DEV Community: John Frandsen

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.

GoCardless Bank Account Data Alternatives: What to Use When Signups Are Disabled

John Frandsen — Fri, 24 Jul 2026 03:12:54 +0000

If you've been building on GoCardless Bank Account Data (formerly Nordigen's free tier), you may have noticed something concerning: new signups are disabled. The official page at bankaccountdata.gocardless.com/new-signups-disabled now blocks all new integrations.

Existing users can continue, but if you're starting a new project or evaluating options, you need alternatives — today.

What happened

GoCardless acquired Nordigen in 2023 and integrated its free bank-data API as "Bank Account Data." The free tier was hugely popular with indie developers, hobbyist projects, and small fintech tools — it offered EU PSD2 coverage without the upfront cost of enterprise providers.

Now that door is closing for new users. This mirrors a broader pattern: free open banking tiers are disappearing across the industry. Plaid tightened its free tier, Tink went enterprise-only under Visa, and now Nordigen's free legacy is being sunset for new signups.

The question isn't just "what's the alternative" — it's "what alternative doesn't lock me into the same cycle?"

The alternatives compared

Provider	eIDAS cert required?	Pricing model	EU coverage	Best for
open-banking.io	❌ No	Free tier + paid plans	EU (PSD2)	Devs who want no certificate hassle
Tink (Visa)	✅ Yes	Enterprise pricing	EU + global	Large-scale production
Plaid	✅ Yes (EU)	Pay-per-call	Global	US-first teams needing EU too
Yapily	✅ Yes	Custom pricing	EU	Enterprise integrations
Enable Banking	✅ Yes	Custom pricing	EU	Budget-conscious teams

The key differentiator isn't coverage or pricing — it's the certificate requirement. Most providers require you to hold an eIDAS QWAC/QSeal certificate to call their APIs directly.

Why certificate-free matters more than you think

An eIDAS qualified certificate costs €2,000–10,000 per year, depending on the issuer and type. You need to renew every 1–2 years, maintain audit trails, and handle the operational overhead of certificate rotation.

For an indie developer or small SMB tool, the certificate cost can exceed the entire app's revenue. This is the hidden tax that makes "free" open banking APIs expensive in practice — you're paying for the cert even if the API calls are free.

Certificate-free alternatives work differently: they use end-to-end encryption through regulated partner infrastructure, so you get PSD2-compliant bank data access without holding the certificate yourself. You interact with a standard REST API; the regulated partner handles the compliance layer.

How to migrate from GoCardless BAD

If you've been using the Nordigen/GoCardless Bank Account Data REST API, the migration path is straightforward:

API surface is similar. Most PSD2 providers expose endpoints for accounts, transactions, and balances. Endpoint structures differ slightly but the data model is consistent across PSD2.
Re-map bank identifiers. Each provider uses slightly different bank ID schemas. You'll need to update your bank selection/lookup logic.
Consent flow is similar. PSD2 mandates a redirect-based consent flow (ASPSP → callback). The mechanics are the same; the redirect URLs and token formats differ.
Test incrementally. Start with one bank, verify transaction data quality, then expand coverage.

The simplest path: pick a cert-free provider, spin up a sandbox, and point your existing integration at the new endpoints. If you were using Nordigen's Python SDK, the migration is mostly changing base URLs and auth headers.

What to do right now

Check your current integration status. If you're an existing GoCardless BAD user, confirm your access is still active and understand the sunset timeline.
Evaluate cert-free alternatives before your access ends. Don't wait until the last minute — consent flows, bank mappings, and testing take time.
If you're starting fresh, skip the cert entirely. There's no reason to buy a €2,000+/year certificate when cert-free options exist with the same PSD2 coverage.

Disclosure: I'm affiliated with open-banking.io, a certificate-free EU open banking API. This comparison is based on publicly available information about each provider as of July 2026.

Five Ways to Access European Bank Data in 2026 (And What Each Actually Costs)

John Frandsen — Thu, 23 Jul 2026 01:14:48 +0000

The Five Paths to European Bank Data (And What Each One Actually Costs)

If you're building a fintech app in Europe, you need bank transaction data. The PSD2 directive guarantees access — but how you get that access determines your cost, complexity, and time-to-market.

I've spent the last year navigating this landscape. Here's an honest breakdown of every path available in 2026, with real numbers.

Path 1: Become a TPP yourself

You register as an Account Information Service Provider (AISP) with your national regulator, obtain an eIDAS Qualified Website Authentication Certificate (QWAC) and Qualified Electronic Seal (QSEAL), and call bank APIs directly.

What it costs:

Item	Cost (EUR/year)
QWAC certificate	500 – 2,000
QSEAL certificate	500 – 2,000
Regulatory registration & legal	3,000 – 10,000
Per-bank API integration	Engineering time × N banks
Certificate renewal (annual)	500 – 2,000

The hidden cost: every bank implements the Berlin Group NextGenPSD2 spec differently. LHV handles SCA one way. BNP Paribas another. Revolut's consent flow is non-standard. You'll spend weeks per bank debugging redirect loops, signature format mismatches, and undocumented error codes.

Verdict: Only makes sense if you're a funded company with a dedicated compliance team and plan to operate at scale across many markets.

Path 2: Use a licensed aggregator (Plaid, TrueLayer, Yapily)

These companies hold the TPP licenses and certificates. You integrate their SDK, and they handle the regulatory burden.

What it costs:

Plaid: Usage-based, typically $0.50–$2.00 per connected account per month. Minimum commitments for production access.
TrueLayer: Pay-per-call or revenue-share models. Free tier for development.
Yapily: Per-call pricing with volume discounts.

