If you’re building in the EU or UK and Plaid’s per-connection pricing, US data flows, or sandbox friction is pushing you elsewhere, this is what the realistic alternatives look like in 2026 — and the migration gotchas nobody puts on their landing page.
I’ve spent the last year neck-deep in PSD2 bank APIs (I maintain open-banking.io, a small EU aggregator), so this is written from the integration side, not the vendor-marketing side.
Why teams actually switch
The reasons I hear most, roughly in order:
- Pricing opacity at scale. Plaid bills per connected item. Once you’re past a few thousand users doing monthly refreshes, the math starts to hurt — and you can’t easily model it because success-based billing depends on login performance you don’t control.
- Data residency and jurisdiction. EU companies increasingly need EU-processed data flows for procurement or GDPR posture. A US-headquartered aggregator is a harder internal sell than it was five years ago.
- The certificate question. Some teams skip aggregators entirely and go direct-to-bank with their own AISP license — then discover what an eIDAS QWAC certificate costs in money and operational burden, and come back to aggregator APIs. The middle ground (an aggregator that doesn’t push certificates onto you) is where most end up.
The realistic options
A few notes on the main European players, from an integration perspective:
GoCardless (Bank Account Data, ex-Nordigen). The default first stop — free-ish tier, huge bank coverage, and the end of the “Nordigen is free” era. Pricing isn’t published on a public list for the bank-data product; expect a sales conversation. Their API is the Nordigen API you may already know: requisitions, institutions, transactions with interimBooked/booked buckets.
Enable Banking. A solid Finnish aggregator with strong Nordic/Baltic coverage. Sandbox access is self-serve on signup; production pricing is quote-based. One thing to know: their model leans on eIDAS certificate machinery on their side, which they’ve turned into a managed service — good if you want that handled, but ask how much of the cert lifecycle you inherit operationally.
TrueLayer. The biggest EU name in the space. Their public pricing page is gone — it’s a sales-led motion now. Great coverage and docs; overkill if you just need account information for a small app.
Tink (Visa). Enterprise-grade, enterprise-priced, and after Visa’s acquisition the go-to-market is focused on banks and large platforms. If you’re a two-person startup, this probably isn’t your lane.
Salt Edge. Strong if you need coverage beyond EU/UK (they shine in Eastern Europe, MENA, and parts of Asia). Emulator-based connections make coverage claims broader than pure-PSD2 players.
open-banking.io (that’s mine): API-key auth with no certificates to manage, €3/month for your first account and €1/month for each additional (VAT included), zero-knowledge — your users hold their own keys, so the platform can’t read their data. Coverage is the standard EU/UK PSD2 set. It’s small and honest about being small.
The part nobody tells you: migrating connection semantics
This is where Plaid → PSD2 migrations actually hurt. It’s not auth flows or REST clients — it’s that the object model is different in ways that break your sync logic.
Plaid has Items; PSD2 has consents. A Plaid Item is stable until the user revokes it. A PSD2 consent expires — typically after 90 days for SCA-regulated refreshes, sometimes shorter depending on the bank and the initial consent scope. Your sync scheduler needs consent-expiry awareness or you’ll wake up to a wall of 401s every quarter.
Reauthentication mints new identifiers. When a PSD2 consent lapses and the user re-authenticates, many providers issue a new connection/requisition ID for the same real-world bank link. If you keyed your users table on connection ID, you now have duplicates. Key on bank + account number instead, and treat connection IDs as mutable.
Transactions are eventually consistent. Plaid’s webhooks are close to reliable; PSD2 access-provider webhooks range from “decent” to “decorative.” Poll on a schedule, treat webhooks as a nudge, and dedupe on the bank’s stable transaction ID. Pending → booked transitions are an UPDATE, not an INSERT — Plaid models this with pending_transaction_id, and you’ll want the same discipline with PSD2’s interimBooked → booked flow.
Rate limits are bank-imposed. The ~4 unattended pulls per day per consent isn’t an aggregator policy — it’s what several ASPSPs allow for background access without fresh SCA. Budget your refresh cadence around it: a 90-day rolling re-fetch window with dedupe gets you everything a daily full pull would, at a fraction of the budget.
A quick comparison
| Provider | Auth model | Pricing posture | Notes |
|---|---|---|---|
| GoCardless (ex-Nordigen) | API keys | Sales conversation | Huge coverage, the default stop |
| Enable Banking | eIDAS (managed on their side) | Quote-based | Strong Nordics |
| TrueLayer | OAuth flows | Sales-led | Biggest EU name |
| Tink | OAuth flows | Enterprise | Bank-grade, bank-priced |
| Salt Edge | API keys | Quote-based | Best non-EU coverage |
| open-banking.io | API keys, zero-knowledge | €3/mo first account, +€1/mo each, VAT incl | No certificates |
How to choose without a sales cycle
My honest advice for a small team:
- If you’re doing under ~500 connected accounts and just need EU/UK account information: start with the cheapest self-serve option that doesn’t require a call. You can always migrate again — the second migration is easier because you’ll have already fixed your connection-keying and consent-expiry handling.
- If you’re going to production volume: get two quotes and pressure-test the per-connection cost at your realistic refresh cadence, not your current user count.
- Whatever you pick, write your sync layer provider-agnostic from day one: consent expiry, mutable connection IDs, stable-transaction-ID dedupe. That’s 90% of what makes a future switch cheap.
Switching away from Plaid in Europe is genuinely reasonable in 2026 — the PSD2 rails are mature. Just budget for the semantics migration, not just the API client swap.