External accounts must undergo a series of validations before they can be used for transactions. These validations ensure that account details are accurate, the account is operational, and regulatory checks are satisfied.

Validating an external account helps:

• Reduce ACH return risks (e.g., insufficient funds, closed accounts)
• Prevent fraudulent activity
• Improve success rates of debit and credit transactions

Depending on your program configuration, validations can be triggered during account creation or later using the validation API. Multiple validation methods may be applied before an account becomes fully active.

---

Validation & Activation Lifecycle

INACTIVE
   ↓
PENDING_VERIFICATION
   ↓
┌──────────────────────────────────────────────────────────────┐
│                     VALIDATIONS IN PROGRESS                  │
│                                                              │
│  1. EWS (Instant Validation)                                 │
│     PENDING → OPEN / VALIDATED ───────────────┐              │
│            → NOT_FOUND ────────┐              │              │
│            → INVALID_DEBIT_ACC │              │              │
│            → CLOSED / HIGH_RISK│              │              │
│                                 ↓              ↓              │
│  2. PRENOTE (if ALWAYS / ON_FAILURE)                         │
│     PENDING → PROCESSING → COMPLETED ────────┐              │
│                         → FAILED ────────────┘              │
│                                                              │
│  3. MICRO-DEPOSIT (if ALWAYS)                               │
│     PENDING → PROCESSING → AWAITING_VERIFICATION            │
│                         → COMPLETED ──────────┐              │
│                         → RETURNED / FAILED ──┘              │
│                                                              │
│  4. OFAC (Compliance Check)                                 │
│     PENDING → VERIFIED ───────────────────────┐              │
│            → UNDER_REVIEW                     │              │
│            → REJECTED ────────────────────────┘              │
│                                                              │
│  5. DOCUMENT VERIFICATION (Optional)                        │
│     PENDING → VERIFIED                                      │
│            → REJECTED                                       │
│                                                              │
└──────────────────────────────────────────────────────────────┘
   ↓
┌───────────────────────┬──────────────────────────┬──────────────┐
│ ACTIVE                │ ACTIVE (Credit Only)     │ BLOCKED      │
│ (All validations      │ (Debit restricted due    │ (Any critical│
│ successful)           │ to validation outcomes)  │ failure)     │
└───────────────────────┴──────────────────────────┴──────────────┘

Key Notes:

• External accounts move from INACTIVE → PENDING_VERIFICATION upon validation initiation
• Multiple validations may run in parallel or as fallback mechanisms
• Final account status depends on combined validation outcomes, not a single method

---

External Account Status

External account status represents the current stage of validation and determines whether the account can be used for transactions.

How External Account Status is Determined

The final status of an external account is determined by the combined outcome of validation methods and compliance checks. The following table outlines how different outcomes impact the final status:

---

Validation Methods

External accounts can be validated using multiple methods depending on your program configuration:

• EWS (Instant Validation): Performs real-time checks on account status and recent transaction history
• Prenote: Sends a $0 transaction to validate the account at the bank level
• Micro-deposit: Verifies account ownership by depositing small amounts that the customer must confirm

External accounts can be validated either during account creation or later by explicitly triggering validations using the POST v1/customer/id/{id}/externalAccount/id/{id}/validate API.

To help you choose the right validation method, refer to the comparison below.

Validation Rules:

• EWS can be used independently or alongside other methods
• Prenote and Micro-deposit are mutually exclusive (only one can be used)
• Use ON_FAILURE to trigger Prenote when EWS is inconclusive (NOT_FOUND)

Completing Micro-deposit Verification

If you are using Micro-deposit validation, an additional step is required to complete the verification process.

Once the micro-deposits are credited to the external account, the customer must confirm the deposited amounts to verify ownership.

To complete this step, use the POST v1/customer/id/{id}/externalAccount/id/{id}/verify API.

---

Compliance Checks

In addition to validation methods, external accounts undergo compliance and verification checks to ensure regulatory adherence and document authenticity.

OFAC Verification

Validates the external account holder against regulatory watchlists to ensure compliance.

Document Verification

Triggered when supporting documents (e.g., authorization forms) are uploaded for the external account.

📘

Key Notes:

• Validation methods may run independently or as fallback mechanisms
• Final status of the external account is determined by combined outcomes across validations and compliance checks
• External accounts can re-enter PENDING_VERIFICATION if re-validation is triggered

---

Instant Internal Validation (Passport Match)

When an external account is added, the system checks whether the account already exists within the Passport ecosystem. If a match is found, the account can be instantly validated without requiring additional validation methods such as Prenote or Micro-deposits. This significantly reduces onboarding time and avoids unnecessary verification steps.

To view the outcome of this validation, use the External Account Retrieve API and check the validateInstantly object in the response for detailed status and reason.

Instant Validation Statuses

---

Failure Handling & Re-verification

External account validations may fail due to account issues, compliance failures, or bank-level responses. Understanding these scenarios helps you take the appropriate corrective action and ensure successful transaction processing.

Always monitor validation statuses and status reasons via the Retrieve External Account API or webhooks to proactively handle failures.

Common Failure Scenarios

1. Insufficient Funds / Returns (e.g., R01)
   1. External account may be marked as ACTIVE (Credit Only)
   2. Debit transactions are temporarily restricted
   3. Credits can still be processed Recommended Action: Retry debit transactions after sufficient funds are available
2. Account Closed or Invalid (e.g., R02)
   1. External account is moved to BLOCKED
   2. No further transactions are allowed Recommended Action: User must add a new external account
3. Validation Failures
   1. Prenote failures (RETURNED)
   2. Micro-deposit failures (RETURNED, VERIFICATION_FAILED)
   3. External account is moved to BLOCKED Recommended Action: User should re-add or re-verify the account details
4. Compliance Failures (OFAC = REJECTED)
   1. External account is restricted due to regulatory reasons Recommended Action: Requires manual review or resolution via compliance team
5. Automatic Re-verification & Fallbacks: In certain cases, the system may automatically trigger additional validation steps:
   1. If EWS returns NOT_FOUND → System can trigger Prenote (ON_FAILURE)
   2. If validation method is inconclusive → Fallback validation may be applied based on configuration
6. Re-verification Scenarios
   1. If an external account is manually unblocked → Status moves back to PENDING_VERIFICATION
   2. If validation fails repeatedly → External account may need to be re-created
   3. If account details are updated → Validation may be re-triggered

---

Best Practices

• Prefer Instant Validation for faster onboarding
• Use Micro-deposit when ownership confirmation is critical
• Monitor status transitions via the Retrieve External Account API