The upside: Polished SDKs, good documentation, broad bank coverage. You're up and running in days.

The downside: You're paying a premium per-transaction. For a personal finance app with 1,000 users syncing monthly, that's $500–$2,000/month just for data access. And you're locked into their API surface — if they change pricing or deprecate endpoints, your users feel it.

Path 3: Nordigen / GoCardless Bank Account Data

Nordigen pioneered a generous free tier for bank data access. After the GoCardless acquisition, the free tier has been scaled back, and the long-term pricing direction is toward the GoCardless Open Banking product line.

What it costs: Free tier exists (limited), paid plans start around €100–€500/month depending on volume.

The risk: The acquisition means pricing and feature decisions are now made by a large payments company optimizing for enterprise accounts. If you're an indie developer or small startup, you're not the priority customer.

Path 4: Enable Banking

A Finnish aggregator with a developer-friendly API and transparent per-bank pricing. Good coverage of Nordic and Baltic banks.

What it costs: Per-API-call pricing. Roughly €0.05–€0.15 per call depending on volume.

The upside: Honest pricing, good docs, responsive support.
The downside: You still pay per-call, and costs scale linearly with user count.

Path 5: Cert-free proxy services

This is the model I work on — services that sit between you and the bank APIs, absorbing the eIDAS certificate requirement entirely. You get a simple REST API key and never touch a certificate.

import urllib.request
import json

# No certificate. No mTLS. Just an API key.
API_KEY = "your-api-key"

# Create a session
req = urllib.request.Request(
    "https://api.open-banking.io/v1/sessions",
    data=json.dumps({
        "bank": "REVOLUT",
        "redirect_url": "https://yourapp.com/callback"
    }).encode(),
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json"
    }
)
response = urllib.request.urlopen(req)
session = json.loads(response.read())

# User completes SCA redirect, then:
# Fetch transactions
req = urllib.request.Request(
    f"https://api.open-banking.io/v1/sessions/{session['id']}/transactions",
    headers={"Authorization": f"Bearer {API_KEY}"}
)
transactions = json.loads(urllib.request.urlopen(req).read())

What it costs: Subscription-based, typically €2–€5/month per application regardless of call volume. No per-transaction fees.

The upside: Fixed cost means it scales with users without scaling your bill. No certificate management. Standard REST API — works with any HTTP client.
The downside: You're trusting a third party with the TPP layer. Less granular control than direct bank API access.

How to choose

Your situation	Recommended path
Funded company, multi-market, compliance team	TPP license + direct APIs
Quick prototype, any budget	Aggregator (Plaid/TrueLayer)
Cost-sensitive, per-call OK	Enable Banking
Fixed budget, indie/small team	Cert-free proxy
Enterprise, needs payment initiation too	Yapily or TrueLayer

The key insight: the cheapest API call is the one where the certificate cost is amortized across thousands of users. If you're below that scale, a cert-free proxy gives you the same data at a fraction of the cost.

Disclosure: I maintain open-banking.io, a cert-free open banking API service. This article reflects my experience building in this space — the cost figures come from public pricing pages and my own integration work. I've tried to be honest about the tradeoffs of every approach, including the one I work on.

Reading EU Bank Transactions With Python and PSD2 — Without Buying an eIDAS Certificate

John Frandsen — Wed, 22 Jul 2026 05:09:27 +0000

If you've tried to build anything with European bank APIs, you probably hit the same wall I did: the certificate requirement. PSD2 says you need an eIDAS QWAC certificate to talk to banks directly, and those aren't cheap or quick to obtain.

But there's a path that skips the certificate entirely. I'll show you how it works — with real code you can run today.

The short version

Instead of obtaining your own eIDAS certificate and registering as a Third Party Provider with every bank, you use an Account Information Service Provider (AISP) that already has the certificate. Your app talks to their API; they talk to the banks. You never touch a certificate.

The trade-off: you depend on an intermediary. But for most indie projects, small businesses, and personal-finance tools, that's a perfectly reasonable trade. You get bank data via a clean REST API instead of fighting with mutual TLS and per-bank registration.

What you'll need

Python 3.8+ (stdlib only, no pip installs needed for the basics)
An API key from an AISP provider
A bank account in a supported EU country

I'm the maintainer of open-banking.io, so I'll use our API as the example — but the pattern is the same for any PSD2 AISP (Enable Banking, Salt Edge, Tink, etc.). Pick whichever fits your coverage and budget.

Step 1: Get your API key

export OBI_API_KEY="***"

Never hardcode it. If you commit it to git, rotate immediately.

Step 2: Initiate a bank connection

Your user needs to consent to sharing their data. This redirects them to their bank's login page:

import os
import json
import urllib.request

API_BASE = "https://api.open-banking.io/v1"
API_KEY=os.env...EY"]

def create_session(bank_id: str, return_url: str) -> dict:
    """Start a bank connection. Returns a consent URL for the user."""
    payload = json.dumps({
        "bank_id": bank_id,
        "return_url": return_url,
    }).encode()

    req = urllib.request.Request(
        f"{API_BASE}/sessions",
        data=payload,
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        method="POST",
    )

    with urllib.request.urlopen(req) as resp:
        return json.loads(resp.read())

# Example: connect to a Danish bank
result = create_session("nordea-dk", "https://yourapp.com/callback")
print(f"Send the user to: {result['consent_url']}")

The user visits consent_url, logs into their bank, and approves. They're redirected back to your return_url with a session token.

Step 3: Fetch accounts and balances

Once the session is authorized:

