DEV Community: John Frandsen

Tink Alternatives in 2026: An Honest Developer's Comparison

John Frandsen — Sat, 29 Aug 2026 01:10:59 +0000

Most people searching for a Tink alternative aren't angry at Tink. The coverage is real, the docs are decent, and the API does what it says. The search usually happens for a simpler reason: Tink was bought by Visa in 2022, and the product has drifted upmarket ever since.

I've spent the past two years wiring European bank data into small apps, almost always through an aggregator. Here's my honest take on when it makes sense to move off Tink, and what you actually get when you do.

A note on method: everything below comes from pointing the same small app — list accounts, pull transactions nightly, render a balance — at several of these providers during 2026. I judge them on four things: whether the sandbox works without a signed contract, whether they cover the banks my users actually have, whether pricing survives having fewer than a few thousand users, and how much the consent flow hurts on a phone.

Why developers start looking

Tink's positioning today is an enterprise platform: risk scoring, payment initiation, and account verification sold as bundles to banks and large fintechs. If that's you, none of this is a problem.

If you're a two-person team that just wants to list transactions, the friction shows up early:

Pricing isn't public, so budgeting starts with a sales call rather than a docs page.
The platform is bundled — you're sold payments and risk products alongside the transactions API you actually asked for.
Going from sandbox to production involves commercial review, which is where side projects go to die.

None of this makes Tink bad. It makes Tink a poor fit for anything smaller than a funded company that needs read-only account data this month, not next quarter.

There's also a quieter reason teams move: roadmap risk. When a platform's priorities are set inside a card network, features get built for the network's enterprise needs. Transactions-as-a-commodity for small apps is not that, and it shows in what ships and what gets deprecated.

The alternatives, honestly

GoCardless Bank Account Data (formerly Nordigen). Published pricing, a genuine free sandbox, and solid EU coverage. The catch is availability: signups have been gated in waves since the Nordigen brand was retired, so confirm you can actually get in before you build on it. If you can, it's the default budget choice for EU bank data.

TrueLayer. The strongest UK coverage of the independents and the best payment initiation story. It's also the most enterprise-leaning of the bunch — expect a real sales process before production keys. I wrote a longer piece on choosing an open banking API beyond TrueLayer that goes deeper on when the paperwork is worth it.

Yapily. API-first with no dashboard hand-holding, per-call pricing you can at least see, and wide coverage. Good fit if you're comfortable doing more of the integration yourself and don't want to be sold a platform.

Plaid (in Europe). It works, but you're using their home-market product transplanted across the Atlantic. European bank coverage lags the locals, and per-item pricing in dollars gets odd when your users are all in euros.

The self-hosted route. For small tools this is where I've landed. I maintain open-banking.io, a self-hosted PSD2 aggregator where you hold your own private key so the operator can't read your bank data, and a hobby-scale setup runs around €3/month. The trade is breadth for control: coverage is EU/UK, not global, and you're the one holding the keys in every sense.

Switching costs less than you expect

Every provider above normalizes banks into something close to the Berlin Group shapes, so your core integration is one small family of endpoints: consent, accounts, transactions. Here's the entire read path against most of them:

import requests

r = requests.get(
    f"https://api.aggregator.example/v1/accounts/{account_id}/transactions",
    headers={"Authorization": f"Bearer {access_token}"},
    params={"date_from": "2026-06-01", "date_to": "2026-08-28"},
    timeout=10,
)
for tx in r.json()["transactions"]["booked"]:
    amount = tx["transactionAmount"]["amount"]
    note = tx.get("remittanceInformationUnstructured", "")[:60]
    print(tx["bookingDate"], amount, note)

Swap the base URL and the auth header, and that snippet runs against any aggregator in this list. I've ported this exact loop between three providers; the GET was never the hard part.

The hard part is everything around it: paginating a first sync of several thousand transactions, deduplicating overlaps between windows, and surviving the 90-day consent re-authorization cycle that PSD2 imposes. That pipeline is identical regardless of vendor, and I wrote a full sync guide with the failure modes if you're heading there.

How to actually choose

Rank your banks before you rank your providers. Coverage is the one thing you can't engineer around: if the three banks most of your users sit at aren't well supported, nothing else about a provider matters. Every aggregator here publishes a bank directory — spend ten minutes in it before anything else, because coverage claims in marketing pages and coverage in the directory rarely match perfectly.

Then match the pricing model to your app's shape. Per-connection pricing hurts when your users reconnect often or churn through sandboxes; per-call pricing hurts when you poll nightly for a handful of transactions; minimum commitments hurt everyone under a few thousand users. The cheapest provider for a personal finance tool is rarely the cheapest for a B2B dashboard, and vice versa.

When Tink is still the right answer

If you need payment initiation at volume across many markets, or you want risk and verification products from a single vendor that a bank regulator will recognize, Tink's enterprise direction is a feature, not a bug. A funded fintech should still shortlist it. So should anyone who needs the reassurance of a Visa-owned counterparty in their procurement chain.

For everyone else — the side project, the personal finance tool, the small business dashboard — the instinct that brought you to this search is correct. Just do one thing before you commit: test a real connection to the specific banks your users actually have. Coverage charts look identical on paper across every provider here, and the differences only show up the first time you hit a real bank redirect flow with real credentials.

Disclosure: I maintain open-banking.io, one of the options discussed above. Weigh my bias accordingly.

Open Banking Python Library: What Actually Exists in 2026 (and What I Use Instead)

John Frandsen — Fri, 28 Aug 2026 11:11:20 +0000

When I first needed bank transactions inside a Python app, I did what every developer does. I typed pip install open-banking and hoped for the best. What I found instead was a drawer full of half-maintained wrappers, each tied to one commercial provider. This is the map I wish somebody had handed me back then.

Quick disclosure so you can calibrate my bias: I maintain open-banking.io, a low-cost EU/UK bank-data API. This piece is about the whole landscape, not one product.

What a search for an open banking Python library actually finds

Search PyPI for "open banking" and you get a small pile of packages. The one literally named openbankingapi is thin and hasn't seen meaningful work in years. enablebanking-api is a generated SDK for Enable Banking's commercial API. There are also several community wrappers for the old Nordigen API, none of them official, and most went quiet after GoCardless absorbed Nordigen and rebranded everything under Bank Account Data.

The bigger aggregators do ship real SDKs. Plaid has plaid-python, maintained and fine, but its European coverage has always felt like the B-side of a US-first product. TrueLayer's truelayer-python is decent too, though the company has drifted steadily upmarket toward enterprise clients.

None of these packages is wrong. But none of them is what "open banking Python library" sounds like either. They're all clients for one company's REST API, and the company can vanish or reprice right underneath them. Ask anyone who built on the Nordigen free tier.

Why there's no "requests" of open banking

The dream library would talk to every bank directly. In Europe that can't exist, and the reason is regulatory more than technical.

PSD2 forces thousands of banks to expose APIs, but each bank implements its own flavor, and calling them as a third party requires an eIDAS certificate most indie devs will never want to obtain. So the market settled on aggregators: licensed intermediaries that maintain one clean REST API over hundreds of banks. All the ugly per-bank work happens on their servers.

That's why every Python package you find wraps exactly one aggregator. The aggregator is the library. Python is just the steering wheel.

The three realistic options

Given that, you really have three choices:

Use your provider's official SDK if one exists. Fine, but you inherit their abstractions and their release cadence.
Use a community wrapper. Check the last-commit date first; half of these are weekend projects wearing a README.
Write ~60 lines of requests against the provider's REST API yourself. My usual pick. You understand every line, and switching providers later becomes a base-URL change instead of a rewrite.

I've done all three on real projects. The third ages best.

A minimal client in plain requests

Most aggregator APIs follow the same shape: list banks, start a consent flow, read accounts, read transactions. Here's the entire pattern, anonymized:

import requests

BASE = "https://api.your-ais-provider.example/v2"
H = {"Authorization": "Bearer YOUR_TOKEN"}  # from the provider's dashboard

# 1. Find the user's bank
banks = requests.get(f"{BASE}/banks/", headers=H).json()["results"]
bank_id = next(b for b in banks if "YourBank" in b["name"])["id"]

# 2. Start a consent (requisition) flow — user approves at their bank
req = requests.post(f"{BASE}/requisitions/", headers=H, json={
    "redirect": "http://localhost:8000/callback",
    "institution_id": bank_id,
}).json()
print("Send the user to:", req["link"])

# 3. After they approve and land back on your redirect:
accounts = requests.get(f"{BASE}/requisitions/{req['id']}/", headers=H).json()["accounts"]
tx = requests.get(f"{BASE}/accounts/{accounts[0]}/transactions/", headers=H).json()

That's the core loop for basically every European open banking provider. If a library saves you less code than this, ask what it's actually adding.

The part no library saves you from

The loop above is the easy 20%. The annoying 80% is lifecycle management, and no pip package handles it for you.

PSD2 consents expire — in most countries the user has to re-authenticate roughly every 90 days. Bank connections also break for mundane reasons: password changes, bank maintenance windows, silent schema drift on one specific bank's transaction format. You'll want a small job that checks connection health and tells the user which bank needs attention, in plain language.

Refresh tokens are the other quiet time sink. They expire on their own schedule, per provider, and the failure mode is always a 401 at 2am rather than a clean error. Whatever you build, wrap it in one retry-with-re-auth path early. That's the code I wish I'd written on day one instead of week six.

This is exactly where writing your own thin module pays off. The failure modes are your product decisions, not the library's.

What I check before depending on any of this

Before committing to a provider, and by extension to a library, I look at four things.

Bank coverage in the countries I actually need. Aggregate bank counts are marketing. The list for your two target countries is reality.

Whether the sandbox works without paperwork. If I can't test end-to-end before talking to a sales team, that tells me everything about who the product is really for.

Pricing per bank connection. This varies wildly, from enterprise contracts down to entry tiers around €3/month at the low end. For an indie project, this number decides viability more than any API design choice.

Who holds the keys. Some providers keep everything server-side; others let you hold your own private key so plaintext account data never touches their infrastructure. Worth knowing that option exists before you need it.

What I'd pick

If you just want to see it work this weekend, pick a provider with a no-friction sandbox and write the 60 lines of requests yourself. I wrote a longer walkthrough of doing exactly that with Python — no certificates, real transactions at the end — if you want the full version: reading EU bank transactions with Python and PSD2.

Then wrap those calls in one small module of your own. Congratulations, you now have a private open banking Python library. One you fully control, and one that survives whatever the aggregator market decides to do next.

Plaid Alternatives in Europe - What Actually Changes When You Switch

John Frandsen — Mon, 17 Aug 2026 01:21:45 +0000

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.

Free Signup vs Production Access: What Self-Serve PSD2 Providers Actually Gate

John Frandsen — Sun, 16 Aug 2026 01:15:35 +0000

"Self-serve" is doing a lot of work

Every PSD2 account-information provider markets some version of "get started in minutes." What varies — enormously — is what you can actually do before a human from sales gets involved. There are really three gates:

Signup — can you create an account at all, alone, with an email address?
Sandbox — can you call working APIs before signing anything?
Production — can real users at real banks connect, and under what terms?

