Implementation checklist
Step-by-step checklist for implementing Plaid Core Exchange
Scoping and implementation
Review the Core Exchange API reference documentation
Review the architecture diagram
Get access to the Plaid Data Partner Dashboard. Your Plaid contact will provide a one-time use link to either sign up for a data partner Dashboard account or create a new team if you already have Plaid Dashboard access.
Gather business information. In the onboarding flow, Plaid verifies your organization and requires the following information, which you can collect in advance:
- Name and business email address of a responsible business contact representing the data provider organization
- Company address
- Company name
- Company tax ID
- Company Legal Entity Identifier
- Industry
- Licensing and registration (e.g., FDIC, NCUA, SIPC)
Gather technical contact information. Before you go live, Plaid requires technical contact information in the event an urgent technical issue arises. For more details, see Post-launch operations.
- Shared email address
- Phone number (if available)
- Additional individual contacts
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 IP addresses. Learn more about allowlisting.
162.120.88.0/222602:F74B::/40
Do not remove any of the following Plaid IPs from your allowlist, if they are already present:
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 OAuth server, including:
- A server domain
- A well-known configuration endpoint
Note: OIDC compliance is recommended but not required. Plaid supports OAuth without OIDC. For more details, see Authentication overview.
Run through FDX Explorer to see a complete OAuth flow with sample requests.
Issue Plaid a client ID and client secret
Make identity information available to Plaid (choose one):
- OIDC compliant (recommended):
- OAuth without OIDC:
/customers/currentendpoint
- Create a token exchange endpoint
Develop and test FDX data subsets
Use the Validator in the Dashboard to test each endpoint as you build.
/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/accounts/{accountId}/statements: Get account statements/accounts/{accountId}/asset-transfer-networks: Get asset transfer networks for an account/customers/current(only if OIDC is not used): Get the ID of the customer within the authorization scope
Go-live
Get ready for production
Confirm you have implemented strong authentication in your OAuth flow (i.e., MFA)
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 or 152x152 circular PNG and under 2MB.
Once you have validated your integration, request production access in the Plaid Dashboard. For more details, see Production access.
Pilot and migrate
(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, Plaid will partner with you to develop a pilot and migration plan.
A typical migration involves:
- Pilot cohort: Enable new connections in production for a small cohort, monitor health, and resolve issues.
- Remaining cohorts: Expand to remaining cohorts in production, with continued monitoring. The number of cohorts is partner-dependent.
- Existing user migration: After integration health is validated, Plaid begins a process to migrate all existing Items over to the OAuth + API connection. This phase typically runs over approximately 90 days.
Timelines vary based on ability to validate institutional health and address open issues.
Ongoing management
After going live, Plaid continues to partner with you to ensure integration quality. Key integration health metrics 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 key identifiers to aid in troubleshooting. For a full list, see Post-launch operations.
Consider ways to take your integration to the next level:
- Increase user throughput with App2App functionality
- Enable Permissions Manager and App Directory for transparency into user consent and connected applications
Key considerations for digital banking platforms
Digital banking platforms can onboard multiple financial institutions under a single integration.
Opt-out migration
An "opt-out" migration is a strategy where API access is rolled out to all financial institutions on the platform by default, rather than requiring each institution to individually opt in. This approach accelerates the timeline and delivers reliable, secure data access more quickly.
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, Plaid may recommend either:
- Production pilot: Bring 1-5 financial institutions live in production to validate integration before bringing the rest live.
- Broader rollout: Upload financial institutions into the Data Partner Dashboard and launch on API.
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, representing each subgroup in a pilot cohort helps uncover variability or errors early.
- Account and routing numbers: Accuracy of account and routing numbers is critical, particularly for platforms representing different backend cores where edge-case discrepancies may exist. Validate that
/payment-networkdata 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.