def get_accounts(session_id: str) -> list:
    req = urllib.request.Request(
        f"{API_BASE}/sessions/{session_id}/accounts",
        headers={"Authorization": f"Bearer {API_KEY}"},
    )
    with urllib.request.urlopen(req) as resp:
        return json.loads(resp.read())["accounts"]

def get_balance(session_id: str, account_id: str) -> dict:
    req = urllib.request.Request(
        f"{API_BASE}/sessions/{session_id}/accounts/{account_id}/balance",
        headers={"Authorization": f"Bearer {API_KEY}"},
    )
    with urllib.request.urlopen(req) as resp:
        return json.loads(resp.read())

accounts = get_accounts(result["session_id"])
for acct in accounts:
    bal = get_balance(result["session_id"], acct["id"])
    print(f"{acct['name']}: {bal['amount']} {bal['currency']}")

Step 4: Fetch transactions

def get_transactions(session_id: str, account_id: str) -> list:
    req = urllib.request.Request(
        f"{API_BASE}/sessions/{session_id}/accounts/{account_id}/transactions",
        headers={"Authorization": f"Bearer {API_KEY}"},
    )
    with urllib.request.urlopen(req) as resp:
        return json.loads(resp.read())["transactions"]

for txn in get_transactions(result["session_id"], accounts[0]["id"]):
    print(f"{txn['date']} | {txn['amount']:>8} | {txn['description'][:50]}")

That's it. You're reading live bank data without ever touching a certificate.

Gotchas worth knowing

Consent expiry. PSD2 consents expire (typically 90 days, varies by bank). You'll need to re-authorize periodically. Build that into your app's flow — don't assume a session lasts forever.

Booked vs pending. Transactions come in two flavors. booked transactions are finalized; pending are provisional and may change or disappear. If you're building a budgeting tool, track booked as your source of truth and dedupe carefully — the same transaction can appear in both lists during the settlement window.

Bank coverage gaps. No AISP covers every EU bank. Before committing, check the provider's coverage list for the banks your users actually need. Smaller regional banks are often the gap.

Rate limits. PSD2 APIs enforce per-consent access frequency limits (typically 4x/day for transactions). Cache aggressively. Don't poll in a loop.

Privacy model. Some providers store your transaction data server-side. Others (like ours) use client-held encryption keys so the provider literally can't read user data. If you're building for GDPR-conscious users, check which model you're getting.

When you should get the certificate

If you're building a regulated financial product at scale — processing payments (PIS), doing credit checks, or serving thousands of users across many banks — get your own eIDAS certificate and go direct. The intermediary adds latency, cost per call, and a dependency you don't want at scale.

But for personal projects, small SaaS tools, internal dashboards, and anything where you just need to read account data without the enterprise overhead: the AISP path is the pragmatic choice.

Disclosure: I'm John, the maintainer of open-banking.io — a certificate-free PSD2 account information service for EU banks. The code above works with our API, but the pattern applies to any compliant AISP. Questions? Find me in the comments.

Open Banking Without an eIDAS Certificate: A Practical Developer's Guide (2026)

John Frandsen — Tue, 21 Jul 2026 23:11:52 +0000

If you've ever tried to call a European bank's open banking endpoint directly — say, to read your own account balances programmatically — you probably hit a wall that looks something like this:

HTTP 401 Unauthorized
{"error": "invalid_client", "error_description": "mutual TLS certificate required"}

That's the eIDAS certificate gate. Under PSD2, a bank's production API is protected by mutual TLS using a qualified certificate (a QWAC), and request signing often needs a second one (QSeal). For a regulated bank or a well-funded fintech, that's a tax you pay. For an indie developer, a student project, or a small business automating its own accounting, it's a deal-breaker: the certs cost roughly EUR 2,000–10,000 per year, take weeks of paperwork, and require a registered legal entity.

The good news: there's a well-defined, fully compliant path to read EU bank data without ever touching an eIDAS certificate yourself. This guide explains how it actually works under the hood, when to use it, and includes real, runnable code.

Disclosure up front: I'm John, the founder of open-banking.io — one of the providers in this space. I'll use our API for the worked code example because I know it best, but the architecture I'm describing is how every certificate-free aggregator works. I'll be honest about where direct access is the better choice.

The two paths to a bank's API

Every PSD2 Account Information Service (AIS) call ultimately lands on the same bank endpoint. The question is who holds the certificate.

Path A — Direct (you hold the eIDAS certificate)

You apply for an eIDAS QWAC and QSeal from a qualified trust service provider, register as a TPP (Third Party Provider) with each national regulator, onboard with each bank's developer portal, and call the bank directly over mutual TLS.

Cost: EUR 2k–10k/year per certificate + legal/regulatory overhead
Time to first call: 4–12 weeks
Coverage: one bank cluster at a time (you onboard bank-by-bank)
Best for: regulated fintechs with high volume, enterprise treasuries, anyone who needs to avoid a data intermediary in the path

Path B — Aggregator (the aggregator holds the certificate)

You sign up with an AIS aggregator, get an API key, and call their unified API. They hold the eIDAS certificates, maintain the bank integrations, handle the per-bank quirks (Berlin Group vs STET vs UK Open Banking vs Polish API standards), and present you with one consistent REST interface.

Cost: free tiers exist (small projects), usage-based pricing at scale
Time to first call: minutes
Coverage: hundreds/thousands of banks across the EU/EEA through one integration
Best for: indie devs, SMBs, PFM apps, self-hosters, anyone who values shipping over regulatory plumbing