A provider can be wide open at gates one and two and still be effectively closed at gate three. That's the trap, and it's why "self-serve PSD2" comparisons deserve more than a feature checkbox.

The field as of August 2026

(From actually attempting the signups, not from reading landing pages.)

Enable Banking is the closest thing to genuine self-serve among the challengers. Email magic-link signup, account auto-created, a sandbox with no contract — and, notably, restricted production access with no contract either, where you can connect your own accounts. Their sandbox is genuinely good: real bank coverage, honest documentation, no credit card. Credit where due.

But the moment your app serves other people — public, customer-facing production — you need a signed contract, KYB (know-your-business) verification, and volume-based billing priced by their sales team via info@enablebanking.com. Perfectly reasonable for a business with a finance function. Not the "self-serve" an indie builder was hoping for.

GoCardless Bank Account Data (formerly Nordigen) — closed to new onboarding since 2025, free tier sunset. The platform that built a thousand side projects no longer takes new independent developers.

TrueLayer — free tier gone, /pricing 404s, and a clear retreat upmarket to enterprise. The live-upgrade path involves sending your client_id to sales.

Tink (Visa) — "Contact Sales" on effectively every page.

Yapily — "Talk to an expert." Same wall.

None of this is misconduct. These are businesses that did the math and stopped subsidizing hobbyists. But if you ARE the hobbyist, the practical reading is: the 2021-era free-open-banking window has closed at the big platforms.

The table

Provider	Signup	Sandbox	Prod (own accounts)	Prod (customers)
Enable Banking	Self-serve, magic link	Free, no contract	Restricted, no contract	Contract + KYB + sales-priced volume
GoCardless Bank Account Data	Closed to new users	—	—	—
TrueLayer	Sales-assisted	Limited	Via sales (send client_id)	Enterprise
Tink	"Contact Sales"	Gated	Sales	Sales
Yapily	"Talk to an expert"	Gated	Sales	Sales
open-banking.io	Self-serve	Yes	Yes — your own bank keys	Yes, from day one (~€3/mo)

How to check the gate yourself in ten minutes

Before you commit a weekend of integration work to any provider, run this diligence pass. It's what produced the table above.

Find the pricing page. Does it exist? A 404 on /pricing tells you the company has stopped caring about small buyers — the funnel starts with a sales call now.
Try the signup with a throwaway email. Magic link in your inbox within a minute = real self-serve. A "we'll be in touch" form = sales-walled, whatever the landing page says.
Search the docs for "production" or "go-live". Read what the upgrade requires. If the words "contract", "KYB", or "contact our team" appear, budget weeks, not minutes.
Check who holds the keys. Do you register with banks yourself and use your own client credentials, or does the provider hold everything? Own keys means you can leave later without re-consenting every user through yet another provider.
Ask what a certificate costs you. If the answer is "nothing, our license covers it", that's the cert-free model. If you're expected to produce a QWAC, that's €2–10k a year you hadn't budgeted.

Ten minutes of this beats three weekends of integration into a platform you'll have to leave.

The decision framework

The real question isn't "who's best" — it's "which gate model does my project need?"

Restricted production (own accounts only) is enough when:

You're building a personal tool — your own budgeting dashboard, net-worth tracker, tax-prep helper
You're evaluating integrations before committing
The only bank accounts that will ever pass through the app are yours

In that world, Enable Banking's model is genuinely a good deal: free, no contract, your real data. I'd use it without hesitation for a personal project.

You need public production the moment:

Anyone who isn't you connects a bank
You charge money for the product
You hand it to a beta group, a friend, or a client

The instant "any real user" exists, restricted-prod models snap you into contracts, KYB paperwork, and sales cycles measured in weeks. Fine if you're at that stage and want negotiated volume pricing. If you're not, it's friction between you and your first ten users — which is where most side projects die.

Price in the certificate tax, too. Going direct rather than through any aggregator usually means eIDAS QWAC/QSealC certificates: €2–10k a year and months of paperwork before your first API call. Some aggregator models (mine included) are structured so the aggregator's license covers that and you never touch a certificate. Know which model you're signing up for before you spend a weekend on integration.

Disclosure

I build open-banking.io — a certificate-free EU/UK PSD2 account-information API. Self-serve signup; you use your own bank-issued client keys, with the aggregator-style license handled for you; about €3/month; new customers are welcome, with public production access from day one. I'm obviously biased, which is why the table above describes competitors as accurately as I can manage — including Enable Banking's genuinely free tier, which fits some of these use-cases better than mine does.

Match the gate model to the use-case. That's the whole article.

Migrating Off Nordigen: A Field Guide for Indie Builders (2026)

John Frandsen — Sat, 15 Aug 2026 01:12:36 +0000

What happened

The short version: the era of free bank data for side projects is over at the big aggregators.

Nordigen — the Latvian open-banking startup that ran a genuinely free account-information API — was acquired by GoCardless in 2022 and is being folded into "GoCardless Bank Account Data". The free tier has been sunset. And GoCardless Bank Account Data itself stopped taking new onboarding back in 2025. As of this writing, there's no indication that access is coming back for new independent developers.

If you built on Nordigen, you already know all this. If you were about to, this article saves you an afternoon of dead-end signup pages.

Who's actually affected:

Budgeting apps pulling balances and transactions nightly
Expense trackers categorizing card spending
Spreadsheet users pushing transactions into Google Sheets
Indie SaaS with a "connect your bank" button that a few hundred real people use

All of these ran fine on a free tier. None of them have a procurement department.

Your realistic options

Three paths, roughly ordered by pain.

1. Direct PSD2 with your own eIDAS certificates

You register as an account information service provider, get through the paperwork, and obtain QWAC and QSealC certificates from a qualified trust service provider. Then you integrate with each bank's API yourself.

Real costs, as of 2026:

QWAC + QSealC certificates: €2,000–€10,000 per year, depending on the trust service provider
Months of paperwork — audit evidence, policy documents, insurance, registration processes
Per-bank overhead — some banks require their own onboarding and certificates on top
Permanent maintenance — you own every bank's API quirks and breaking changes forever

This makes sense if bank connectivity IS your product. It does not make sense for a budgeting app with 40 users.

2. Aggregator with your own bank-issued keys (the cert-free middle path)

Some aggregators handle the licensing and certificate burden themselves and let you bring your own bank-issued client credentials. You register with each bank yourself (usually a web form, often same-day approval), drop the client ID/secret into the aggregator's API, and get one harmonized REST interface across banks. The aggregator does the certificate dance; you never see a QWAC.

You keep the keys, which means you can always go direct later. This is where most ex-Nordigen indies land.

3. Full broker — the aggregator holds everything

The classic enterprise model: the aggregator holds the license, the certificates, and the bank relationships. You never touch a bank credential. In exchange you get sales calls, per-call pricing tiers, and contract cycles. Fine for fintechs; heavy for side projects.

Migration mechanics

Consents do not travel

A PSD2 consent is best understood as OAuth-for-bank-data: the bank issues it to a specific account-information provider, for a specific user, for a limited window. When you switch providers, the consent stays behind. There is no token export. Every end-user re-authorizes through the new provider's flow.

Practical consequences:

Every user re-authenticates once. Plan your comms; expect a dip in connected accounts.
The 90-day clock resets. Recurring-access consents under PSD2 last up to 90 days (180 in some jurisdictions as rules evolve — plan for 90). After migration, day one is day one again.
Nordigen "requisitions" and "end-user agreements" can't be moved or converted. They die with the account.

Historical data: export before you cancel

Most banks serve around 90 days of transaction history per consent window through the API. Some serve more; few serve years. If your old provider cached more history than that, export it before you deactivate the account — raw accounts, balances, transactions, metadata — into storage you control. Don't count on re-fetching two years of history through the new provider; the bank may simply not serve it.

Dedupe: the stable transaction ID

Most banks give transactions a stable ID. Use it as your dedupe key — but hash it together with the booking date:

import hashlib

def dedupe_key(txn):
    raw = f"{txn['transaction_id']}|{txn.get('booking_date', '')}"
    return hashlib.sha256(raw.encode()).hexdigest()

Why hash ID + booking date? Because some banks re-issue the same ID for a corrected transaction with a different date, and you want that to land as a new row, not get swallowed.

Then watch booked vs pending. The same logical transaction typically shows up first as pending and later as booked. Some banks give both entries the same ID; some don't. Two rules that save you:

Ingest pending and booked into a state column (or separate paths), and only count booked rows in financial reports.
Expire pendings older than N days instead of promoting them — card authorizations that get dropped never become booked.

The classic migration bug: re-fetching overlapping windows after the switch, storing pending and booked as separate rows with auto-generated keys, and double-counting a month of groceries.

FITID mapping (QuickBooks / OFX users)

If you push transactions into a .qbo/OFX file or feed, the <FITID> element is the dedupe key on the receiving side. Map it deterministically:

Prefer the bank's transaction ID, sanitized (OFX hates angle brackets and control characters; mind length limits).
If a bank truly gives no usable ID, hash (amount, booking_date, remittance_info) — but identical coffee purchases on the same day will collide, so add a sequence salt.
Never generate FITIDs from a timestamp. QuickBooks will happily import the same transaction every time, forever.

Endpoint mapping

Nordigen's API shape maps almost 1:1 onto a generic PSD2 AIS shape. The renaming: requisition → consent, institution → bank, end-user agreement → consent terms.

import requests

# Nordigen                          ->  Generic PSD2 AIS
# POST /token/new/                      POST /oauth/token
# GET  /institutions/                   GET  /banks
# POST /requisitions/                   POST /consents        (returns an auth URL)
# GET  /requisitions/{id}               GET  /consents/{id}
# GET  /accounts/{id}/balances/         GET  /accounts/{id}/balances
# GET  /accounts/{id}/transactions/     GET  /accounts/{id}/transactions
#      ?date_from=2026-01-01                 ?date_from=2026-01-01&bookingStatus=both

API = "https://api.your-new-provider.example"

tok = requests.post(
    f"{API}/oauth/token",
    auth=(CLIENT_ID, CLIENT_SECRET),
    data={"grant_type": "client_credentials"},
).json()["access_token"]
H = {"Authorization": f"Bearer {tok}"}

# 1. create a consent (was: create a requisition)
consent = requests.post(
    f"{API}/consents", headers=H,
    json={"bank_id": "SANDBOX_TERTIARY_BANK", "redirect_url": REDIRECT_URL},
).json()

# 2. redirect the user to consent["auth_url"], handle the callback
# 3. list accounts and pull transactions with an overlap window

accounts = requests.get(
    f"{API}/accounts", headers=H, params={"consent_id": consent["consent_id"]}
).json()

txns = requests.get(
    f"{API}/accounts/{accounts[0]['id']}/transactions", headers=H,
    params={"date_from": "2026-07-01", "bookingStatus": "both"},
).json()

Pull with an overlapping date window from your last successful sync — your dedupe keys absorb the overlap. For a simple app, this is one to two days of work, minus the gotchas above.

Migration checklist

