Planning your integration

Core Exchange connects four players:

Each party plays a role. The consumer uses an app, the app connects via Plaid, Plaid communicates with you, and you authenticate the user and issue tokens.

Your authorization server issues one user-scoped token to Plaid. Plaid then handles issuing short-lived, app-scoped tokens to each connected app downstream.

Why this matters:

• Reduces API traffic - One token for multiple apps eliminates duplicate data requests for users with multiple connections.
• Centralized consent management - Users revoke access from one place instead of managing separate tokens per app. Data Providers get a unified view through Permissions Manager instead of tracking distributed per-app tokens.
• Returning user experience enabled - Users authenticate once with your bank, then quickly reconnect to new apps using phone verification.

Some integrations issue one token per app. This means repeating the OAuth flow for every new connection, which creates more friction, more API calls, and no returning user experience. Plaid still supports this model, but you should consider migrating to universal tokens for better performance and user experience.

The two models differ in several key areas:

The returning user experience is Plaid's streamlined onboarding for users who have previously connected their accounts. Here's how it works:

1. First connection: User verifies their phone number during the initial Link session
2. Subsequent connections: When the same user connects to a new app, Plaid recognizes their phone number
3. Quick reconnection: User can instantly access previously connected institutions and choose accounts to share - no need to re-authenticate

Why it matters to Data Providers:

• Higher conversion rates - Users complete connections faster with less friction
• Reduced authentication load - Users can connect new apps without going through your full OAuth flow every time (when adding apps, not new accounts)
• Better user experience - Less manual data entry and faster onboarding
• Requires universal token model - Only works with the user-scoped token approach (recommended), not per-app tokens

This feature is automatically enabled and requires the universal/single-token architecture, in which you issue one token to Plaid for each user, rather than separate tokens per app. It's one of the key benefits of choosing the universal token model.

Where users select which accounts to share matters more than you think. This decision directly affects the user experience for returning users.

Users see the account selection screen in Plaid Link after authenticating with you. You issue a token with access to all accounts, and Plaid handles filtering based on the user's selection.

• Full returning user experience - Users authenticate once, then quickly connect new apps using phone verification
• Flexible connections - Users can share different accounts with different apps without re-authenticating
• Simpler implementation - You don't need account selection logic in your OAuth flow

Users select accounts during the OAuth flow on your domain. The token you issue is scoped to only the selected accounts.

If a user previously selected their checking account when connecting Venmo, they can later connect Copilot to that same checking account using the returning user experience. But if they want to share their savings account with Copilot (an account they never selected before), they'll need to go through the full OAuth flow again to expand the scope.

When this happens:

Users don't think in terms of "previously selected accounts." They just want to connect their bank to an app. Forcing OAuth for a new account feels like friction, not security.

Why Plaid recommends Plaid Link for account selection: Plaid Link delivers pre-built, conversion-optimized account selection screens with no development work required on your end. Link achieves industry-leading conversion rates through streamlined UIs, passkey authentication for returning users, and continuous optimization across 12,000+ institutions. If your users typically have multiple accounts (checking, savings, credit cards), placing account selection in Link eliminates the need to build and maintain your own account selection logic while delivering a better user experience.

Some Data Providers display which data types the user is authorizing (account numbers, transactions, balances, etc.) during the OAuth flow. Transparency is important. But allowing users to deselect individual data types at the OAuth layer doesn't provide the security benefit you might expect - and it breaks the returning user experience.

With the universal token model, you issue a broad token to Plaid that covers all data types the user might share with any app. Plaid then acts as a gatekeeper, issuing downstream app-specific tokens scoped only to what each app actually requested.

Example: Even though your Plaid token includes statements, Venmo never sees them if Venmo only requests account numbers for ACH. The lending app that needs statements gets them, but Venmo doesn't. Data minimization happens at the Plaid layer, where apps declare their needs upfront.

If users can deselect data types during OAuth, they'd need to re-authenticate every time they connect an app that requires a previously excluded data type. A user who opted out of sharing statements with Venmo would have to go through full OAuth again to connect a lending app that needs statements - even though Venmo never would have received those statements anyway.

Show users what data types are shared, but don't give them checkboxes to deselect individual types. Users see what's shared and can approve or cancel the entire request.

If you disclose data types during OAuth, show the superset of data types that Plaid might need across all use cases. Users authorize once, and Plaid handles scoping to individual apps based on what each app actually requested.

Plaid manages an extensive third-party risk management program and onboards apps to the network. Data Providers need visibility into which apps users are connecting to them. That's where App Directory comes in.

App Directory provides Data Providers with application metadata without the overhead of Dynamic Client Registration. Available via APIs and a no-code dashboard, it's the fastest path to app-level visibility.

Two endpoints available:

• GET /fdx/recipients - Returns a list of all applications
• GET /fdx/recipients/<recipient_id> - Returns details for a specific application

What you get:

Each application record includes name, logo URL, website, terms of service, privacy policy, contact information, requested scopes, consent duration, and more. Everything needed to understand which apps are accessing user data.

How to integrate:

1. No-code option: Use Plaid's Data Partner Dashboard to search by application name or browse the full catalog with no development required.
2. API option: Integrate the App Directory endpoints into your systems for programmatic access.

FDX alignment: This approach implements FDX RFC 0206 (Delegated App Registration), approved in FDX v5.1. Plaid handles app onboarding and due diligence. Data Providers get visibility and control without managing individual client registrations.

Some Data Providers implement FDX Dynamic Client Registration (DCR) to ensure interoperability across multiple aggregators. DCR is a standardized protocol for programmatically registering OAuth clients.

Standard FDX DCR assumes a three-party model: user -> app -> data provider. In this model, each app registers as its own OAuth client and receives unique credentials (client ID and secret).

Core Exchange uses a four-party model:

Plaid is the OAuth client, not the individual apps. Apps never call your API directly - they connect through Plaid.

Traditional DCR assumes each app registers as its own OAuth client with unique credentials. When Data Providers implement this, they end up issuing per-app tokens. Users have to complete OAuth for every new app connection; the returning user experience breaks, and API traffic increases for users with multiple connections. Traditional DCR breaks the universal token model.

If you need DCR for interoperability, use a single-token-compatible DCR instead. This approach preserves the universal token model while still using the DCR protocol.

How it works:

1. Plaid registers as the OAuth client and receives credentials
2. Plaid registers individual apps with a dap_client_id parameter
3. You return a recipient_id (not client credentials) for each app
4. Apps are registered, but tokens are issued to Plaid only

This model gives you:

• App-level visibility (same as traditional DCR)
• Ability to reject applications during registration
• Compatibility across aggregators
• Preserved returning user experience

Implementation: A single-token-compatible DCR is defined in FDX RFC 0356. If you're considering DCR, coordinate with your Plaid contact to discuss implementation details and timelines.

Key requirement: If implementing DCR with Plaid, you must use a single-token architecture. Per-app tokens are not supported.

Before moving to implementation, make these key decisions:

• Token model: Universal token or per-app token?
• Account selection screen location: Plaid Link or your domain?
• Data type selection: Disclosure without checkboxes
• App visibility: App Directory or DCR?
• OIDC vs OAuth 2.0: OIDC recommended for returning user experience

Recommended configuration: Universal token + Plaid-owned account selection + App Directory + OIDC

This combination delivers:

• Full returning user experience
• Reduced API traffic for users with multiple app connections
• Simplified implementation
• Best user experience