Dimension	Direct (eIDAS)	Aggregator (cert-free)
Certificate required?	QWAC + QSeal (you buy)	None
Setup time	Weeks–months	Minutes
Upfront cost	EUR 2k–10k/yr	$0 on free tiers
Bank coverage	Per-bank onboarding	1,000s of banks, one API
Data path	You <-> Bank	You <-> Aggregator <-> Bank
GDPR control	Full (no intermediary)	Depends on provider (look for EU data residency + E2E encryption)
Per-bank quirks	You handle them all	Abstracted away

The GDPR row is the one people underestimate. A good aggregator gives you EU-only data residency and ideally end-to-end encryption where only you hold the decryption key — meaning the aggregator genuinely can't read your transactions in the clear. That's the property you're trading the direct path for, so verify it before you sign up.

How the cert-free flow actually works

Aggregators don't "skip" PSD2 — they comply with it on your behalf. Here's the sequence, and it's the same whether you use Nordigen/GoCardless, Tink, TrueLayer, Enable Banking, or open-banking.io:

1. Create a consent / requisition      -> you POST "user wants bank X"
2. Redirect user to bank (SCA)         -> user authenticates at their bank
3. Bank calls back to aggregator       -> consent is now "valid"
4. You list accounts                   -> GET /accounts
5. You fetch balances & transactions   -> GET /accounts/{id}/transactions
6. Consent expires (90 / 180 days)     -> repeat from step 1

The eIDAS certificate is used in step 2 and 3 — when the aggregator talks to the bank's production endpoints. Your API key only authenticates you to the aggregator, over standard HTTPS. You never see mTLS.

The two things that bite people:

SCA (Strong Customer Authentication): the user must actively authenticate at their bank — a redirect, an app-to-app handoff, or a decoupled push. You can't silently scrape. Plan your UX around a browser/redirect hop.
Consent expiry: PSD2 limits AIS consent. Common values are 90 days (Germany) or 180 days (many other markets), and users can revoke at any time. Your code must handle re-consent gracefully — store the consent expiry timestamp alongside the consent id and trigger re-auth before it lapses.

Real code: your first cert-free bank-data call

Here's the actual pattern, using open-banking.io's API as the worked example. The shape (create requisition -> redirect -> list -> fetch) is identical across providers; only the field names change.

Step 1 — Create a requisition (pick a bank)

# Replace YOUR_API_KEY with the key from your provider's dashboard
curl -X POST https://api.open-banking.io/v1/requisitions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "redirect": "https://yourapp.example.com/callback",
    "institution_id": "DANMARKS_DANSKE_BANK",
    "reference": "user-42-first-link"
  }'

{
  "id": "req_8f3a...",
  "link": "https://api.open-banking.io/redirect/req_8f3a...",
  "accounts": [],
  "status": "CR"
}

Send the user's browser to link. They authenticate at Danske Bank (SCA). On success, the bank redirects back to your redirect URL.

Step 2 — List the linked accounts

curl https://api.open-banking.io/v1/requisitions/req_8f3a... \
  -H "Authorization: Bearer YOUR_API_KEY"

{
  "id": "req_8f3a...",
  "status": "LN",
  "accounts": ["acc_a1b2...", "acc_c3d4..."]
}

status: "LN" means linked. Now grab data.

Step 3 — Fetch balances and transactions

# Balances
curl https://api.open-banking.io/v1/accounts/acc_a1b2.../balances \
  -H "Authorization: Bearer YOUR_API_KEY"

# Transactions (last 30 days)
curl "https://api.open-banking.io/v1/accounts/acc_a1b2.../transactions?date_from=2026-06-21&date_to=2026-07-21" \
  -H "Authorization: Bearer YOUR_API_KEY"

A tiny Python client

import os, requests

API = "https://api.open-banking.io/v1"
KEY = os.environ["OBI_API_KEY"]
H   = {"Authorization": f"Bearer {KEY}"}

def create_requisition(institution_id, redirect_url):
    r = requests.post(f"{API}/requisitions", headers=H, json={
        "redirect": redirect_url,
        "institution_id": institution_id,
    })
    r.raise_for_status()
    return r.json()

def list_accounts(requisition_id):
    r = requests.get(f"{API}/requisitions/{requisition_id}", headers=H)
    return r.json()["accounts"]

def get_transactions(account_id, date_from, date_to):
    r = requests.get(
        f"{API}/accounts/{account_id}/transactions",
        headers=H, params={"date_from": date_from, "date_to": date_to},
    )
    return r.json()["transactions"]

# Usage
req = create_requisition("DANMARKS_DANSKE_BANK", "https://yourapp.example.com/cb")
print("Send user to:", req["link"])
# ... after the user authenticates at their bank ...
for acct in list_accounts(req["id"]):
    txns = get_transactions(acct, "2026-06-21", "2026-07-21")
    print(acct, len(txns), "transactions")

Check each provider's live docs for the exact field names — they vary. The flow above is universal across PSD2 AIS.

Five gotchas that cost me real time

Consent expiry is per-country, not universal. Germany defaults to 90 days; the Nordics often allow 180. Store the expiry per consent and notify users at T-7, T-3, and T-0. A silent expiry is the #1 reason "my sync stopped working" tickets.
Bank coverage has real gaps. "Supports 10,000 banks" hides the fact that your specific regional Sparkasse or niche neobank may be missing or sandbox-only. Test your actual target banks before committing.
Transaction booking vs pending. Most APIs expose both booked and pending transactions. Dedupe by transactionId (or entryReference); if a bank doesn't supply one, hash (date, amount, counterparty, description) and treat collisions carefully.
Rate limits and polling. Refreshing transactions every minute will get you throttled — and PSD2 limits how often you can pull anyway. Once or twice a day per account is usually plenty; some banks also support webhooks for new transactions.
GDPR / data residency. If your users are EU-based and you're shipping a commercial product, confirm the aggregator processes data in the EU and offers end-to-end encryption. "Compliant with PSD2" is not the same as "we can't read your data."