[ ] Export all cached history from the old provider — before cancelling anything
[ ] Pick a path: own eIDAS certs / own-keys aggregator / full broker
[ ] Re-wire the auth flow; test consent creation + callback in sandbox first
[ ] Add (transaction_id, booking_date) dedupe with a booked/pending state column
[ ] Add FITID mapping if anything downstream speaks OFX
[ ] Migrate users in waves; each re-authorizes exactly once
[ ] Calendar reminder at day ~85: your first 90-day re-consent wave
[ ] Then cancel the old account

One disclosure, so you know who's writing this: I build open-banking.io, a certificate-free EU/UK PSD2 account-information API where you use your own bank-issued client keys (the aggregator-style license is handled for you) for about €3/month — one of the option-2 paths above, and new customers are welcome. Whatever you pick, the mechanics in this guide apply the same way.

Building a Personal Finance App with Open Banking APIs in 2026 (No Certificates Required)

John Frandsen — Wed, 12 Aug 2026 23:09:17 +0000

Building a personal finance app used to mean begging users to paste a CSV export — or worse, to share their banking password with a screen-scraping service. Open Banking was supposed to fix that, and under PSD2 it largely has. Every regulated EU/UK bank now exposes a standard API that returns your balances and transactions as clean JSON, with your explicit consent.

So why isn't every indie developer shipping a net-worth dashboard on top of it?

Because the "official" path to those APIs requires an eIDAS qualified certificate (QWAC + QSeal), a regulator licence, and weeks of compliance paperwork. That's the wall most tutorials quietly skip. This one doesn't. We'll cover how PSD2 APIs actually work, why the certificate requirement blocks indie builders, and then build a working personal-finance tracker end-to-end using a certificate-free provider — with real curl and Python you can run today.

What an "Open Banking API" actually means

Two pieces of jargon do most of the heavy lifting, and clearing them up front will save you hours:

PSD2 is the EU directive (second Payment Services Directive) that forced banks to open up customer data to licensed third parties, on the customer's request. The UK's Open Banking standard is the local implementation of the same idea.
AISP / PIS — an Account Information Service reads data (balances, transactions); a Payment Initiation Service can move money. For a personal finance app you only ever need AIS. That's read-only by law.

The thing that makes Open Banking safe — and the thing that makes it annoying to set up — is the consent redirect flow. Your app never sees the user's bank password. Instead:

Your app asks the API provider to start a connection for, say, "Nordea" or "Lunar".
The provider redirects the user to their own bank's login page (the bank's domain, the bank's TLS).
The user logs in there and approves a scoped consent (e.g. "read balances and transactions for 90 days").
The bank redirects back to your app with an authorisation code.
Your app exchanges that code for access/refresh tokens and can now poll the data API.

At no point do you touch credentials. The bank hands you a token with a defined scope and an expiry.

The certificate wall (and why it blocks indie builders)

Here's the part the vendor docs bury. To call a bank's PSD2 API directly, as your own licensed third-party provider (TPP), you must present a QWAC (Qualified Website Authentication Certificate) and a QSeal (Qualified Electronic Seal) — collectively the eIDAS qualified certificates. You get those by:

Becoming an authorised AISP with your national regulator (the FCA in the UK, Finanstilsynet in Denmark, BaFin in Germany, etc.).
Passing audits and maintaining a compliance programme.
Buying the certificates from a qualified trust service provider — typically €1,000–€6,000/year, plus setup.

For a bank or a funded fintech, that's Tuesday. For an indie developer who just wants to build a net-worth dashboard over the weekend, it's a non-starter. So either you give up, or you use an aggregator that is already licensed and lets you ride on its authorisation — handing you a simple API key instead of a certificate.

That second option is the pragmatic one, and it's what the rest of this tutorial uses.

The certificate-free approach

A handful of providers are already licensed AISPs and expose their aggregated API to you behind a plain API key. They hold the certificates; you hold a key. You still go through the bank's consent redirect — the security model is identical — but you skip the licensing and certificate procurement entirely.

The provider used in the code below is open-banking.io (full disclosure: it's a service I built, which is exactly why I can show you the cheapest path). It's certificate-free, costs €3/month for one account, and connects to EU/UK banks. The pattern — API key, consent flow, JSON data — is the same one you'll see at Yapily, Tink, TrueLayer, or Enable Banking; the difference is the absence of certificates and the price tag. Adapt the code to whichever provider you pick.

Now let's build something.

Step 0 — Get API access (no certificates, ~2 minutes)

Create an account and connect a real bank through the consent redirect described above.
Generate an API key and export a credentials.json bundle. The bundle pairs your API key with your private decryption key (more on why in the security section).

There is no eIDAS step. There is no audit. You authenticate every request with a single header:

curl -H "X-Api-Key: $OBIO_API_KEY" https://open-banking.io/api/accounts

That's the entire auth model. No OAuth client-secret dance on your side, no mTLS, no certificate rotation.

Step 1 — List accounts and balances (Python)

Install the Python client (or just use httpx against the raw REST endpoint — your call):

pip install open-banking-io

Then list every connected account with its booked balance:

from open_banking_io import OpenBankingClient

with OpenBankingClient.from_credentials("credentials.json") as client:
    for account in client.get_accounts():
        booked = next((b for b in account.balances if b.type == "ITBD"), None)
        label = account.display_name or account.owner_name
        print(f"{label} ({account.iban}): {booked.amount} {account.currency}")

Run it and you get something like:

Drift (DK64 6466…4927): 12482.55 DKK
Salary (DK21 3000…8841): 828.13 DKK
Buffer (DK90 5301…2207): 34010.00 DKK

Two things worth noting. First, balances come in types (ITBD = interim booked, CLBD = closing booked, XPCD = expected, etc.) — always pick the one that matches your use case. "Booked" is the safe default for a net-worth figure because it excludes pending authorisations. Second, amount is a decimal.Decimal, not a float — keep it that way or you'll silently lose pennies to floating-point error. This trips up a lot of finance apps.

Step 2 — Pull and paginate transactions

def load_txns(client, account_id, page_size=200):
    txns, offset = [], 0
    while True:
        page = client.get_transactions(account_id, limit=page_size, offset=offset)
        txns.extend(page.items)
        if len(page.items) < page_size:
            break
        offset += page_size
    return txns

with OpenBankingClient.from_credentials("credentials.json") as client:
    all_txns = []
    for acct in client.get_accounts():
        all_txns.extend(load_txns(client, acct.id))
        print(f"Loaded {len(all_txns)} transactions from {acct.display_name or acct.iban}")

The PSD2 transaction schema (Berlin Group NextGenPSD2) is verbose by design: a single payment carries creditorName, debtorName, remittanceInformationUnstructured, transactionAmount, bookingDate, valueDate, and more. Normalise it once into your own flat shape and never look at the raw schema again:

def normalise(t):
    counterparty = t.creditor_name or t.debtor_name or "Unknown"
    return {
        "date": t.booking_date,
        "counterparty": counterparty.strip(),
        "amount": t.amount,     # Decimal; money in is positive, out is negative
        "currency": t.currency,
    }

Step 3 — Turn raw transactions into insights

This is where your app actually adds value. The API gives you rows; your job is insight. A few primitives get you most of the way:

from collections import defaultdict
from decimal import Decimal

income, spend = Decimal("0"), Decimal("0")
by_counterparty = defaultdict(Decimal)

for t in all_txns:
    n = normalise(t)
    by_counterparty[n["counterparty"]] += n["amount"]
    if n["amount"] > 0:
        income += n["amount"]
    else:
        spend += -n["amount"]

print(f"Income:       {income:>12,.2f}")
print(f"Spending:     {spend:>12,.2f}")
print(f"Net cashflow: {(income - spend):>12,.2f}\n")
print("Top 5 spenders:")
for name, amt in sorted(by_counterparty.items(), key=lambda kv: kv[1])[:5]:
    print(f"  {name:30s} {amt:>10,.2f}")

That's a real, working spend tracker. From here the usual next steps are obvious: bucket by month, flag recurring subscriptions (same counterparty, same amount, ~30-day cadence), raise an alert when income drops, and project a 30-day balance forecast. None of that needs the bank API at all — you already have clean, signed, normalised data.

Step 4 — Schedule a daily sync and cache

You don't want to hit the bank on every page load. The standard pattern is a daily server-side job that pulls fresh transactions into your own database; your frontend reads from your DB, not the bank.

# cron / scheduled job — run once per day
with OpenBankingClient.from_credentials("credentials.json") as client:
    client.sync_all()           # refresh every connected account from the bank
    for acct in client.get_accounts():
        for t in load_txns(client, acct.id):
            upsert_into_db(t)   # idempotent insert keyed on the transaction id

sync_all() triggers an online refresh; get_transactions() then returns the latest rows. Keep the credentials bundle server-side only (see below) and you have a textbook ETL: bank → provider → your DB → your app.

Security: zero-knowledge, and why it matters for a finance app

A personal finance app is a high-trust product. Two security properties are worth understanding before you ship:

The consent layer is bank-enforced. Read-only is not a setting in your code — it's a legal scope the bank grants at consent time. Your token simply cannot initiate a payment if you only asked for AIS. That's a much stronger guarantee than a "we promise not to move money" checkbox.
End-to-end encryption / zero-knowledge. The better providers don't store your data in a form they can read. open-banking.io, for example, encrypts every account and transaction envelope under a key derived from your private key (ECDH P‑256 → HKDF‑SHA256 → AES‑256‑GCM). The server holds ciphertext it cannot decrypt; decryption happens in your client process, using the private key from your credentials.json. If the provider is breached, the attacker gets sealed blobs.

Practical implication: the credentials.json bundle contains your private decryption key. Never ship it to a browser, a mobile app, or a public repo. Keep it on your server — ideally as a Kubernetes Secret or a secrets manager, mounted read-only:

kubectl create secret generic obio-credentials \
  --from-file=credentials.json=./open-banking.io-credentials-2026-08-12.json

A word on cost

Most aggregators price for enterprise: per-connection fees in the euros, minimum commits, sales calls. That's fine if you're a funded startup, brutal if you're an indie. The certificate-free providers sit at the cheap end of the spectrum — open-banking.io is €3/month for one account and €1/month per additional account, no minimum. When you pick a provider, model your cost per active user, because transaction volume and connection count are where the bill climbs.

What you've got

At this point you have:

A way to read bank data without an eIDAS certificate or a licence.
A consent flow that's bank-enforced and read-only by law.
Clean, normalised transactions to build any insight on top of.
A daily-sync ETL pattern with zero-knowledge encryption.

That's the complete foundation of a personal finance app — net worth, cashflow, subscription tracking, the lot — built on PSD2 APIs without touching the certificate wall. The hard part of fintech isn't the data plumbing any more; it's the product you build on top of clean data. Go build something worth using.

Disclosure: I'm the developer behind open-banking.io, which is why I can point you at the cheapest, certificate-free path. The architecture in this post works with any PSD2 aggregator — swap the SDK and API key for Yapily, Tink, TrueLayer, or Enable Banking and the same steps hold.

The Best Plaid Alternative in Europe (2025): A Developer's Guide to PSD2 APIs

John Frandsen — Tue, 11 Aug 2026 13:11:53 +0000

If you've tried to build a European fintech app on top of Plaid, you've probably hit the same wall as everyone else: Plaid's European (UK/EU) coverage is thin, and it isn't really a PSD2-native product. That sends a lot of developers searching for a Plaid alternative in Europe — one that speaks the EU's Open Banking protocol natively, covers the right banks, and ideally doesn't bury you in compliance paperwork.

This article is a practical, code-first comparison of the main options for accessing bank account data (balances, transactions, account details) across the UK and EU. I'll show you what each provider actually gives you as a developer, what the eIDAS certificate situation is (this matters more than you'd think), and working curl, Python, and JavaScript examples you can run today.

