Implementation Checklist
Checklist for implementing Plaid Core Exchange
Scoping and implementation
- Review the Core Exchange API Reference documentation
- Review the architecture diagram
- Try out our Postman collection to test requests and responses on a mock bank server
- Complete the Intake Questionnaire. The information provided allows us to best support you through your onboarding experience
- Get access to the Plaid Data Partner Dashboard.
To access Plaid's Data Partner Dashboard, you must create a new dashboard team and have your Plaid contact convert it into a Data Partner team.
- If your organization already has access to the Plaid Dashboard as a Plaid customer
- While logged in at dashboard.plaid.com, navigate to the button in the top left corner and click "Create a new team."
- For "What best describes your organization," select "Business or developer."
- For "What are you building," select "Personal finances."
- If your organization does not have access to the Plaid dashboard
- Sign up for a Plaid account at dashboard.plaid.com/signup.
- Under "Welcome! How can we help you get started?" select "Business or developer."
- After completing the sign-up flow, verify your email to gain access to the dashboard.
- Copy your
client_id
on dashboard.plaid.com/developers/keys and share it with your Plaid contact to convert your team into a Data Partner team.
- Prepare one or more test accounts for each type of account you support (checking, savings, credit card, loan, 401k, etc.) Ensure that:
- All accounts have balance data
- All accounts have contact data
- Depository, loan, and investment accounts have transaction data
- Depository accounts have payment networks data
- Allowlist the following Plaid IPs:
- 18.214.218.91
- 3.211.30.208
- 3.214.25.67
- 54.88.74.128
- 54.208.59.10
- 54.88.202.28
- 34.199.37.46
- 35.168.137.48
- 3.215.49.214
- 34.202.178.138
- 52.0.205.192
- 52.3.166.211
- 35.174.147.86
- 52.88.82.239
- 52.41.247.19
- 3.233.249.56
- 35.153.85.253
- 3.219.116.195
Building and testing
Develop and test authentication
- Create an OIDC-compliant server, including:
- A server domain
- A well-known configuration endpoint
- Issue Plaid a client ID and client secret
- Make identity information available to Plaid (Choose one below):
- OIDC-compliant:
- Non-OIDC compliant (not recommended):
-
/customers/current
endpoint - Create a token exchange endpoint
Develop and test FDX data subsets
-
/accounts
: Search and view customer accounts -
/accounts/{accountId}
: Get account balances, liabilities, and other information -
/accounts/{accountId}/payment-networks
: Get payment networks supported by an account -
/accounts/{accountId}/contact
: Get account contact information -
/accounts/{accountId}/transactions
: List all account transactions -
/customers/current
(only if OpenID Connect compliance is not followed): Get the ID of the customer within the authorization scope
Go-live
Get ready for production
- Confirm your organization's name, logo, and URL. Plaid uses this information to populate your organization's details in Plaid Link. Your logo file must be a 96x96 circular PNG and under 2MB
- If you would like to make an external launch announcement, reach out to our Plaid team to finalize plans
- Once you have validated your integration, request production access in the [Plaid dashboard](https://dashboard.plaid.com/) or reach out to your Plaid contact
Pilot and migrate
(Note: This section only applies to existing Plaid partners)
If your institution is already supported in Plaid Link or you are a platform provider with numerous institutions, we will partner together to develop a pilot and migration plan. Migrations typically have 4 phases:
Phase | Description | Timeline* | |
---|---|---|---|
1 | Friends and Family Testing | Limited access, internal user traffic | ~ 2 weeks |
2 | Pilot Cohort | Enable new connections in production for pilot cohort, monitor health and resolve issues | ~ 2 weeks |
3 | Remaining Cohorts | Enable new connections for remaining cohorts in production, monitor health and resolve issues **# of cohorts is partner dependent | ~ 2-3 weeks |
4 | Existing User Migration | After integration health is validated, Plaid will begin a process to migrate all existing items over to the OAuth + API connection. | ~120 days |
*Timeline illustrative. Speed contingent on ability to validate institutional health, address any open issues etc.
Ongoing management
We will continue to partner together to ensure integration quality after you go live on API connectivity with Plaid. Key integration health metrics Plaid monitors include: conversion, data access success rate, data availability and accuracy.
- Update the Plaid team with the correct point of contact to support ongoing integration health
- Log the variables below to help troubleshoot any potential issues with the integration:
- OAuth flow: log the OAuth
state
variable - The
state
variable is sent in the URL from Plaid when an OAuth login initiates. - API connections: log
UserIdentifier
- Depending on your OAuth integration this value will be:
- The value of
sub
from your OIDC token - The value of
sub
from your OIDC UserInfo endpoint - If neither of the above options are available, implement the
/customers/current
endpoint and use the value ofcustomerId
- Consider ways to take your integration to the next level:
- Increase consumer throughput with App2App functionality
- Show your customers their most up-to-date connections to Plaid-powered apps and enable them to make updates in real-time, automatically syncing permissions across the financial ecosystem via Permissions Manager
Key considerations for Digital Banking Platforms
Partnering with Digital Banking Platforms is essential to how Plaid leads the market in preparing for the open finance future. Over 30 platforms, representing 7000+ financial institutions are already live or in the process of going live with API-based data connectivity with Plaid.
The Plaid team has made key investments to support rapid scaling of our API migrations. Our Data Partner Dashboard and internal tooling make it straightforward to migrate hundreds of financial institutions and millions of new and existing users to API in a matter of weeks.
1. Execute an “opt-out migration”
Financial institutions and their end users now expect highly reliable and secure data access. In order to deliver that experience as quickly as possible, we recommend an "opt-out" migration strategy for Digital Banking Platform institutions.
How to execute:
- Communicate with your financial institutions that Plaid API access is rolling out for all institutions
- Share with Plaid the number of institutions you support
- Determine if cohort-based ramping of institutions is needed (details to consider in step 2)
- Dependent on the scale of your existing Plaid volume, we may encourage either:
- Friends and family pilot: Set up 1-2 financial institutions for testing in production under a pseudonym only findable by active testers. Plaid will share a PDF checklist of tests to run to testers.
- Production pilot: Bring 1-5 financial institutions live in production to validate integration before bringing the rest of your institutions live.
- Upload financial institutions into the Data Partner dashboard
- Plaid brings financial institutions live on API!
2. Consider backend data complexities upfront:
- Pilot/testing plan: Do you have different backend pods, product lines, or backend core groupings that might align to different backend data models? If so, we encourage representing each subgroup in a pilot cohort to uncover any variability or errors.
- Account and routing numbers: There is zero room for error when it comes to accuracy of account and routing numbers. We have found with platforms representing different backend cores there can be some edge-case discrepancy. Please validate that `/payment-network` data is accurate for all institutions before going live.
Architecture diagram
This sequence diagram depicts the standard flow of an end-user selecting an institution in Plaid Link and the resulting interaction flow between Plaid and a data partner’s API. Core Exchange offers flexibility that meets your needs, so exact flows can vary depending on your OAuth 2.0 and FDX implementation.