When should you actually get the certificate?

The aggregator path isn't always right. Go direct with your own eIDAS certificate when:

You're a regulated AIS/PISP and volume justifies it (rough rule of thumb: once you're paying the aggregator more than ~EUR 2k/year, the math flips).
You're an enterprise treasury or bank-adjacent product where no third party may sit in the data path (regulatory or policy reasons).
You need Payment Initiation (PIS) at high reliability and the aggregator's PIS coverage is thin for your target banks.

For everyone else — hobby projects, SMB accounting automation, personal finance dashboards, self-hosted budgeting tools (Actual Budget, Firefly III, Beancount integrations) — the certificate-free aggregator path is almost always the pragmatic choice. You get to ship this week instead of next quarter.

TL;DR

You don't need an eIDAS certificate to read EU bank data. An AIS aggregator holds it for you; you get an API key.
The flow is universal: create requisition -> SCA redirect -> list accounts -> fetch transactions -> renew consent before it expires.
Pick a provider on three axes: bank coverage for your banks, EU data residency + E2E encryption, and a free tier that fits your stage.
Go direct (buy the cert) only when volume, regulation, or a no-intermediary requirement demands it.

If you want to try the flow above end-to-end, you can grab a free API key at open-banking.io — and yes, that's my project, so apply appropriate skepticism and compare it against Tink, TrueLayer, GoCardless (formerly Nordigen), and Enable Banking before you commit. The right answer depends on your banks and your budget, not on who wrote this article.

Questions or war stories from your own bank-data integrations? Drop them in the comments — I read every one.

Why You Cant Just Call a Bank API: Open Banking Authentication Explained for Developers

John Frandsen — Thu, 16 Jul 2026 00:52:34 +0000

If you've ever tried to hit a bank's API directly and hit a wall of certificates, registration forms, and regulatory compliance documents — you're not alone. Open banking APIs promise programmatic access to financial data, but the authentication layer is where most developers get stuck.

Here's what's actually going on, and why most teams end up using an aggregator instead.

The three layers of open banking auth

Open banking authentication isn't one thing — it's three things stacked on top of each other:

1. eIDAS / QWAC certificates (the regulatory gate)

If you want to talk to a bank's API directly in the EU/UK, you need an eIDAS Qualified Certificate (specifically a QWAC — Qualified Website Authentication Certificate). This proves you're a regulated Third Party Provider (TPP).

The cost? Anywhere from €2,000–€10,000 per year, depending on the issuer. Plus the regulatory registration process, which can take months.

This is the single biggest barrier for indie developers and small companies. You can't just curl a bank endpoint — the TLS handshake requires a client certificate the bank recognizes.

2. OAuth 2.0 + SCA (the user consent flow)

Once you're past the certificate gate, every bank interaction starts with an OAuth 2.0 Authorization Code flow with Strong Customer Authentication (SCA):

GET /authorize?
  response_type=code&
  client_id=your_client_id&
  redirect_uri=https://yourapp.com/callback&
  scope=accounts&
  state=random_state

The user is redirected to their bank, authenticates (2FA — usually a push notification or SMS code), and consents to sharing specific accounts. You get back an authorization code, exchange it for access + refresh tokens, and use the access token for subsequent API calls.

Each bank implements this slightly differently. The Open Banking Standard in the UK enforces a consistent flow, but continental European banks vary widely.

3. Bank-specific API quirks (the implementation tax)

Even with certificates and OAuth sorted, each bank's API has its own:

Response formats (some use Berlin Group NextGenPSD2, some use STET, some use the UK Open Banking standard)
Pagination schemes
Transaction ID formats
Rate limits
Error response structures
Sandbox vs production differences

This is why companies like Plaid, Tink, TrueLayer, and GoCardless/Nordigen exist — they abstract away all three layers behind a single, consistent API.

The aggregator model

An aggregator (also called an AISP — Account Information Service Provider) holds the eIDAS certificate, maintains connections to hundreds of banks, and exposes a unified REST API:

import requests

# One API key, no certificates
headers = {"Authorization": "Bearer obi_your_api_key"}
response = requests.get(
    "https://api.open-banking.io/v1/accounts/{account_id}/transactions",
    headers=headers
)
transactions = response.json()

You authenticate with a simple bearer token. The aggregator handles:

The eIDAS certificate and TPP registration
The OAuth + SCA consent redirect
Normalizing 3,000+ bank APIs into one consistent schema
Handling token refresh, reconnection, and rate limits

The trade-off: you pay per API call or a monthly fee, and you trust the aggregator with credentials/access to your financial data.

Certificate-free aggregators: a newer option

Most aggregators still require you to go through their onboarding, which can involve KYC, compliance checks, and minimum volume commitments. But a newer category — certificate-free aggregators — strips even that down.

Services like open-banking.io provide a bearer-token REST API where:

No eIDAS certificate is needed (the aggregator holds it)
No minimum volume or enterprise contract
You sign up, get an API key, and start calling
Pricing is usage-based (from a few euros/month)

This makes it viable for hobby projects, personal finance dashboards, and SMB integrations that can't justify the cost of a full enterprise aggregator contract.

When to use what