Disclosure up front: I'm involved with open-banking.io, a certificate-free PSD2 API that's one of the options in this comparison. I'll mark that clearly when it comes up, but the code patterns and the comparison below apply to whichever provider you choose.

Why developers look for a Plaid alternative in Europe

Plaid is excellent in the US. In Europe it's a different story. A few concrete reasons European teams move off (or never start with) Plaid:

Bank coverage gaps. Plaid's European coverage relies on integrations that are often thinner than local PSD2 aggregators. Many mid-tier and regional banks in Germany, France, Spain, and the Nordics are missing or unreliable.
Not PSD2-first. Plaid's API shape was designed for the US banking model. PSD2's Account Information Service (AIS) flow — with strong-customer-authentication (SCA) redirects, consent, and 90-day re-auth — fits awkwardly on top.
Pricing. Plaid's per-call / success-based pricing can get expensive for use cases that poll balances or sync transactions frequently (accounting, expense, lending underwriting).
Licensing friction. Pure TPP (Third Party Provider) aggregators that operate under their own eIDAS certificate are the native model in the EU. Plaid doesn't sit cleanly in that category.

The good news: under PSD2 (Payment Services Directive 2), every bank in the EEA and the UK is legally required to expose a free, standardized API for account information. That means there's a healthy market of PSD2-native aggregators, and you have real choices.

What "PSD2-native" actually means (and why the eIDAS certificate matters)

Before the comparison, one concept that trips up a lot of teams:

To call a bank's PSD2 API directly, a third party is supposed to hold an eIDAS QWAC (Qualified Website Authentication Certificate) — an expensive, audit-heavy certificate issued by a Qualified Trust Service Provider. Banks use it to verify the caller is a licensed TPP.

In practice, this means:

DIY path: You register as a TPP with your national regulator, go through audits, buy a QWAC (roughly EUR 1,000-6,000/year), and integrate each bank's API individually. Months of work.
Aggregator path: You use a provider (Yapily, Tink, Enable Banking, etc.) that already holds the eIDAS certificate and has done the per-bank integrations. You just call their API.

Almost all aggregators require you to either bring your own eIDAS certificate or operate under theirs with KYB/onboarding overhead. One notable exception is open-banking.io, which is built specifically to remove the certificate requirement for AIS use cases — more on that in the comparison.

Requirement	DIY PSD2	Typical aggregator	open-banking.io
eIDAS QWAC certificate	Required (you buy it)	They hold it; you do KYB	Not required
Per-bank integration	You build each one	Done for you	Done for you
TPP license	Required	They hold it	Not required for AIS
Time to first API call	Weeks-months	Days (after onboarding)	Minutes

The main Plaid alternatives in Europe: compared

Here's an honest, developer-eye-view comparison. I'll cover each in more detail below.

Provider	Coverage	Auth model	Requires eIDAS cert?	Pricing model	Best for
Yapily	UK + EU (strong)	Yapily-hosted consent	Yes (KYB onboarding)	Per successful AIS call	Enterprise, lending
Tink (Visa)	Pan-European	Tink-hosted / app-2-app	Yes	Volume tiers, enterprise	Large fintechs
Enable Banking	Nordics + EU	Redirect/decoupled	Yes	Per-call	Nordic-focused apps
Nordigen (GoCardless)	EU + UK (free tier)	Redirect	Free tier has limits	Freemium then paid	MVPs, small apps
open-banking.io	EU + UK	Certificate-free HTTP	No	Simple tiers	SMB tools, accountants, fast prototyping
Plaid (EU/UK)	Partial EU/UK	Plaid-link	n/a (US-centric)	Per-call/success	US-first products

A note on each

Yapily is probably the most frequently cited Plaid alternative in Europe for a reason: solid coverage, a clean REST API, and a real TPP license. The trade-off is enterprise-grade onboarding (KYB, contract) and per-call pricing that adds up at scale.

Tink (now owned by Visa) has excellent coverage and the nicest developer UX in the enterprise tier. The cost and procurement process reflect that positioning.

Enable Banking is the go-to if you're focused on the Nordics; they have deep coverage there and a straightforward API.

Nordigen / GoCardless offers a genuinely free tier, which makes it attractive for MVPs. The free tier has bank and call limits, and you graduate to paid pricing as you grow.

open-banking.io is the one I'm closest to. Its wedge is being certificate-free: you can start calling AIS endpoints without buying a QWAC or going through TPP-style onboarding. That makes it useful for SMB tools, accounting integrations, and prototyping where you don't want compliance to be the long pole.

The flow every European open banking API shares

Whichever provider you pick, the end-to-end flow for reading a user's bank data looks roughly like this:

Create a consent / session — you tell the provider which bank and what scopes (accounts, balances, transactions).
Redirect the user to SCA — under PSD2, the user authenticates at their bank (redirect or decoupled/app-to-app). This satisfies Strong Customer Authentication.
Exchange the auth code for an access token (or the provider gives you a session/requisition ID).
Fetch data — accounts, balances, transactions — over the next ~90 days until re-consent is required.

Let's see that in code.

Code examples

The examples below use open-banking.io's API shape (HTTP/JSON, bearer token) because it's what I can show end-to-end here. The structure is nearly identical for Yapily, Tink, and others — only the endpoint names and auth details differ.

1. Initialize a bank session (consent)

# Create a session for a German bank account (read-only AIS)
curl -X POST https://api.open-banking.io/v1/sessions \
  -H "Authorization: Bearer $OBI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "bank": "DEUTSCHE_BANK",
    "country": "DE",
    "scopes": ["accounts", "balances", "transactions"],
    "redirect_url": "https://yourapp.example.com/callback"
  }'

Response (abbreviated):

{
  "session_id": "sess_01HZX...",
  "status": "awaiting_authentication",
  "auth_url": "https://auth.open-banking.io/authorize?session=sess_01HZX..."
}

You redirect your user to auth_url. They authenticate with their bank (SCA), and you're called back at redirect_url.

2. List accounts

import os, requests

token = os.environ["OBI_TOKEN"]
session_id = "sess_01HZX..."
headers = {"Authorization": f"Bearer {token}"}

accounts = requests.get(
    f"https://api.open-banking.io/v1/sessions/{session_id}/accounts",
    headers=headers,
).json()

for acct in accounts["data"]:
    print(acct["iban"], acct["name"], acct["currency"])

3. Fetch balances and transactions

// Node 18+ (built-in fetch)
const token = process.env.OBI_TOKEN;
const sessionId = "sess_01HZX...";
const headers = { Authorization: `Bearer ${token}` };

// Balances
const balances = await fetch(
  `https://api.open-banking.io/v1/sessions/${sessionId}/accounts/acc_123/balances`,
  { headers }
).then((r) => r.json());

console.log("Available balance:", balances.data[0].balanceAmount.amount);

// Transactions (last 30 days)
const txns = await fetch(
  `https://api.open-banking.io/v1/sessions/${sessionId}/accounts/acc_123/transactions?date_from=2025-07-11`,
  { headers }
).then((r) => r.json());

for (const t of txns.data) {
  console.log(t.bookingDate, t.transactionAmount.amount, t.remittanceInformationUnstructured);
}

4. A complete Python helper

Here's a small reusable client you can adapt:

import os, requests
from datetime import datetime, timedelta

class OpenBankingClient:
    BASE = "https://api.open-banking.io/v1"

    def __init__(self, token=None):
        self.token = token or os.environ["OBI_TOKEN"]
        self.s = requests.Session()
        self.s.headers["Authorization"] = f"Bearer {self.token}"

    def create_session(self, bank, country, redirect_url):
        r = self.s.post(
            f"{self.BASE}/sessions",
            json={
                "bank": bank,
                "country": country,
                "scopes": ["accounts", "balances", "transactions"],
                "redirect_url": redirect_url,
            },
        )
        r.raise_for_status()
        return r.json()

    def accounts(self, session_id):
        r = self.s.get(f"{self.BASE}/sessions/{session_id}/accounts")
        r.raise_for_status()
        return r.json()["data"]

    def transactions(self, session_id, account_id, days=30):
        since = (datetime.utcnow() - timedelta(days=days)).date().isoformat()
        r = self.s.get(
            f"{self.BASE}/sessions/{session_id}/accounts/{account_id}/transactions",
            params={"date_from": since},
        )
        r.raise_for_status()
        return r.json()["data"]

# Usage
client = OpenBankingClient()
session = client.create_session("REVOLT", "GB", "https://app.example.com/cb")
# ... user completes SCA at session["auth_url"] ...
for acct in client.accounts(session["session_id"]):
    txns = client.transactions(session["session_id"], acct["id"])
    print(f"{acct['iban']}: {len(txns)} transactions")

Tip: Always treat the auth_url redirect as the SSA/SCA boundary. Don't try to cache or replay user bank credentials — under PSD2 you must never see them. That's the whole point of the redirect flow.

How to choose: a decision guide

If you're not sure which Plaid alternative in Europe fits your project, use this rough guide:

You're an enterprise / regulated fintech doing lending at scale → Yapily or Tink. Budget for onboarding and per-call pricing.
You're Nordic-focused → Enable Banking.
You're building an MVP and want free to start → Nordigen's free tier, then re-evaluate.
You're building SMB tooling, an accountant integration, or a prototype — and you want to skip the eIDAS certificate and TPP onboarding entirely → open-banking.io.
You're US-first and only need light EU coverage → Plaid may still be the pragmatic choice.

The single biggest differentiator to interrogate during evaluation is the certificate/onboarding requirement. If a one-week procurement delay kills your project, that narrows the field considerably.

Pitfalls to avoid when switching from Plaid

A few things that bite people moving off Plaid onto a PSD2-native provider:

90-day re-authentication. PSD2 requires re-consent every 90 days for AIS. Plaid abstracts this differently than PSD2 aggregators do; plan your UX around re-auth reminders.
Transaction field variance. The Berlin Group NextGen PSD2 schema (used across much of the EU) has rich but unevenly-populated fields. remittanceInformationUnstructured is where payer names/reference often live — but not every bank fills it.
Sandbox vs. production coverage gaps. A bank present in a provider's sandbox may behave differently in production. Test on real (small) accounts early.
Rate limits per bank. Some banks rate-limit TPP calls aggressively. Cache responses where it makes sense and respect Retry-After.
Currency and timezone on transactions. Always read both transactionAmount (with currency) and bookingDate vs. valueDate — they differ and matter for reconciliation.

