Database Auth

Database Auth can increase conversion by providing instant account verification when end users cannot, or do not want to, log into their financial institution to verify their account. With Database Auth, users can instead enter their account and routing number manually.

Database Auth verifies account and routing numbers by checking the information provided against Plaid's known account numbers, leveraging Plaid's database of over 200 million verified accounts. If no match is found, Plaid will check the account number format against known usages by the institution associated with the given routing number. Database Auth will provide a verification status of 'pass', 'pass with caution', or 'fail' and a set of attributes that contributed to that status, such as whether a match was found or whether Plaid fell back to checking account number formats.

Database Auth does not verify that the user has access to the bank account and does also not fully guarantee that the account exists. Database Auth does not create a live connection to the bank account and cannot be used to check real-time balances (although it is compatible with anti-risk products such as Signal and Identity Match). For these reasons, Database Auth should not be enabled where there is a very high risk of fraud or ACH returns.

Database Auth is available for Auth flows the United States. In Canada, Database Auth is currently in beta; contact your Plaid account manager for details.

You can try out the Database Auth flow in an Interactive Demo.

1. Starting on a page in your app, the user clicks an action that opens Plaid Link.
2. Inside of Plaid Link, the user selects an option that triggers the manual verification flow. This could occur because the user opted in to the manual flow (if Auth Type Select is enabled) or because their institution does not support Instant Auth.
3. The user will be prompted to enter their name, routing number, and account number.
4. Based on rules you have configured, the user will either see a success screen or a failure screen, or be prompted to fall back to micro-deposit-based verification.

1. Create a link_token with the following parameters:
   • The products array should include auth or transfer only, and no other products.
   • If you are enabling Identity Match, put identity in the required_if_supported_products array, as putting it in the products array will prevent Database Auth from activating.
   • If you plan to use Signal, put signal in the additional_consented_products or required_if_supported_products array. Putting it in the products array will prevent Database Auth from activating.
   • No other products besides Signal and Identity are compatible with Database Auth Items. To enable other products for Items where Database Auth is not used, put those products in the additional_consented_products array.
   • country_codes should be set to ['US'] – Database Auth is currently only available in the United States.
2. In the Dashboard Account Verification pane, ensure "Manage via Dashboard" is selected, and enable "Verify with Database Verification".
3. Configure the rules:
   • (Recommended for most customers) To use Plaid's rules-based, customizable, no-code evaluation logic, select "For certain Database Auth results, fallback".
   • To use your own evaluation logic, select "For any Database Auth result, complete Link". This option is designed for customers who require more fine-grained control of the Link flow beyond what the ruleset configuration allows, or who have highly sophisticated fraud evaluation systems and require more custom logic. See Using your own evaluation logic.
4. Open Link according to the instructions for your platform, using the link_token created earlier.
5. After the end user completes the Link session, if the session was successful, or if you are using manual evaluation logic, Link will return a public_token that you can exchange for an access_token. You can then proceed to call /auth/get and/or /processor/auth/get, as described in the main Auth integration process.
6. If the session was unsuccessful, Link will fall back to either an error screen or to a micro-deposit flow, depending on which options you selected in the Account Verification pane.

Your business logic will be based on the results of the verification status and the name score.

The possible values and most common causes for verification_status are:

database_insights_pass: Plaid was able to match the account and routing number provided to an existing Item on the Plaid network and has high confidence that the account exists. The account is not known to be closed or frozen.

database_insights_pass_with_caution: Plaid was unable to match the account and routing number provided to an existing Item on the Plaid network, but the routing number is valid and the account number matches Plaid's known rules for account number formatting at the associated financial institution.

database_insights_fail: The routing number is not recognized, or the account number does not appear to match the formatting rules at the associated financial institution, or Plaid has received data indicating the account is closed or frozen.

In addition to the common causes above, additional risk factors may impact verification_status results.

Understanding the pass with caution verification status

Because database_insights_pass_with_caution is a common Database Insights result, how you choose to handle it is important.

In a typical test scenario, accepting only pass results reduced administrative return rates by by over 80%, while accepting both pass and pass_with_caution reduced administrative return rates by approximately 50%. Note that results will vary based on your own user base and use case and are not guarantees.

If you do not want to accept database_insights_pass_with_caution, you can configure Link to use a Fallback flow.

The possible values for the name match score range from 0-100. In general, you should require a name match of at least 70 to effectively protect against account takeover attacks.

Example of how to interpret name match score

If you selected "For any Database Auth result, complete Link", you must write your own code for handling the results of the Database Auth verification.

To get the results, call /auth/get and examine the verification_status, verification_insights, and verification_name fields. Based on the values in these fields, you will make a decision on whether to accept the account data as verified, take additional risk mitigation steps, or reject the account data as unverified.

The verification_insights object will contain more detailed analysis showing exactly which checks passed or failed to result in the given verification_status. It will also contain the name_score.

For more details on the verification_insights values, see the API Reference.

When using your own evaluation logic, you can fallback only to Automated Micro-deposits, and not to Instant Micro-deposits or Same-Day Micro-deposits.

If Database Auth fails, you can configure fallback to Instant Micro-deposits, Same-Day Micro-deposits, or Automated Micro-deposits via the Account Verification Dashboard.

For test credentials that can be used to test Database Insights in the Sandbox environment, see Testing Database Auth.