Approach	Cost	Effort	Best for
Direct bank API (own eIDAS cert)	€2k–€10k/yr + regulatory work	Very high	Banks, large fintechs, regulated TPPs
Enterprise aggregator (Plaid, Tink, etc.)	Negotiated, often $500+/mo	Medium (KYC + integration)	Funded startups, established fintechs
Certificate-free aggregator	€3–€50/mo, usage-based	Low (API key + REST calls)	Indie devs, SMBs, self-hosted tools

Practical example: reading transactions

Here's what the full flow looks like with a certificate-free aggregator:

import requests

BASE = "https://api.open-banking.io/v1"
HEADERS = {"Authorization": "Bearer obi_your_api_key"}

# 1. List available institutions
institutions = requests.get(f"{BASE}/institutions?country=DE", headers=HEADERS).json()

# 2. Create an authorization link (user consents via their bank)
auth = requests.post(f"{BASE}/authorization", json={
    "institution_id": institutions[0]["id"],
    "redirect_uri": "https://yourapp.com/callback"
}, headers=HEADERS).json()

# User visits auth["link"], authenticates with their bank, returns to your redirect_uri

# 3. Fetch transactions (after the user completes consent)
account_id = auth["account_id"]
txns = requests.get(
    f"{BASE}/accounts/{account_id}/transactions",
    headers=HEADERS
).json()

for t in txns["transactions"]:
    print(f"{t['date']} | {t['amount']:>10.2f} | {t['description']}")

No certificates. No regulatory paperwork. One HTTP library.

The bottom line

The "open" in open banking refers to the regulatory mandate for banks to open their APIs — not to those APIs being easy to use. The authentication complexity is intentional: it protects users. But it also creates a natural market for aggregators that absorb that complexity.

If you're building a fintech product with funding and regulatory backing, going direct with your own eIDAS certificate makes sense. For everyone else — indie developers, small businesses, self-hosted personal finance tools — an aggregator (especially a certificate-free one) is almost always the right call.

The key is understanding what you're paying for: not just API access, but the entire regulatory and integration layer that makes that access possible.

I build open-banking.io — a certificate-free open banking API for EU/UK bank data. No eIDAS certificates, no minimums, just a bearer token and REST calls.

Nordigen Alternatives in 2026: A Developer's Guide to European Bank Data APIs

John Frandsen — Fri, 10 Jul 2026 10:30:14 +0000

Nordigen (now part of GoCardless) pioneered free PSD2 account information services in Europe. But as the open banking landscape matures in 2026, developers and small teams are evaluating alternatives for good reasons: pricing changes after acquisition, rate limits on free tiers, and the question of whether you need an aggregator at all versus connecting directly to bank APIs.

This guide compares the main Nordigen alternatives for accessing European bank account data, with a focus on what matters to developers and small businesses: cost, certificate requirements, bank coverage, and self-hosting options.

Why Look Beyond Nordigen?

Nordigen was acquired by GoCardless in 2022, and since then the product has been integrated into the GoCardless platform. For developers who originally chose Nordigen for its free, developer-friendly API, several shifts have prompted a search for alternatives:

Pricing uncertainty: The free tier has become more restrictive, and pricing for production use is less transparent than it was as an independent company.
Aggregator dependency: Every request routes through Nordigen's infrastructure. If their service degrades, your application degrades.
Data sovereignty: Some teams prefer to hold bank API connections directly rather than routing through a third party.

The Key Question: Aggregator or Direct API?

Before comparing specific alternatives, it's worth understanding the two architectural approaches:

Aggregators (Nordigen, TrueLayer, Tink, Salt Edge) provide a unified API that abstracts away individual bank APIs. You integrate once and get access to hundreds of banks. The trade-off is an additional layer between you and the bank, plus per-API-call costs.

Direct API / Self-hosted approaches let you connect to bank APIs yourself using PSD2 open banking standards. This eliminates the aggregator middleman and per-call fees but requires you to handle bank API differences, authentication flows, and — traditionally — an eIDAS QWAC certificate.

Nordigen Alternatives Compared

1. TrueLayer

TrueLayer is the most prominent Nordigen competitor in the UK and European markets. They offer a polished API with strong documentation and broad bank coverage.

Coverage: 1,500+ banks across Europe
Pricing: Free sandbox; production pricing is usage-based, starting around £0.10-0.30 per successful API call depending on endpoint
Certificate required: No — TrueLayer handles PSD2 compliance
Best for: Teams that want a premium managed API and can absorb per-call costs

2. Tink (Visa)

Tink was acquired by Visa in 2022 and offers account aggregation, payment initiation, and data enrichment. Their API is well-regarded for data quality and categorization features.

Coverage: 6,000+ banks globally (including non-PSD2 markets)
Pricing: Enterprise-focused; limited free tier
Certificate required: No — Tink handles compliance
Best for: Larger teams needing enrichment and cross-market coverage

3. Salt Edge

Salt Edge has been operating since 2013 and covers both European PSD2 banks and global banks outside the PSD2 framework.

Coverage: 500+ banks in Europe, plus global coverage
Pricing: Tiered plans; developer sandbox available
Certificate required: No
Best for: Teams needing coverage outside Europe alongside PSD2 banks

4. GoCardless (Formerly Nordigen)

After acquiring Nordigen, GoCardless integrated the open banking data API into their broader payment platform. The Nordigen API still works but is increasingly bundled with payment initiation products.

Coverage: 2,300+ banks in 31 European countries
Pricing: Free tier still available (with limits); paid tiers bundled with GoCardless payment products
Certificate required: No
Best for: Teams already using GoCardless for direct debit payments

5. open-banking.io (Cert-Free Direct API)