Official references

PSD2 Directive: Directive (EU) 2015/2366 — the foundational directive.
RTS on SCA and CSC: Commission Delegated Regulation (EU) 2018/389 — defines strong customer authentication and the 90-day AIS re-consent rule.
Berlin Group NextGen PSD2: the Open API standard most EU banks implement — berlin-group-ngp.
UK Open Banking Standard: openbanking.org.uk — the UK's reference implementation and API specs.
EBA Guidelines on PSD2: the European Banking Authority's technical guidance on API access.

Summary

A good Plaid alternative in Europe is one that treats PSD2 as a first-class citizen: native SCA flows, real coverage of EEA + UK banks, and a licensing model that doesn't drown you in paperwork. Yapily, Tink, Enable Banking, and Nordigen are all legitimate picks depending on your scale and region. And if your use case is SMB tooling, accounting integration, or fast prototyping where the eIDAS certificate requirement is the bottleneck, open-banking.io is purpose-built to remove exactly that friction.

Whichever you pick, the underlying PSD2 guarantees are the same: standardized access to account information, balances, and transactions across the entire EU and UK — no scraping, no credentials sharing, fully consented.

If you found this useful, I write about open banking and fintech engineering here on dev.to. Questions or war stories from your own integration? Drop them in the comments.

This article was written by johnfrandsen. I'm involved with open-banking.io, which is mentioned in the comparison above. The technical content and code patterns are applicable across providers.

PSD2 Consent Expiry vs Token Refresh: Why Your Bank Connection Stops After 90 Days

John Frandsen — Thu, 06 Aug 2026 15:18:33 +0000

You refresh your OAuth tokens on schedule. Your token endpoint returns 200s. Your job is green. And yet — at almost exactly 90 days, a chunk of your users' bank connections silently stop pulling transactions. The error rate ticks up at the same interval for everyone, regardless of when they last logged in. Token refresh is healthy, so what expired?

This is the single most common operational mystery in open-banking integrations, and the reason it's confusing is that PSD2 runs three independent timers, and most developers only reason about one of them. If you've only ever thought about OAuth access-token lifetime, you'll find that 90-day cliff inexplicable — because that one timer never reaches 90 days.

Let me untangle the three timers, the regulatory citations behind them, and how to tell them apart at runtime so you can recover correctly instead of blindly retrying.

The three timers at a glance

#	Timer	Set by	Typical duration	Recovery when it lapses
1	OAuth access token	ASPSP token endpoint	seconds–hours	Silent `refresh_token` exchange, no user
2	Consent `validUntil`	PSU (capped by bank, often 90d)	30–180 days	Re-grant consent; silent if SCA still fresh
3	SCA re-authentication window	PSD2 RTS, hard cap ≤180 days	≤180 days	Redirect PSU to bank for strong authentication

The first one is OAuth as you know it. The other two are PSD2-specific and they are the timers that actually explain your 90-day problem. The trick is that token refresh cannot extend timer 2 or 3. A refresh gets you a new bearer token for a consent that itself is expiring, or for an SCA session that has gone stale.

Timer 1 — The access token (the one you already know)

When the PSU finishes the redirect flow, your ASPSP hands you a Bearer access_token plus, usually, a refresh_token. The access token is what you put in the Authorization: Bearer … header on /accounts, /balances, /transactions. Per the Berlin Group NextGenPSD2 Implementation Guidelines, this token's lifetime is implementation-defined and typically short — minutes to a couple of hours — because it's bound to a single consent and a single SCA session.

Refreshing it is the easy part:

def refresh_access_token(refresh_token: str) -> dict:
    r = httpx.post(
        f"{ASPSP_BASE}/as/token.oauth2",
        data={
            "grant_type": "refresh_token",
            "refresh_token": refresh_token,
        },
        auth=(CLIENT_ID, CLIENT_SECRET),   # or private_key_jwt
        headers={"Content-Type": "application/x-www-form-urlencoded"},
        timeout=15,
    )
    r.raise_for_status()
    return r.json()  # {"access_token": ..., "expires_in": 600, "refresh_token": ...?}

Two things to internalize:

refresh_token rotation is common. Many ASPSPs issue a new refresh token on every refresh and invalidate the old one. If you replay an old refresh token you'll get a 400. Persist the new one before you consider the refresh successful.
Refresh only ever gives you more access tokens for the same consent. It does not extend the consent's validUntil, and it does not reset the SCA clock. This is why a healthy refresh job doesn't prevent the 90-day cliff.

Timer 2 — Consent `validUntil` (this is your 90-day problem)

A consent in PSD2 is the PSU's authorization for you (the AISP) to read their account data. It is a first-class object on the bank's side, identified by consentId, with a lifecycle (received → valid → expired | revokedByPsu | terminatedByTpp). Every consent carries a validUntil date — the day after which the bank will refuse all access even if your token is technically valid.

This is the timer that defaults to 90 days at most ASPSPs, and it's the one that produces your synchronized error spike. Where does 90 days come from? Two places:

PSU control. Under PSD2 Article 66, the PSU sets (or accepts a default for) the consent's validity period. Many banks simply default validUntil to 90 days from creation.
National transposition and scheme defaults. UK Open Banking's original CMA9 requirements centred on 90-day re-authentication. German BaFin-influenced implementations, Polish, and several Nordic banks also default to 90. Some go as low as 30.

The PSD2 RTS itself does not mandate 90 days. The RTS ceiling is 180 days (see Timer 3). The 90-day value is a pervasive default, not a legal maximum — but because so many banks ship that default, 90 days is the number you'll see in production.

When validUntil passes, you get an explicit, distinguishable failure. NextGenPSD2 ASPSPs return it as a 403 with application/problem+json (RFC 7807) and a tppMessages array containing CONSENT_EXPIRED. The consent resource's status flips to expired. A refresh_token grant will still succeed against the token endpoint, and you will still get a brand-new access token — but every AIS call with that token returns 403. This is the exact trap: "my token refresh works, but every data call fails."

The recovery is re-grant the consent, which — critically — may or may not require the user to re-authenticate, depending on Timer 3.

Timer 3 — SCA re-authentication (the hard wall PSD2 imposes)

Strong Customer Authentication (SCA) is the act of the PSU proving their identity to their bank (two-factor: something they know + have + are). PSD2's Regulatory Technical Standards — Commission Delegated Regulation (EU) 2018/389, Article 10 — set the maximum interval between two SCAs for account-information access at 180 days. In plain terms: an ASPSP is permitted to not re-challenge the PSU with SCA for up to 180 days after the last SCA, and after 180 days a fresh SCA is mandatory.

This is the one timer that is legally fixed, bank-independent, and uncrossable by any background process. No amount of token refreshing or consent re-granting lets you cross 180 days without the PSU doing strong authentication again.

Here's the subtle part that ties it to Timer 2: a consent can be technically valid (not past validUntil, not revoked) while its SCA is stale. So you can hit two different failures against the same consent:

Consent past validUntil → CONSENT_EXPIRED (re-grant; silent if SCA fresh)
SCA older than 180 days → the bank forces an SCA on the next consent grant → you must redirect the PSU

The interaction is what trips people up. Many banks deliberately set validUntil = 90 days so that consent renewal always happens well inside the 180-day SCA window, which lets renewal be a silent one-tap re-approval rather than a full redirect. That's the UX-friendly interpretation of "90 days." But if you configured a longer validUntil (e.g., 170 days to minimise user friction), the renewal will collide with the SCA window and force a redirect + 2FA on the PSU. You traded frequency for friction and lost on both.

A reasonable rule of thumb: treat 90 days as the renewal cadence and 180 days as the cliff you must never reach. Renew at day ~80, and you'll always be inside the SCA window, which lets renewal be silent or one-tap.

Reading the signals: which timer just fired?

The cheapest debugging win is mapping the HTTP response to the responsible timer, because each has a different recovery path. ASPSPs conforming to NextGenPSD2 return errors as RFC 7807 problem documents:

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json

{
  "type": "https://example.com/errors/forbidden",
  "title": "Consent expired",
  "status": 403,
  "tppMessages": [
    { "category": "ERROR", "code": "CONSENT_EXPIRED",
      "text": "The consent used is expired." }
  ]
}

HTTP status	`tppMessages.code`	Timer fired	Recovery
401	`TOKEN_INVALID` / `TOKEN_EXPIRED`	1 — access token	Refresh silently
403	`CONSENT_EXPIRED`	2 — `validUntil`	Re-grant consent (silent if SCA fresh)
401/403	`CONSENT_INVALID` / `CONSENT_STATUS_INVALID`	2 — revoked/terminated	Re-grant; expect SCA
403	`CONSENT_UNKNOWN`	bad `consentId`	Re-grant
401 (on consent grant)	SCA required	3 — SCA >180d	Redirect PSU to bank

The status code alone is not enough — a 401 from a token-endpoint failure means something different from a 401 on an AIS endpoint. Always parse tppMessages.code; that's the contract NextGenPSD2 gives you to disambiguate.

A recovery orchestrator

Here's the pattern I use to keep this sane: one wrapper that classifies the failure and routes to the correct recovery, instead of scattering retry logic across call sites.

import httpx, time
from dataclasses import dataclass
from enum import Enum

class Recovery(str, Enum):
    RETRY = "retry"                 # transient; just call again
    REFRESH_TOKEN = "refresh"       # timer 1
    REGRANT_CONSENT = "regrant"     # timer 2
    USER_ACTION_SCA = "user_sca"    # timer 3

@dataclass
class ConsentState:
    consent_id: str
    valid_until: float              # epoch
    last_sca_at: float              # epoch
    access_token: str
    access_token_exp: float         # epoch
    refresh_token: str

def classify(resp: httpx.Response, state: ConsentState) -> Recovery:
    codes = {m["code"] for m in resp.json().get("tppMessages", [])}
    if resp.status_code == 401 and (codes & {"TOKEN_INVALID", "TOKEN_EXPIRED"}):
        return Recovery.REFRESH_TOKEN
    if codes & {"CONSENT_EXPIRED"}:
        # consent's validUntil has passed; re-grant.
        # Whether the PSU must do SCA depends on timer 3:
        if time.time() - state.last_sca_at > 170 * 86400:
            return Recovery.USER_ACTION_SCA
        return Recovery.REGRANT_CONSENT
    if codes & {"CONSENT_INVALID", "CONSENT_UNKNOWN", "CONSENT_STATUS_INVALID"}:
        return Recovery.USER_ACTION_SCA     # revoked or corrupted; full re-grant safest
    if resp.status_code >= 500:
        return Recovery.RETRY
    raise RuntimeError(f"unhandled: {resp.status_code} {codes}")

The key design decision: CONSENT_EXPIRED does not unconditionally mean "redirect the user." It only means the user must re-authenticate if SCA is also stale (timer 3). If SCA is fresh, re-granting the consent can be a server-to-server call that returns a new consentId without ever bouncing the PSU to their bank. That's the difference between a 0.1% drop-off and a 20% drop-off on renewal day.

The companion function does the refresh side, so the call site stays clean:

def call_ais(state: ConsentState, path: str) -> dict:
    for attempt in range(4):
        if time.time() > state.access_token_exp - 30:
            _refresh(state)                        # timer 1, proactive
        r = httpx.get(f"{ASPSP_BASE}{path}",
                      headers={"Authorization": f"Bearer {state.access_token}",
                               "Consent-ID": state.consent_id},
                      timeout=20)
        if r.status_code == 200:
            return r.json()
        match classify(r, state):
            case Recovery.REFRESH_TOKEN:    _refresh(state); continue
            case Recovery.RETRY:            time.sleep(2 ** attempt); continue
            case Recovery.REGRANT_CONSENT:  _regrant(state); continue
            case Recovery.USER_ACTION_SCA:  raise NeedsUserAction(state.consent_id)

NeedsUserAction is the signal to your higher layer to send a notification ("tap here to reconnect your bank") instead of looping forever in the background.

Don't wait for the user to hit the error

The mistake that produces the synchronized 90-day cliff is reactive renewal. If you only re-grant when a read call fails, then every PSU who consented in the same onboarding wave hits CONSENT_EXPIRED within the same week, and they all get a reconnect prompt at once — usually in a batch that overwhelms whatever SCA capacity the bank has, and always at a worse UX moment than the original onboarding.

The fix is a scheduled sweeper that renews each consent ~10 days before whichever timer is closer to lapsed:

def sweep(due_soon_days: int = 10):
    for state in consent_store.iter():
        d_to_consent = state.valid_until - time.time()
        d_to_sca     = state.last_sca_at + 180*86400 - time.time()
        d = min(d_to_consent, d_to_sca)
        if d < due_soon_days * 86400:
            if d == d_to_sca:
                notify_user(state, "reconnect")     # timer 3: needs SCA, user must act
            else:
                _regrant(state)                     # timer 2: silent renewal

Now renewals spread out across the calendar because they're driven by each PSU's individual consent timestamp, and the SCA-bound ones get queued for the user instead of crashing a read call.

Why banks vary so much

A short, non-exhaustive map of the defaults you'll actually hit:

Region / scheme	Typical `validUntil` default	Notes
UK (CMA9, OBIE)	90 days	Historical re-auth cadence; FCA aligned SCA ceiling to RTS 180d
Germany (Berlin Group)	90 days	Common; some Sparkassen allow up to 180
Nordics	90–180 days	Decoupled flows common
Poland (Polish API)	up to 180 days	Often closer to the RTS ceiling
France (STET)	90–180 days	Bank-dependent

Always read the specific ASPSP's documentation for both validUntil policy and whether refresh-token rotation is enabled. They differ per bank even within the same scheme, and they're the two settings that break naive integrations.

The mistakes I see most often

Treating 401 and 403 as "token expired." A CONSENT_EXPIRED 403 is not a token problem; refreshing won't help and will waste your rate budget.
Re-granting on every 401. Some teams panic and kick the user back through SCA for any failure. You burn the 180-day SCA goodwill and annoy users. Classify first.
Renewing reactively. All consents from a launch cohort lapse together. Sweep proactively.
Assuming refresh tokens are long-lived. Rotation invalidates them. Persist the new token in the same transaction as the refresh.
Setting validUntil too long to "reduce friction." Past ~150 days you collide with SCA and force a redirect anyway — at a worse time. 90-day renewal inside a fresh SCA window is the local optimum.

Takeaways

Three timers, one OAuth mental model will not save you. Access token (short, silent), consent validUntil (≈90d, re-grant), SCA (≤180d, RTS Art. 10, must involve the PSU).
Token refresh extends timer 1 only. It never extends timers 2 or 3, which is the whole reason the 90-day cliff exists despite healthy refresh jobs.
Classify failures by tppMessages.code, not by status code alone. CONSENT_EXPIRED, TOKEN_EXPIRED, and a forced SCA each demand a different recovery path.
Sweep proactively. Renew ~10 days before the nearest timer lapses, route SCA-bound renewals to the user, and let the rest happen silently.

Get the classification and the sweeper right and the 90-day cliff stops being a mystery outage and becomes a quiet, spread-out background job — which is exactly what open banking should feel like when it's working.

Disclosure: I maintain open-banking.io, a self-hosted PSD2/open banking platform.

Plaid Alternatives in Europe: A PSD2 Developer's Comparison for 2026

John Frandsen — Mon, 03 Aug 2026 01:11:37 +0000

Plaid Alternatives in Europe: A PSD2 Developer's Comparison for 2026

Cover image suggestion: A stylised map of Europe made of interconnected bank/API nodes, with API request/response cards floating over it and a small "no certificate" badge in the corner. Muted fintech palette (deep navy + teal accents). Caption: "European open banking APIs compared."

Plaid is a great product — if you're building for the US. But once your customers are in the Eurozone, the UK, or the Nordics, you start hitting questions Plaid wasn't designed to answer: Where is my data hosted? Do I need an eIDAS certificate to go live? Why am I paying per-connection fees on top of PSD2 banks I could reach for free?

I build and maintain open-banking.io, so I spend an unhealthy amount of time comparing PSD2 providers. This is the comparison I wish existed when I started — focused on what actually matters to a developer shipping a small-business finance tool in Europe: pricing, certificate requirements, coverage, and API ergonomics.

Why look beyond Plaid in Europe?

Three reasons come up again and again in my inbox:

Data residency. Many EU customers (and their lawyers) want bank data to stay in the EEA. Plaid's core infrastructure is US-based, which adds SCC/DPA paperwork.
PSD2 was designed for free access. European regulators intended account information (AIS) and payment initiation (PIS) to be reachable by licensed Third-Party Providers. A pure PSD2 aggregator can often reach the same banks at a fraction of Plaid's per-connection cost.
The eIDAS tax. To call regulated PSD2 bank APIs directly, you need a QWAC (TLS) and often a QSeal (signing) certificate — €1,000–€6,000+ per year before you make a single API call. Some European providers let you avoid this entirely (more below).

TL;DR comparison

