Plaid integration — and its open banking equivalents in Europe — is the foundation of every personal finance app, and it's consistently the part that founders underestimate. The integration looks simple from the outside: connect to a provider, get account balances and transactions, display them. In practice, it's a multi-week engineering effort with ongoing maintenance, coverage gaps that only surface in production, and pricing that scales faster than most founders expect. Our fintech development services cover the full stack — this guide focuses specifically on the bank data integration decision.
We've integrated multiple open banking and bank data providers across fintech builds, including our mobile banking product for kids and parents with Mastercard and payment infrastructure. The provider comparison and integration patterns in this guide are drawn from real project experience. For the broader fintech cost picture, see our fintech app development cost guide.
Why Bank-Data Integration Is Underestimated in PFM Builds
The optimistic version of a bank data integration: call the provider API, get back a list of transactions with categories, display them in a nice chart. Three weeks, maybe four.
The realistic version: choose the wrong provider for your target market and discover in beta that it covers 60% of your users' banks. Handle token expiry correctly or users get silently logged out of their bank connection. Deal with the fact that transaction categorisation from the provider is wrong 15–30% of the time and you need your own categorisation layer. Handle rate limiting and API downtime gracefully. Manage the reconnection flow when a user's bank changes its authentication requirement. Comply with storage and access requirements for the tokens that give you access to someone's bank account.
None of these problems are unsolvable. They're just not visible when you're evaluating providers on their marketing pages. This guide is about the decisions that determine whether your bank data integration is a solid foundation or a source of ongoing production incidents.
The Providers Compared: Plaid, Tink, TrueLayer, MX, Yodlee, Regional Players
The bank data provider landscape has consolidated significantly since 2020. A handful of providers dominate different geographic markets, and the choice between them is primarily a function of where your users are, not which has the best features.
|
Provider |
Primary markets |
Pricing model |
Best for |
Limitations |
|
Plaid |
US, Canada, UK, EU (limited) |
Per-user/month + per-call |
US-focused PFM, lending, payroll |
EU coverage patchy; expensive at scale |
|
Tink |
EU (20+ countries), UK |
Per-connection + per-call |
EU-first neobanks, PFM |
No US coverage; fewer data enrichment features |
|
TrueLayer |
UK, EU, Australia |
Per-connection + revenue share |
UK Open Banking, payment initiation |
Limited US coverage; pricing less transparent |
|
MX |
US, Canada |
Per-user/month |
US PFM, data enrichment, categorisation |
US-only; no EU |
|
Yodlee (Envestnet) |
US, some international |
Per-user/month + data packages |
US wealth management, enterprise |
Legacy architecture; higher enterprise pricing |
|
Nordigen / GoCardless |
EU, UK |
Free tier + per-call premium |
EU budget-conscious builds, early MVP |
Data quality more variable; less enrichment |
Plaid is the default choice for US-first personal finance apps. It has the deepest US bank coverage (10,000+ institutions), mature SDKs for iOS, Android, and web, and a product surface area that goes beyond account data — income verification, identity, assets, and payment initiation are all available. The pricing is per-user-per-month plus per-API-call for certain data types, which gets expensive at scale. For EU-focused products, Plaid's coverage is thin in most markets outside the UK.
Tink (acquired by Visa in 2022) is the strongest choice for EU-first products. It covers 20+ European markets with generally strong bank coverage, and the acquisition by Visa has improved its payment initiation capabilities. Its data enrichment features (categorisation, merchant identification) are solid. No US coverage.
TrueLayer is strongest in the UK, where it was one of the early Open Banking providers. It has expanded into EU markets and Australia, and its payment initiation (pay-by-bank) capabilities are among the strongest available. Pricing is less transparent than Plaid or Tink — typically negotiated rather than listed publicly.
MX is primarily a US data enrichment and categorisation player — it sits above Plaid or other data aggregators and provides cleaner, better-categorised transaction data. For PFM apps that need high-quality transaction categorisation in the US market, MX is worth evaluating as a data quality layer even if another provider handles the bank connection.
Nordigen / GoCardless acquired by GoCardless in 2022 — offers a free tier for EU open banking data access that makes it attractive for early-stage products testing the market. Data quality is more variable than Tink or TrueLayer, but for a budget-conscious EU MVP, it's a reasonable starting point.
Coverage Maps: Which Provider Works in Which Markets
Coverage is the most important variable in provider selection and the hardest to evaluate accurately from documentation alone. "Supports UK" can mean 95% of UK account holders or 40%, depending on how the provider defines support and which banks it has actually connected.
|
Provider |
US |
UK |
Germany |
France |
Nordics |
|
Plaid |
✅ Excellent |
✅ Good |
⚠️ Limited |
⚠️ Limited |
❌ Poor |
|
Tink |
❌ None |
✅ Good |
✅ Excellent |
✅ Good |
✅ Good |
|
TrueLayer |
❌ None |
✅ Excellent |
✅ Good |
✅ Good |
⚠️ Limited |
|
MX |
✅ Excellent |
❌ None |
❌ None |
❌ None |
❌ None |
|
Nordigen |
❌ None |
✅ Good |
✅ Good |
✅ Good |
✅ Excellent |
Coverage numbers in provider documentation are usually institution counts, not account-holder coverage rates. A provider that supports 1,000 UK banks has better coverage than one that supports 200 — but if those 200 banks account for 90% of UK account holders and the 1,000 are mostly smaller building societies, the actual user coverage may be similar. Ask providers for coverage rates by account holder percentage, not institution count, when evaluating for your specific market.
Coverage also degrades over time as banks change their authentication requirements or temporarily restrict API access. Production monitoring that detects when a bank connection starts failing for a cohort of users is not optional — it's how you find out that a bank has changed its OAuth flow before users start calling support.
Pricing Models: Per-User, Per-API-Call, Hybrid
Bank data provider pricing has three common structures, and the one that looks cheapest at MVP often looks most expensive at scale.
Per-user-per-month (Plaid's primary model, MX). You pay a monthly fee for each user who has an active bank connection. Predictable, scales linearly with user growth, and aligns cost with revenue if you're charging users. The risk: inactive users who no longer use the app but still have an active connection continue to cost money. Clean-up logic for dormant connections is an operational requirement, not just good housekeeping.
Per-connection plus per-call (Tink, TrueLayer). You pay when a user connects a bank account and when you make API calls to retrieve data. This can be cheaper than per-user-per-month for products with low data retrieval frequency, and more expensive for products that refresh account data daily or more often. Model your expected API call volume carefully before assuming this structure is cheaper.
Negotiated/enterprise (TrueLayer, Yodlee for large volumes). Above certain user volumes, most providers will negotiate custom pricing. If you're planning to scale beyond 50,000 active connections, the published pricing is a starting point for negotiation, not the final number. Don't build your unit economics on published pricing if you expect to be in this range within 18 months.
One cost that's easy to miss: reconnection events. When a user's bank connection expires or is revoked, the user needs to go through the connection flow again. Each reconnection is typically billed as a new connection. For products with high bank-connection churn (users at banks with short token lifetimes, or users who regularly change their bank passwords), reconnection costs can be a meaningful percentage of total provider spend.
Integration Patterns: Token Storage, Refresh Flows, Error Handling
The Plaid integration pattern is representative of most open banking integrations, with variations by provider:
Initialisation. Your backend requests a link token from the provider, passing the user ID and the products (transactions, auth, identity) you want access to. The link token is passed to the frontend SDK, which opens the provider's hosted UI where the user authenticates with their bank.
Token exchange. After successful authentication, the provider returns a public token. Your backend exchanges this for an access token, which is stored securely server-side. The access token is the credential that allows you to retrieve the user's bank data — it must be encrypted at rest and never returned to the frontend.
Data retrieval. Your backend uses the access token to call the provider API for account balances, transactions, identity, etc. Most providers support webhooks that notify you when new data is available, which is preferable to polling on a schedule.
Token refresh. Access tokens expire. The expiry period varies by provider and by bank (some banks issue tokens that expire in 90 days, others in 12 months). Your system needs to handle token expiry gracefully — detecting when a token has expired, notifying the user, and guiding them through re-authentication without losing their connection history.
Error handling. Bank API errors are not exceptional — they happen regularly. Rate limiting, bank-side outages, authentication failures, and stale session errors all need to be handled gracefully. A bank data integration that surfaces raw API errors to users is a poor product experience. Map provider error codes to user-facing messages that explain what happened and what the user should do.
Data Quality: Account Aggregation Accuracy in 2026
Bank data quality is better than it was five years ago and still not as good as provider documentation suggests. Three areas where data quality issues most commonly affect PFM products:
Transaction categorisation. Provider-supplied categories are wrong 15–30% of the time in our experience, depending on the market and the user's spending patterns. A transaction at a supermarket that also sells petrol may be categorised as groceries or as fuel — or differently by different providers. Most serious PFM products build their own categorisation layer on top of provider categories, using merchant name matching, user corrections, and ML models trained on user-corrected data.
Merchant name normalisation. Raw transaction descriptions from banks are often truncated, include location codes, or are otherwise hard to parse. "AMZN MKTP US*2F4GH8910" is Amazon. "SNBRY SSPRMKTS" is Sainsbury's. Provider SDKs do some normalisation, but it's imperfect. Merchant identification — mapping transaction descriptions to clean merchant names and logos — is a meaningful UX investment for PFM apps.
Balance freshness. Most open banking connections retrieve data at the time of the API call, not in real time. A user's balance as displayed in your app may be 15 minutes to 24 hours old depending on the bank and the provider's caching. Displaying stale balances as current is a trust problem — display data freshness information and refresh prominently.
When You Need More Than One Provider (Cross-Border Fintech)
If your product serves users in multiple countries, you almost certainly need more than one bank data provider. No single provider has excellent coverage in both the US and the EU.
The multi-provider architecture requires: a unified internal data model that normalises account and transaction data regardless of which provider supplied it, provider routing logic that selects the right provider based on the user's country (and potentially the user's bank), and separate token stores for each provider's credentials.
The multi-provider approach adds architectural complexity and doubles (or triples) the integration surface area. For products launching in a single market, defer multi-provider support until you've validated product-market fit. For products with a clear multi-market requirement from day one, it needs to be in the architecture from the start — retrofitting a single-provider architecture to support multiple providers is significantly more expensive than building for it initially.
UK Open Banking vs US Plaid Model: Regulatory Differences
The UK and EU open banking model is regulated — banks are legally required to provide API access to third parties under PSD2. This creates a standardised interface (though implementation quality varies significantly across banks) and means that any FCA-regulated or PSD2-licensed entity can access any compliant bank's data.
The US model, until recently, was Plaid's proprietary model: screen scraping (accessing bank data by simulating a browser session with the user's credentials) plus direct API partnerships with banks that had agreed to provide access. The Financial Data Exchange (FDX) API standard and the CFPB's Section 1033 rulemaking are moving the US toward a more regulated open banking model, but in 2026 the transition is still in progress. The practical effect: Plaid's US coverage is still partly based on screen scraping for banks that haven't moved to API access, which carries reliability and security implications.
For founders building in the UK or EU: open banking regulation means the bank data integration is built on a legally standardised foundation. Provider differentiation is primarily on data quality, enrichment, payment initiation capabilities, and developer experience — not on bank coverage. For founders building in the US: Plaid's proprietary relationships and coverage are more significant differentiators because there's no regulatory baseline.
Security Architecture for Storing Bank-Linked Tokens
Bank-linked access tokens are among the most sensitive credentials your product will handle. They give access to a user's financial accounts — not just data, but in many cases payment initiation capability. The security architecture for storing them is not optional.
Encryption at rest. Access tokens must be encrypted at rest using AES-256 or equivalent. They should not be stored in plain text in any database, log, or cache. Key management matters — the encryption key should be stored separately from the encrypted data, ideally in a key management service (AWS KMS, Google Cloud KMS, HashiCorp Vault).
No client-side exposure. Access tokens must never be sent to the client (mobile app or browser). All API calls that use the access token must go through your backend. If your architecture has the frontend calling the bank data provider directly with an access token, that token is at risk of interception.
Token rotation. When a user's access token expires or is revoked, the old token must be invalidated in your system promptly. Stale tokens that are no longer valid but remain in storage are a security exposure if your system is breached.
Audit logging. Every access to a user's bank data — by your system or by support staff — should be logged with timestamp, accessor identity, and data type accessed. This is a PCI-DSS and GDPR requirement in most contexts, and a good security practice regardless.
Rate limiting and anomaly detection. Unusual patterns in bank data access — a sudden spike in API calls for a single user's data, access from an unexpected IP, access at unusual hours — should trigger alerts. This is how you detect if a compromised account is being used to exfiltrate financial data.
Our security approach for fintech products covers how we architect secure token storage and access controls as a default pattern, not as a compliance add-on.
Cost of Integration Work in a Typical PFM Project
Bank data integration is typically 15–25% of total PFM development cost, depending on the number of providers, the complexity of the categorisation layer, and the sophistication of the error handling and reconnection flow.
- Single provider integration (Plaid or Tink, one market): €15,000–€30,000. Includes SDK integration, token management, webhook handling, basic error handling, and a simple reconnection flow. Assumes categorisation is passed through from the provider without a custom layer.
- Single provider with custom categorisation layer: €25,000–€45,000. Adds merchant name normalisation, category correction logic, and user correction flows. Significantly improves data quality but adds ongoing maintenance as the merchant database needs to be kept current.
- Multi-provider (two markets): €40,000–€70,000. Adds provider routing, unified data model, separate token management per provider, and coordinated error handling across providers.
- Full PFM integration (multi-provider, custom categorisation, payment initiation): €60,000–€100,000+. Full implementation with all of the above plus payment initiation flows, spending analytics, and the monitoring infrastructure to maintain data quality in production.
These are development costs only. Provider fees — per-user-per-month or per-call — are ongoing operational costs that depend on your user volume and data access frequency. Build both into your unit economics before you sign a provider contract.
For a full breakdown of fintech development costs by feature, see our fintech app development cost guide. To talk through the right provider choice and integration architecture for your specific product, our CTO as a Service engagements include this assessment.
FAQ
Should I use Plaid or Tink for my personal finance app?
It depends almost entirely on where your users are. If your product is US-first, Plaid is the default choice — the deepest US coverage, mature SDKs, and the widest product surface area. If your product is EU-first, Tink or TrueLayer are stronger choices — Tink for broad EU coverage, TrueLayer for UK-primary with EU expansion. If you're building cross-border from day one, you'll likely need both Plaid (for the US) and Tink or TrueLayer (for Europe), which means architecting for multi-provider from the start.
How much does Plaid cost?
Plaid's pricing is per-user-per-month for active connections, plus per-call fees for certain products. The specific numbers are not publicly listed — Plaid provides pricing on request, and it varies by product tier, volume, and contract structure. For an early-stage MVP, expect to pay in the range of $0.30–$0.50 per connected user per month, with the price decreasing at scale. Budget for provider costs as a line item in your unit economics before you sign up — the 'free to start' tier has connection and call limits that you'll hit quickly in production.
What's the difference between screen scraping and open banking API access?
Screen scraping accesses bank data by simulating a user logging into their bank's website — it sends the user's credentials to the bank's login page programmatically and parses the resulting HTML. It's fragile (breaks when the bank changes its login page), has security implications (requires storing or transmitting user credentials), and is increasingly restricted by banks. Open banking API access uses a standardised OAuth flow where the bank directly issues an access token to the third party — no credential storage, more reliable, and the legally mandated approach in the EU and UK under PSD2.
How do I handle users who disconnect their bank from my app?
When a user revokes their bank connection — either through your app or directly through their bank — the provider access token is invalidated. Your system needs to detect this (via webhook or error response), mark the connection as inactive in your database, stop making API calls with that token, notify the user that their connection needs to be re-established if they want to continue using bank-data features, and have a clear UX flow for reconnection. Don't retain or attempt to use tokens that have been revoked — this is a security and compliance issue.
Do I need to be regulated to integrate Plaid or open banking?
In the US, no — Plaid's integration doesn't require you to be a regulated financial institution. Plaid handles the regulatory relationship with the banks. In the UK and EU, accessing bank data under PSD2 requires either being a regulated Account Information Service Provider (AISP) or using a regulated provider (like TrueLayer or Tink) who holds the AISP licence and provides you access under their regulatory umbrella. Most fintech startups in the UK and EU use the latter approach — get a legal review of your specific situation before assuming which applies to you.
How long does a Plaid integration take to build?
A basic Plaid integration — account connection, balance retrieval, transaction sync, basic error handling — takes 3–5 weeks for a competent backend engineer who hasn't integrated Plaid before. A production-quality integration with token management, webhook handling, reconnection flows, custom categorisation, and monitoring takes 8–14 weeks. The difference is in the error handling, the edge cases, and the operational tooling — not the happy path. Budget for the full integration, not just the demo.
Building a personal finance app? See our fintech development services, the mobile banking case study, or talk to us about CTO as a Service for your fintech product.