For developers who want to connect to European bank APIs directly without an aggregator — and without the eIDAS certificate cost — open-banking.io provides a PSD2-compliant API layer that handles the bank connection protocol without requiring you to purchase a €2,000-6,000 annual QWAC certificate.

Coverage: European banks supporting Berlin Group NextGenPSD2 or UK Open Banking standards
Pricing: No per-call fees; self-hostable
Certificate required: No — the cert-free architecture is the core differentiator
Best for: Developers, self-hosters, and small businesses that want direct bank connections without aggregator markups or certificate overhead

Comparison Summary

Feature	Nordigen/GoCardless	TrueLayer	Tink	open-banking.io
Pricing model	Free tier + usage	Per-call	Enterprise	No per-call fees
Certificate needed	No	No	No	No
Self-hostable	No	No	No	Yes
Bank coverage	2,300+ EU	1,500+ EU/UK	6,000+ global	EU PSD2 banks
Data enrichment	Basic	Yes	Advanced	No
Payment initiation	Yes (via GoCardless)	Yes	Yes	Read-only focused

How to Choose

Choose an aggregator (TrueLayer, Tink, Salt Edge) if you need:

Maximum bank coverage with a single integration
Data enrichment (merchant identification, categorization)
Payment initiation alongside account data
A managed service with SLAs

Choose a direct/self-hosted approach (open-banking.io) if you need:

No per-call or per-account fees
Full control over your data pipeline
Self-hosting on your own infrastructure
Read-only account information without payment initiation complexity

Stay with Nordigen/GoCardless if you:

Are already integrated and the API meets your needs
Use GoCardless for payments and want unified billing
Need the free tier for low-volume use

The Certificate Question

The single biggest barrier to direct PSD2 API access has been the eIDAS QWAC (Qualified Website Authentication Certificate) requirement. These certificates cost €2,000-6,000 per year and require an extended validation process with an eIDAS-qualified trust service provider.

This is precisely why aggregators like Nordigen gained traction: they absorb the certificate cost and complexity. The emerging alternatives — including cert-free approaches — aim to remove this barrier so that individual developers and small businesses can access bank data directly.

Conclusion

The Nordigen alternative landscape in 2026 is healthy and diverse. Managed aggregators like TrueLayer and Tink offer convenience and enrichment at a per-call cost. Direct API approaches like open-banking.io offer independence and cost predictability for teams willing to handle integration themselves. The right choice depends on your team size, budget, and whether you value managed convenience over architectural control.

What's your experience with Nordigen or other open banking APIs? I'd love to hear about your use case in the comments.

How to Sync Bank Transactions with Open Banking APIs (2026 Guide)

John Frandsen — Thu, 09 Jul 2026 21:55:22 +0000

Most open banking tutorials stop at "make a GET request." In production, you need consent flows, token refresh, pagination across thousands of transactions, deduplication, and rate-limit handling. This guide walks through the full sync pipeline — what actually breaks at 3am when your cron job fires.

The sync lifecycle

A real bank-data sync has four phases:

Onboard: User consents to read-only access → you get a consent token
Initial fetch: Pull all historical transactions (can be thousands)
Incremental sync: Poll for new transactions on a schedule
Token refresh: Consent expires (90 days default under PSD2) → re-authorize

Choosing a provider

Provider	Cert needed?	Pricing model	Bank coverage
Plaid	Per-region	Per-item ($0.20-0.50/mo)	12,000+ globally
TrueLayer	Yes (eIDAS QWAC)	Volume tiers	1,500+ EU/UK
Tink	Yes (eIDAS QWAC)	Custom	3,400+ EU/UK
GoCardless (Bank Account Data)	No (they hold the cert)	Free tier → paid	1,500+ EU/UK
open-banking.io	No	~€3/mo flat	2,500+ EU/UK

Disclosure: I maintain open-banking.io. The rest of this guide is vendor-neutral — pick whichever fits your stack.

The eIDAS QWAC certificate is the hidden gatekeeper. It costs €3,000-15,000/year, requires an annual audit, and takes weeks to obtain. If you're a solo developer or small team, providers that absorb the certificate (GoCardless, open-banking.io) save you that entire process.

Step 1: The consent flow

All PSD2 Account Information Service (AIS) providers use a similar OAuth-style redirect:

// 1. Redirect user to the bank's consent page
const authUrl = provider.getAuthUrl({
  redirect_uri: 'https://yourapp.com/callback',
  scope: 'accounts transactions',
  access_valid_for_days: 90
});

// User clicks → bank asks "Allow YourApp to read your transactions?"
// User approves → redirects back with a code

The consent token you receive is time-limited (PSD2 mandates max 180 days, most default to 90). Store the expiry date — you'll need it.

Step 2: Fetch accounts

async function getAccounts(consentToken) {
  const res = await fetch(`${API_BASE}/accounts`, {
    headers: { 'Authorization': `Bearer ${consentToken}` }
  });
  const data = await res.json();
  return data.accounts; // [{ id, iban, name, currency, balance }]
}

Step 3: Sync transactions (the hard part)

This is where tutorials end and production begins:

async function syncTransactions(accountId, consentToken, lastSyncCursor) {
  let allTransactions = [];
  let cursor = lastSyncCursor;
  let hasMore = true;

  while (hasMore) {
    const url = `${API_BASE}/accounts/${accountId}/transactions?cursor=${cursor}`;
    const res = await fetch(url, {
      headers: { 'Authorization': `Bearer ${consentToken}` }
    });

    if (res.status === 429) {
      // Rate limited — back off
      const retryAfter = res.headers.get('Retry-After') || 60;
      await sleep(retryAfter * 1000);
      continue;
    }

    const page = await res.json();
    allTransactions.push(...page.transactions);

    cursor = page.next_cursor;
    hasMore = page.has_more;

    // Respect rate limits between pages
    await sleep(200);
  }

  return { transactions: allTransactions, nextCursor: cursor };
}