Provider	eIDAS cert needed?	Model	Pricing (illustrative)	Best for
Enable Banking	Yes (they hold it; you don't)	Full-service TPP	Usage-based, free sandbox	Broad Nordic/EU coverage
Nordigen / GoCardless	No (free AIS via PSD2)	Freemium AIS	Free 90-day lookback; Premium ~€300+/mo	Free historical data
Yapily	Yes (they hold it)	Headless API-only	Per-call, free tier	White-label, no UI needed
TrueLayer	Yes (they hold it)	Full-stack + payments	From ~€500/mo + per-connection	VRP / variable recurring payments
Tink (Visa)	Yes	Enterprise platform	On request (enterprise budgets)	Large orgs, Visa ecosystem
Plaid (EU)	Yes (they hold it)	Full-stack	Per-item, dev free → paid	US-first, EU secondary
open-banking.io	No — cert-free	Unified + fallback	Free / simple tiers	Indie & SMB builders

Pricing changes constantly and most of these providers only quote on a call. Treat the numbers above as order of magnitude and confirm on their pricing pages.

The PSD2 landscape: AIS, PIS, and certificates

Under PSD2, banks must expose two regulated services:

AIS (Account Information Services) — read balances and transactions.
PIS (Payment Initiation Services) — initiate a payment from the user's account.

To access the regulated API endpoints, a TPP must present a QWAC certificate (for the TLS handshake) and usually a QSeal certificate (to sign the request payload). You buy these from a Qualified Trust Service Provider (QTSP) — DigiCert, CERTUM, SwissSign, Itana, and friends.

Here's the catch for small builders: the certificate costs more than your first year of API calls. That's the entire reason cert-free aggregators exist.

The eIDAS problem (and how to dodge it)

If you're an indie developer or a small business, you have two realistic paths:

Use a provider that already holds the certificates. Enable Banking, Yapily, TrueLayer, Tink, and Plaid all do. You never touch eIDAS; they proxy the regulated calls. You pay for that convenience in usage fees.
Use a cert-free connector. Nordigen offers free AIS on PSD2 banks without you needing a certificate, and open-banking.io (which I maintain) was built specifically so you can reach your bank data with zero certificates and zero QTSP paperwork. It unifies multiple underlying aggregators and falls back gracefully, so a single API call works whether the bank is regulated-PSD2 or needs a direct connector.

For a deeper dive on the certificate-free path, I wrote a separate practical guide — Open Banking Without an eIDAS Certificate.

Provider notes (the nuance the table can't capture)

Enable Banking — Finnish, quietly excellent Nordic + EU coverage. Their docs are clean and they're the reigning #1 for a lot of "PSD2 account information API" queries. Downside: no famous free tier.

Nordigen (now GoCardless) — The disruptor. They made free 90-day transaction history a thing. If you just need a cash-flow view for an SMB, this is hard to beat. GoCardless acquisition means payments are now bundled under the "Bank Pay" brand.

Yapily — Pure headless. No UI widgets at all — you build everything. Great for white-label; more work if you wanted a drop-in consent screen.

TrueLayer — Strong on payments, especially VRP (Variable Recurring Payments), which is the future of recurring subscriptions and account-to-account in the UK/EU. Expect per-connection fees.

Tink — Acquired by Visa. Enterprise-grade, enterprise-priced. Brilliant data enrichment; overkill for a side project.

Plaid EU — Solid coverage, the best DX if you're already on Plaid in the US. But you inherit the per-item model and the US-centric data posture.

open-banking.io — Mine. The pitch is simple: one API, no eIDAS, no QTSP, works across regulated and direct connectors. Built for people who want to ship an SMB finance tool this week, not file compliance paperwork for three months.

Code: the same task, three ways

Fetching balances and recent transactions is the canonical "hello world" of open banking. Here it is against a cert-free endpoint versus a classic Plaid call.

curl — cert-free (open-banking.io style):

# After a one-time user consent flow, you get an access token.
# No certificate, no QTSP, no mTLS handshake to configure.
curl https://api.open-banking.io/v1/accounts/transactions \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "X-Account-Id: $ACCOUNT_ID"

Python — same thing, with error handling:

import os
import requests

def fetch_transactions(account_id, access_token):
    r = requests.get(
        "https://api.open-banking.io/v1/accounts/transactions",
        headers={
            "Authorization": f"Bearer {access_token}",
            "X-Account-Id": account_id,
        },
        timeout=30,
    )
    r.raise_for_status()
    return r.json()["transactions"]

txns = fetch_transactions("acct_123", os.environ["ACCESS_TOKEN"])
print(f"{len(txns)} transactions pulled — no certificate required.")

For contrast, a classic Plaid EU call requires a client_id + secret, an access_token from their Link flow, and — behind the scenes — Plaid holds the eIDAS certs and bills you per item:

import plaid

client = plaid.PlaidClient(
    client_id=os.environ["PLAID_CLIENT_ID"],
    secret=os.environ["PLAID_SECRET"],
    environment=plaid.Environment.Production,
)
resp = client.transactions_get(
    access_token=access_token,
    start_date="2026-01-01",
    end_date="2026-08-01",
)

Same outcome, very different cost and compliance posture.

How to choose (a 60-second framework)

Ask yourself three questions:

Do you ever need PIS (payments), or just AIS (data)? If only data, Nordigen or open-banking.io will save you money. If payments, TrueLayer and Yapily lead.
Is data residency non-negotiable? Then rule out US-first providers and lean into EU-headquartered aggregators.
Can your budget absorb €2k+/yr in certificate + compliance before launch? If no — and for most SMB builders the answer is no — a cert-free connector is the pragmatic default.

A note on affiliation

I maintain open-banking.io, so I'm plainly not neutral — I built it because I needed a cert-free path myself. The comparison above is my honest read of the market, and every provider listed is a legitimate choice depending on your constraints. Run the numbers for your own volume before committing.

TL;DR: If you're a small business or indie builder in Europe and your goal is account information without the eIDAS tax, start with a cert-free connector (Nordigen for free history, open-banking.io for a unified cert-free path). If you need payments at scale, look at TrueLayer and Yapily. Plaid remains the safe default only if you're already invested in it.

What did I get wrong? Which provider should I add a real benchmark for next? I'd love to hear what you're building in the comments.

fintech #api #banking #psd2

Build an MCP server that lets Claude read EU bank data (no eIDAS certificate needed)

John Frandsen — Fri, 31 Jul 2026 15:29:10 +0000

If you've tried to give an LLM agent access to your own bank account, you've probably hit the same wall every time: PSD2 says banks must expose account information APIs, but actually calling one usually requires an eIDAS QWAC certificate — a €500–700/year artefact gated behind KYC, a qualified trust service provider, and a CA that treats developers like compliance risks. Agents can read your GitHub, your calendar, your email… and then bounce off the bank.

I maintain open-banking.io, and I wrote previously about why agents can't reach banks. This post is the constructive follow-up: how to actually do it, by wiring a cert-free open-banking API into an MCP server that Claude (or any MCP-aware client) can call as a tool. Disclosure up front — I'm the maintainer, so judge the bias accordingly. The pattern works with any redirect-based AIS provider; I'm just using the one I know best.

Why MCP is the right shape for this

Model Context Protocol tools are a good fit for bank data for three reasons:

Read-only by design. AIS (Account Information Services) is inherently a read operation. Mapping get_balances / get_transactions to MCP tools makes the blast radius obvious in a way that a raw HTTP client does not.
Consent is a distinct step. Open banking uses an OAuth-style redirect flow where the human logs into their bank and approves scopes. MCP's tool-call boundary matches this: the agent never sees credentials, it only sees the result of an approved session.
Composability. Once balances and transactions are tools, the agent can reason across them ("sum last 30 days of grocery spend") without you writing a single analytic endpoint.

The catch is that you still need someone to hold the eIDAS cert and run the consent redirect. That's the wedge cert-free aggregators occupy: they hold the certificate and expose a plain REST API to you, so your MCP server never touches eIDAS at all.

The architecture

┌──────────┐   MCP (stdio/HTTP)   ┌─────────────────┐   REST + OAuth2   ┌────────────────┐
│  Claude  │ ───────────────────► │  your MCP server │ ───────────────► │ cert-free AIS  │
│  Desktop │ ◄─────────────────── │  (FastMCP, Py)   │ ◄─────────────── │  (open-banking │
└──────────┘   tool results        └─────────────────┘   JSON            │     .io)       │
                                                                        └───────┬────────┘
                                                                                │ holds eIDAS QWAC
                                                                         ┌──────▼──────┐
                                                                         │  EU bank    │
                                                                         │  PSD2 API   │
                                                                         └─────────────┘

The bank still sees a PSD2-regulated call with a valid QWAC. Your agent sees a JSON object. The certificate "tax" is paid once, upstream, by the aggregator — not per developer.

A minimal MCP server

Here's a working FastMCP server in ~60 lines. It exposes three tools: list supported banks, start a consent flow, and read data once consent is granted.

# eu_bank_mcp.py
import os, webbrowser
from mcp.server.fastmcp import FastMCP
import httpx

API_BASE = os.environ["OBI_API_BASE"]   # e.g. https://api.open-banking.io
API_KEY  = os.environ["OBI_API_KEY"]
SESSION_TOKEN = None  # cached after consent; in prod, persist to a secrets store

mcp = FastMCP("eu-bank")

def _headers():
    h = {"Authorization": f"Bearer {API_KEY}"}
    if SESSION_TOKEN:
        h["X-Consent-Token"] = SESSION_TOKEN
    return h

@mcp.tool()
def list_banks(country: str = "DK") -> list[dict]:
    """List banks available for connection in a given ISO country code."""
    r = httpx.get(f"{API_BASE}/v1/banks", params={"country": country}, headers=_headers(), timeout=15)
    r.raise_for_status()
    return [{"id": b["id"], "name": b["name"]} for b in r.json()["banks"]]

@mcp.tool()
def connect_bank(bank_id: str) -> str:
    """Start the redirect consent flow for a bank. Opens the user's browser.
    Returns the consent URL so the agent can surface it to the human."""
    global SESSION_TOKEN
    r = httpx.post(f"{API_BASE}/v1/consent", json={"bank_id": bank_id}, headers=_headers(), timeout=15)
    r.raise_for_status()
    consent_url = r.json()["consent_url"]
    SESSION_TOKEN = r.json().get("pending_token")
    webbrowser.open(consent_url)  # the HUMAN authenticates here, not the agent
    return f"Open this URL in a browser and approve: {consent_url}"

@mcp.tool()
def get_balances() -> list[dict]:
    """Return balances for all connected accounts. Requires prior consent."""
    r = httpx.get(f"{API_BASE}/v1/balances", headers=_headers(), timeout=15)
    r.raise_for_status()
    return r.json()["balances"]

@mcp.tool()
def get_transactions(account_id: str, days: int = 30) -> list[dict]:
    """Return transactions for an account over the last N days."""
    r = httpx.get(
        f"{API_BASE}/v1/transactions",
        params={"account_id": account_id, "days": days},
        headers=_headers(), timeout=15,
    )
    r.raise_for_status()
    return r.json()["transactions"]

if __name__ == "__main__":
    mcp.run()  # stdio transport by default

Note what's not here: no private key, no CSR, no certificate renewal cron, no openssl incantations. The eIDAS burden is a problem the aggregator already solved.

Point Claude Desktop at it

Drop this into claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/):

{
  "mcpServers": {
    "eu-bank": {
      "command": "python",
      "args": ["/absolute/path/to/eu_bank_mcp.py"],
      "env": {
        "OBI_API_BASE": "https://api.open-banking.io",
        "OBI_API_KEY": "sk_live_your_key"
      }
    }
  }
}

Restart Claude, and the tools appear in the function list. A natural conversation now works:

You: Connect my Danish bank, then tell me how much I spent on groceries last month.

Claude: I'll call list_banks("DK")… found nordfyns-bank. Calling connect_bank — please approve in the browser that just opened. Once you're back, I'll pull balances and 30 days of transactions and categorize them.

The redirect flow is the key safety property: the agent never sees the bank login. It only receives a consent token after a human completes authentication at the bank's own domain.

Cert-based vs cert-free MCP access

	Direct PSD2 API (you hold eIDAS)	Cert-free aggregator + MCP
Upfront cost	€500–700/yr + KYC	~€3/mo per bank, no KYC on you
Time to first call	2–8 weeks (CA issuance)	minutes
Certificate ops	renewals, key rotation, HSM	none
What the agent sees	raw SCA + signed calls	clean REST → MCP tools
Compliance surface	you're the regulated-ish party	aggregator is regulated
Best for	large regulated TPPs	indie builders, agents, personal finance

For an agent that just needs to read balances and transactions to answer questions, the right column wins almost every time.

Security notes worth stating plainly

Scope to AIS only. Never wire PIS (payment initiation) into an agent tool casually. Read access is recoverable; initiated payments are not. If you need payment tools, gate them behind a human-in-the-loop confirmation step, not silent agent autonomy.
Cache the consent token securely. The sketch above uses a global for clarity; in production, persist it to the OS keychain or a secrets manager. Treat it like a session cookie — it is one.
Consent expires. EU PSD2 consents max out at 90 days by default and many banks cap at 30. Your server should detect a 401 on read calls and re-trigger connect_bank rather than silently failing.
Log the agent's tool calls. The first time Claude calls get_transactions on its own initiative, you'll want an audit trail. FastMCP emits per-call events; ship them somewhere you control.

What this unlocks

Once bank data is just tool calls, the things agents can do get interesting fast: recurring-transfer detection ("you have three subscriptions you haven't used in 60 days"), cash-flow forecasting from transaction history, cross-account net-worth summaries, and — the one I'm most excited about — letting a personal-finance agent reconcile against a budgeting tool without screen-scraping or CSV exports.

The barrier was never the AI. It was the certificate. Removing it from the agent's path is what makes bank-aware agents practical today.

Disclosure: I maintain open-banking.io, the cert-free aggregation API used in the examples above. The MCP pattern works with any redirect-based AIS provider. Docs and a free tier to try the consent flow end-to-end are at open-banking.io.

European Alternatives to Plaid: Open Banking APIs Compared

John Frandsen — Thu, 30 Jul 2026 15:15:11 +0000

Why European Developers Need Plaid Alternatives

Plaid dominates open banking in the US, but European developers face a different landscape. GDPR data sovereignty rules, PSD2 regulatory requirements, and — most importantly — the eIDAS certificate wall create a gap that Plaid's EU offering doesn't fully bridge.

If you're building a fintech app, a budgeting tool, or an accounting integration in Europe, you need an open banking API that actually works within the EU regulatory framework without requiring you to become a licensed financial institution just to read transaction data.

Let's compare what's actually available.

The eIDAS Certificate Problem

Before comparing providers, you need to understand the single biggest barrier in European open banking: the eIDAS Qualified Website Authentication Certificate (QWAC).

Under PSD2, to directly access bank APIs as an Account Information Service Provider (AISP), you need:

Regulatory approval from your national financial authority
An eIDAS QWAC certificate (€500–€3,000/year depending on the CA)
An eIDAS Qualified Electronic Seal (QSeal) for signing API requests
Ongoing compliance audits

For a solo developer or small startup, this is a non-starter. The certificate alone costs more than many side projects earn in a year. This is why most developers use an aggregator — a licensed provider that handles the regulatory burden and exposes a simpler API.

European Open Banking APIs Compared

Here's how the major European open banking API providers stack up for developers:

Provider	Certificate Required?	Pricing Model	Bank Coverage	Developer Experience
Plaid (EU)	Yes (via Plaid)	Per-user, scales fast	Good EU coverage	Excellent docs, mature SDKs
TrueLayer	Yes (via TrueLayer)	Volume-based tiers	Strong UK/EU	Good docs, GraphQL + REST
Tink (Visa)	Yes (via Tink)	Enterprise-tier pricing	Strong Nordics/EU	Solid API, enterprise focus
Yapily	Yes (via Yapily)	Per-call pricing	Broad EU coverage	REST API, good coverage
GoCardless (Nordigen)	Yes (via GoCardless)	Free tier (limited) + paid	Good EU coverage	Changing pricing model
Salt Edge	Yes (via Salt Edge)	Custom enterprise	Global coverage	Mature API, broad reach

The Pattern

Notice the pattern? Every major aggregator requires a certificate — theirs. You don't need your own eIDAS cert, but you pay for it through:

Per-user pricing (Plaid charges per connected account)
Volume tiers (TrueLayer, Yapily gatekeep features behind volume)
Enterprise contracts (Tink, Salt Edge often require sales calls)
Changing free tiers (GoCardless/Nordigen has repeatedly adjusted their free offering)

This creates a real problem: as your app grows, costs scale unpredictably, and the provider can change terms at any time.

What Indie Developers Actually Need

After watching hundreds of open banking integrations across GitHub repos, forums, and community projects, here's what developers consistently ask for:

Predictable, low cost — flat-rate pricing that doesn't scale per user
No certificate overhead — direct API access without eIDAS procurement
Standard REST API — no proprietary SDKs required
Transparent bank coverage — know exactly which banks are supported
Self-serve signup — no sales calls, no enterprise contracts

The community response to this gap has been telling. In the last year alone, developers have built independent client libraries for the GoCardless/Nordigen API in Rust, .NET, Go, Python, and Dart — volunteer effort aimed at making a cert-heavy endpoint more accessible. Two community-built open banking MCP servers have appeared for AI agents. The demand is real.

Evaluating Your Options

When choosing a European Plaid alternative, ask these questions:

Cost predictability: Can you model your costs at 10, 100, and 1,000 users? Per-user models break at scale. Look for flat-rate or usage-based pricing you can control.

Certificate model: Do you need your own eIDAS cert, or does the provider handle it? If you're self-hosting or building an internal tool, the certificate requirement may be your biggest cost.

Bank coverage: European bank coverage varies significantly. A provider strong in the Nordics may be weak in Southern Europe. Check the actual coverage list, not marketing claims.

Exit strategy: What happens if the provider changes pricing or shuts down? Can you migrate your integration, or are you locked in?

Developer experience: Is there a sandbox you can test without signing up? Are the docs public? Can you make a test API call in under 5 minutes?

The Bottom Line

The European open banking landscape is fragmented because PSD2 created a regulatory framework that favors large, well-capitalized aggregators. The certificate tax is real — it's the reason indie developers face higher costs and fewer options than their US counterparts.

When evaluating alternatives, prioritize cost predictability, transparent coverage, and self-serve access. The provider that lets you start building in minutes without a sales call is the one that respects your time as a developer.

Disclosure: I maintain open-banking.io, a cert-free PSD2 open banking API service for indie developers. This article focuses on the broader ecosystem landscape — evaluate all options against your specific needs.

Your AI Agent Can Call Every API — Except Your Bank. Here's Why.

John Frandsen — Tue, 28 Jul 2026 23:20:52 +0000

Every API you'd want an agent to call has a clean path: an API key, an OAuth dance, maybe a scoped token. Your LLM can read your calendar, file your issues, query your database. Then it hits your bank — and the door slams.

It's not that bank APIs don't exist. PSD2 forced EU banks to publish them. It's that the authentication layer is built for institutions, not agents. Getting onto a bank's API as a third party requires an eIDAS QWAC + eSEAL certificate — a Qualified Website Authentication Certificate and a Qualified Electronic Seal, issued by a QTSP after a weeks-long onboarding that runs €2,000–€10,000 per year.

No agent framework ships a tool that can produce a Qualified Seal. No indie dev spinning up an MCP server on a Friday night is going to file for one. So the agent wave, which is consuming every other API surface, bounces off banking entirely.

The aggregator vacuum, explained

This is the actual reason the open-banking landscape is dominated by aggregators — Yapily, TrueLayer, Tink, Plaid. It's not that they have better technology. It's that they're the only entities willing and able to absorb the certificate tax.

They buy the eIDAS certs. They handle the regulatory registration as Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs). They maintain the per-bank connector sprawl (every bank implements the Berlin Group NextGenPSD2 standard slightly differently). Then they sell you a single REST key on top.

