Plaid logo
Docs
ALL DOCS

Auth

  • Introduction to Auth
  • Add Auth to your app
  • Money movement partnerships
  • Increasing pay-by-bank adoption
  • Additional Auth flows
    • Instant Auth, Instant Match, & Instant Micro-deposits
    • Automated Micro-deposits
    • Same Day Micro-deposits
    • Micro-deposit Events
    • Database Auth
    • Configuring entry points
    • Test in Sandbox
    • Anti-fraud best practices
    • Database Insights and Match (legacy)
Plaid logo
Docs
Close search modal
Ask Bill!
Ask Bill!
Hi! I'm Bill! You can ask me all about the Plaid API. Try asking questions like:
  • What's the difference between an Item and an access token?
  • Which countries does Investments support?
  • How do I set up Link on the web?
Note: Bill isn't perfect. He's just a robot platypus that reads our docs for fun. You should treat his answers with the same healthy skepticism you might treat any other answer on the internet. This chat may be logged for quality and training purposes. Please don't send Bill any PII -- he's scared of intimacy. All chats with Bill are subject to Plaid's Privacy Policy.
Plaid.com
Log in
Get API Keys
Open nav

Anti-fraud best practices

Optimally configure manual entry verification flows to reduce fraud

Plaid provides a suite of fraud prevention products that assist your application in catching bad actors and ACH returns. You can verify the source of funds with Identity, confirm the real-time Balance prior to a transfer, and leverage our machine learning model Signal to prevent returns and release funds earlier. These features are fully compatible with accounts connected via Instant Auth, Instant Match, and Automated Micro-deposits.

However, if an account is connected via a manual entry method such as Same Day Micro-deposits, Instant Micro-deposits, or Database Auth, these features are not always available and could increase the likelihood that you experience fraud and ACH returns. Following the recommendations below can help mitigate these risks.

Use Identity Match, Signal, and/or Identity Document Upload

Approximately 30% of Items created with manual entry methods (including 100% of Items created by Database Auth that have a database_insights_pass verification status) are supported by /identity/match, which allows you to determine the likelihood that the user's identity details, such as name and address, on file with their financial institution match identity information held by you. For more details on this feature, see Identity.

The same Items that are supported by /identity/match are also supported by Signal. Signal can assess the return risk of a transaction based on machine learning analysis and alert you to high-risk transactions. For more details, see Signal.

Identity Document Upload verifies account owner identity based on bank statements, and is compatible with Items that don't support /identity/match or /identity/get. After creating the Item, you can use update mode to send the user through a Link session where they will be asked to upload a bank statement. Plaid will then analyze this statement for an account number match and will parse identity data from the statement. With the optional Fraud Risk feature, you can also check the uploaded statement for signs of fraud. For more details, see Identity Document Upload.

Adjust a user’s Link experience based on their risk profile

In order to reduce fraud upstream on your application, you can use Plaid Identity Verification to verify a government ID or match with a selfie of the document holder.

If your application does not have an identity verification solution or Plaid Link is not gated from the general public with fraud prevention and user verification checks in place, we do not recommend adopting manual entry verification flows as it may introduce an unnecessary fraud vector onto your platform.

If you identify a user to be riskier, consider disabling manual entry verification flows for those users.

Another option for riskier users is to leave manual entry verification flows enabled, but enable Reroute to Credentials in Forced mode, which will only allow the user to link via manual entry verification flows when using a routing number not supported by other authentication methods.

You may also consider changing your user’s experience with your service based on their connection method. For example, if a user connected via a manual entry verification flow, you may consider enforcing a lower transfer threshold than for users where it was possible to verify identity and increasing hold times on those funds.

Was this helpful?
Developer community
GitHub
GitHub
Stack Overflow
Stack Overflow
YouTube
YouTube
Discord
Discord