Database Auth
Evaluate a manually entered account using Plaid network data
Overview
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 flow
- Starting on a page in your app, the user clicks an action that opens Plaid Link.
- 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.
- The user will be prompted to enter their name, routing number, and account number.
- 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.
Implementation steps
- Create a
link_token
with the following parameters:- The
products
array should includeauth
ortransfer
only, and no other products. - If you are enabling Identity Match, put
identity
in therequired_if_supported_products
array, as putting it in theproducts
array will prevent Database Auth from activating. - If you plan to use Signal, put
signal
in theadditional_consented_products
orrequired_if_supported_products
array. Putting it in theproducts
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.
- The
- In the Dashboard Account Verification pane, ensure "Manage via Dashboard" is selected, and enable "Verify with Database Verification".
- 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.
- Open Link according to the instructions for your platform, using the
link_token
created earlier. - 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 anaccess_token
. You can then proceed to call/auth/get
and/or/processor/auth/get
, as described in the main Auth integration process. - 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.
Understanding verification status and name score
Your business logic will be based on the results of the verification status and the name score.
Verification status
The possible values 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.
Balance is not compatible with Items verified via Database Auth. If you need to check for potential ACH return risk for items verified via Database Auth, you must use Signal.
Signal and Identity Match are only compatible with Database Auth Items whose verification status is database_insights_pass
. If you need to check for potential ACH return risk using Signal before making transfers, or if you need to check for account takeover fraud using Identity Match, you should not accept the database_insights_pass_with_caution
status.
Name match score
The possible values for the name match score range from 0-100. In general, you should require a name match of at least 70.
Example of how to interpret name match score
Range | Meaning | Example |
---|---|---|
100 | Exact match | Andrew Smith, Andrew Smith |
85-99 | Strong match, likely spelling error, nickname, or a missing middle name, prefix or suffix | Andrew Smith, Andrew Simth |
70-84 | Possible match, likely alias or nickname and spelling error | Andrew Smith, Andy Simth |
50-69 | Unlikely match, likely relative | Andrew Smith, Betty Smith |
0-49 | Unlikely match | Andrew Smith, Ray Charles |
Using your own evaluation logic (advanced)
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
and verification_insights
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.
When using other flows, customers using a processor partner do not typically need to call /auth/get
, and can directly call /processor/token/create
instead. However, if you are using Database Auth with a processor partner and using your own evaluation logic, you must call /auth/get
and check the value of the verification_status
and/or verification_insights
fields before passing a processor token to the partner.
Fallback flows
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.
Testing Database Auth in Sandbox
For test credentials that can be used to test Database Insights in the Sandbox environment, see Testing Database Auth.