It's a perfectly rational business. But it has a side effect: it makes bank data the only major API category where you cannot talk directly to the source without a six-figure compliance posture. For agents, that's a problem.

Why MCP makes this acute

Model Context Protocol (MCP) servers are how tools get into agent runtimes this year. The pattern is clean — a server exposes a handful of tools, an agent discovers and calls them. For most domains this is trivial: wrap a REST API, return JSON, done.

For banking it breaks at the first step, because the wrapper needs a client certificate to even complete the TLS handshake with the bank. That's not a config value you paste in — it's a credential bound to a legal entity that has passed regulatory vetting. An MCP server you'd publish to a registry can't carry one. So today, the realistic "bank MCP server" is one that talks to an aggregator, not to banks.

I think that's the wrong default. The interesting design question for agent-native banking is whether we can get read access to one's own account data without forcing the agent stack through an intermediary. That requires a tier of access that doesn't exist in the PSD2 rulebook as written, but which several adjacent trends are pulling toward.

What a certificate-free read tier would unlock

PSD2 already distinguishes AIS (read) from PIS (write). The certificate burden exists for both, but the risk profiles are wildly different: a consented, read-only view of your own balances and transactions is not the same as initiating a payment. Yet both sit behind the same eIDAS wall.

A practical, agent-friendly pattern is starting to emerge at the edges:

Sandbox-first, cert-free. Several bank developer portals and aggregator sandboxes expose test data with only an API key. An MCP server can ship against these today, giving agents real-shaped data to develop against without any compliance posture. This is where most agent/banking experimentation will live for the next year.
AISP-lite / hosted-agent consent. Instead of every agent operator registering as an AISP, an entity holds the AISP license and grants scoped, consent-bound read tokens to agent processes — not to end companies. The agent runs against your consented accounts; it never holds the certificate. This is structurally what aggregators do, but with the boundary drawn so that the agent is the consumer, not the company.
Certificate-free production read tiers. The genuinely useful (and genuinely hard) version: a bank-data API that gives consented read access with API-key auth, with the certificate burden absorbed by the API provider rather than pushed onto every integrator. This is what I've been building toward with open-banking.io — a certificate-free read tier so that the smallest integrator, or a single MCP server, can reach bank data without the eIDAS tax.

The third option is the one that matters for agents. If accessing your own transaction history requires you to first become a regulated financial institution, agent-native personal finance is a non-starter.

A sketch of what the agent side looks like

To make this concrete, here's the shape of an MCP tool that reads account data through a certificate-free tier — no client cert, no eIDAS, just a key and user consent:

// An MCP "list_transactions" tool definition
{
  "name": "list_transactions",
  "description": "List recent transactions for a consented bank account.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "account_id": { "type": "string" },
      "since": { "type": "string", "format": "date" },
      "limit": { "type": "integer", "default": 50 }
    },
    "required": ["account_id"]
  }
}

# The server-side handler — note: no mTLS, no client certificate
async def list_transactions(account_id: str, since: str, limit: int = 50):
    resp = await client.get(
        f"https://api.example-bankdata.io/v1/accounts/{account_id}/transactions",
        params={"since": since, "limit": limit},
        headers={"X-API-Key": os.environ["OBI_KEY"]},
    )
    resp.raise_for_status()
    return normalize_for_agent(resp.json())  # flatten to agent-friendly JSON

The hard part isn't this code — it's trivial. The hard part is everything upstream: the consent flow, the bank connectors, the regulatory absorption that lets the integrator skip eIDAS entirely. That's the layer worth building if you want agents to actually reach banking data.

The takeaway

The reason your agent can read your GitHub but not your bank statement isn't a missing integration. It's a regulatory design choice — the certificate tax — that funnels all third-party bank access through a handful of intermediaries. As the MCP ecosystem keeps eating every other API surface, banking is going to be the conspicuous holdout unless we build read tiers that don't require every integrator to become a regulated institution.

Certificate-free, consent-bound, read-first access is the unlock. If you're building agent tooling and you've bounced off banking, that's the gap worth closing.

I maintain open-banking.io, a certificate-free open banking API. The views on PSD2/eIDAS here are my own; the agent-native banking question is one I think about daily.

DEV Community: John Frandsen

Tink Alternatives in 2026: An Honest Developer's Comparison

Why developers start looking

The alternatives, honestly

Switching costs less than you expect

How to actually choose

When Tink is still the right answer

Open Banking Python Library: What Actually Exists in 2026 (and What I Use Instead)

What a search for an open banking Python library actually finds

Why there's no "requests" of open banking

The three realistic options

A minimal client in plain requests

The part no library saves you from

What I check before depending on any of this

What I'd pick

Plaid Alternatives in Europe - What Actually Changes When You Switch

Why teams actually switch

The realistic options

The part nobody tells you: migrating connection semantics

A quick comparison

How to choose without a sales cycle

Free Signup vs Production Access: What Self-Serve PSD2 Providers Actually Gate

"Self-serve" is doing a lot of work

The field as of August 2026

The table

How to check the gate yourself in ten minutes

The decision framework

Disclosure

Migrating Off Nordigen: A Field Guide for Indie Builders (2026)

What happened

Your realistic options

1. Direct PSD2 with your own eIDAS certificates

2. Aggregator with your own bank-issued keys (the cert-free middle path)

3. Full broker — the aggregator holds everything

Migration mechanics

Consents do not travel

Historical data: export before you cancel

Dedupe: the stable transaction ID

FITID mapping (QuickBooks / OFX users)

Endpoint mapping

Migration checklist

Building a Personal Finance App with Open Banking APIs in 2026 (No Certificates Required)

What an "Open Banking API" actually means

The certificate wall (and why it blocks indie builders)

The certificate-free approach

Step 0 — Get API access (no certificates, ~2 minutes)

Step 1 — List accounts and balances (Python)

Step 2 — Pull and paginate transactions

Step 3 — Turn raw transactions into insights

Step 4 — Schedule a daily sync and cache

Security: zero-knowledge, and why it matters for a finance app

A word on cost

What you've got

The Best Plaid Alternative in Europe (2025): A Developer's Guide to PSD2 APIs

Why developers look for a Plaid alternative in Europe

What "PSD2-native" actually means (and why the eIDAS certificate matters)

The main Plaid alternatives in Europe: compared

A note on each

The flow every European open banking API shares

Code examples

1. Initialize a bank session (consent)

2. List accounts

3. Fetch balances and transactions

4. A complete Python helper

How to choose: a decision guide

Pitfalls to avoid when switching from Plaid

Official references

Summary

PSD2 Consent Expiry vs Token Refresh: Why Your Bank Connection Stops After 90 Days

The three timers at a glance

Timer 1 — The access token (the one you already know)

Timer 2 — Consent validUntil (this is your 90-day problem)

Timer 3 — SCA re-authentication (the hard wall PSD2 imposes)

Reading the signals: which timer just fired?

A recovery orchestrator

Don't wait for the user to hit the error

Why banks vary so much

The mistakes I see most often

Takeaways

Plaid Alternatives in Europe: A PSD2 Developer's Comparison for 2026

Timer 2 — Consent `validUntil` (this is your 90-day problem)