Deduplication

Banks will return overlapping transactions between syncs. The cursor handles most of this, but edge cases exist:

A pending transaction settles (bookingDate changes, transactionId may change)
A transaction is reversed and re-booked
The bank back-dates a transaction

Store a composite key: {bankTransactionId, bookingDate, amount}. If the bank provides a transactionId or entryReference, prefer that. If not, hash the three fields above.

function dedupeKey(tx) {
  const id = tx.transactionId || tx.entryReference;
  if (id) return id;
  return `${tx.bookingDate}:${tx.amount}:${tx.counterpartyIban || ''}`;
}

Step 4: Token refresh

PSD2 consent expires. You cannot silently refresh it — the user must re-authorize. Design for this:

async function checkConsent(consentToken) {
  const res = await fetch(`${API_BASE}/accounts`, {
    headers: { 'Authorization': `Bearer ${consentToken}` }
  });

  if (res.status === 401 || res.status === 403) {
    // Consent expired or revoked
    notifyUser('Your bank connection needs reauthorization');
    return { valid: false, needsReauth: true };
  }

  return { valid: true };
}

Send the notification early (7 days before expiry). Users who see "reconnect your bank" at the moment of need will do it. Users who see it when they're not using your app will ignore it.

Production checklist

Rate limits: Most providers allow 4-15 requests/minute per consent. Batch where possible.
Idempotency: Use the bank's transactionId as your dedup key, not your own generated ID.
Pagination: Some banks return 100/page, others 500. Always respect the has_more flag.
Webhooks: Some providers offer transaction webhooks (push instead of poll). Use them if available — they reduce API calls by 90%+.
Error handling: Banks go down. The PSD2 network is 6,000+ banks — some will be unavailable. Retry with exponential backoff, but don't block the entire sync on one failing account.
Data freshness: Transactions can appear 1-3 days after the actual payment (pending → booked). Don't display "real-time" if you're polling daily.

What breaks in production

The three things that caused the most production incidents in my experience:

Consent expiry cascade: Multiple users' consents expire on the same day (if you onboarded them in a batch). Your reauth notification queue overflows. Stagger onboarding or add jitter to expiry notifications.
Transaction ID instability: Some banks change the transactionId when a pending transaction settles. Your dedup fails and you get duplicates. Always store both pending and booked versions, and reconcile by matching on amount + date + counterparty.
Rate limit headers: Some providers return X-RateLimit-Remaining in headers, not the response body. If you ignore headers, you'll get 429s that seem random.

The open banking APIs are powerful, but the production details — consent lifecycle, deduplication, rate limiting — are where most integrations stall. The providers above all expose similar REST APIs, so the patterns in this guide apply regardless of which one you choose.

If you're building something with bank data and want a certificate-free starting point, open-banking.io (which I maintain) offers a simple server-to-server API at around €3/month — but the architecture patterns here work with any PSD2 provider.

DEV Community: John Frandsen

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

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

Why look beyond Plaid in Europe?

TL;DR comparison

The PSD2 landscape: AIS, PIS, and certificates

The eIDAS problem (and how to dodge it)

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

Code: the same task, three ways

How to choose (a 60-second framework)

A note on affiliation

fintech #api #banking #psd2

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

Why MCP is the right shape for this

The architecture

A minimal MCP server

Point Claude Desktop at it

Cert-based vs cert-free MCP access

Security notes worth stating plainly

What this unlocks

European Alternatives to Plaid: Open Banking APIs Compared

Why European Developers Need Plaid Alternatives

The eIDAS Certificate Problem

European Open Banking APIs Compared

The Pattern

What Indie Developers Actually Need

Evaluating Your Options

The Bottom Line

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

The aggregator vacuum, explained

Why MCP makes this acute

What a certificate-free read tier would unlock

A sketch of what the agent side looks like

The takeaway

GoCardless Bank Account Data Alternatives: What to Use When Signups Are Disabled

What happened

The alternatives compared

Why certificate-free matters more than you think

How to migrate from GoCardless BAD

What to do right now

Five Ways to Access European Bank Data in 2026 (And What Each Actually Costs)

The Five Paths to European Bank Data (And What Each One Actually Costs)

Path 1: Become a TPP yourself

Path 2: Use a licensed aggregator (Plaid, TrueLayer, Yapily)

Path 3: Nordigen / GoCardless Bank Account Data

Path 4: Enable Banking

Path 5: Cert-free proxy services

How to choose

Reading EU Bank Transactions With Python and PSD2 — Without Buying an eIDAS Certificate

The short version

What you'll need

Step 1: Get your API key

Step 2: Initiate a bank connection

Step 3: Fetch accounts and balances

Step 4: Fetch transactions

Gotchas worth knowing

When you should get the certificate

Open Banking Without an eIDAS Certificate: A Practical Developer's Guide (2026)

The two paths to a bank's API

Path A — Direct (you hold the eIDAS certificate)

Path B — Aggregator (the aggregator holds the certificate)

How the cert-free flow actually works

Real code: your first cert-free bank-data call

Step 1 — Create a requisition (pick a bank)

Step 2 — List the linked accounts

Step 3 — Fetch balances and transactions

A tiny Python client

Five gotchas that cost me real time

When should you actually get the certificate?

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