Introduction

The MX Platform API’s Instant Account Verification (IAV) feature allows partners to access account and routing numbers. This guide will take you through the process of getting this information using MXconnect or purely through API endpoints.

The verification process is very similar to standard aggregation. You’ll benefit by reading our comprehensive aggregation guide as well, which covers things like multifactor authentication.

Some important things to keep in mind:

  • IAV is part of MX Platform API and you’ll need to follow its requirements. For important information on errors, standards and conventions, and the overall resource structure of the MX Platform API, please see our API reference.
  • IAV applies only to demand deposit accounts. Functionally, this means that only CHECKING and SAVINGS accounts are likely to be verified.
  • If a verification is already running when you start a new verification, a 202 Accepted status will be returned. If another aggregation-type process is already running — like standard aggregation or extended transaction history — a 409 Conflict will be returned.

MXconnect Workflow

You’ll use this workflow with MXconnect. See our full guide for more.

  1. Create a user.
  2. Load MXconnect for that user.
    • The end user will use MXconnect to create a member, start a verification job, and answer multi-factor authentication if necessary.
  3. The end user interacts with MXconnect.
    • Listen for and handle event messages; MXconnect will deliver the member connected event message if successful.
    • Polling the member status helps deal with cases where MXconnect is closed early or unexpectedly; a verification is successful when the member connection_status is CONNECTED and the is_aggregating field changes from true to false.
  4. Read the new member’s account numbers.

API-only Workflow

You’ll use this workflow with the Platform API. See our full guide for more.

  1. Create a user.
  2. Create a member using the correct institution code and credentials required by that institution.
    • When a member is created, a standard aggregation is automatically started; this can be stopped with the skip_aggregation parameter.
  3. Call the verify endpoint.
  4. Poll the member’s connection status.
  5. Answer multifactor authentication, if necessary.
  6. Answer the special account-selection challenge.
  7. Poll the verification status until an end state is reached.
    • A verification is successful when the connection_status is CONNECTED and the is_aggregating field changes from true to false.
  8. List the member’s account numbers.

A note on virtual account numbers

OAuth connections for the Chase institution do not return end users’ actual account numbers for deposit accounts. Instead, they return a Virtual Account Number (VAN) and an associated routing number (ABA). The VAN will not have any similarity to the actual account number; the ABA will be an ABA for the institution, but may or may not be the ABA associated with the actual account number, as some institutions have multiple ABAs.

The VAN and associated ABA returned through the verification endpoint are valid for money movement on the ACH system, but only when used together; for instance, using the VAN with a different ABA also associated with the institution will not work for money movement.

Nevertheless, these numbers will not match end users’ actual account numbers for verification purposes.

While Chase is currently the only institution on the MX platform which returns VANs on OAuth connections, other institutions may do so in the future.

Non-OAuth connections will return real account and routing numbers.