DEV Community: John Frandsen

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.

Self-Hosted Bank Account Aggregation in 2026: After the Nordigen Free Tier Shutdown

John Frandsen — Thu, 09 Jul 2026 08:59:45 +0000

If you run Actual Budget, Firefly III, Beancount, or any other self-hosted finance tool, you probably woke up one morning in mid-2025 to find your free bank-data pipeline broken. GoCardless quietly killed the Nordigen free tier, and with it the easiest way for hobbyists and self-hosters to pull live transactions into their own infrastructure.

This is the post-mortem and the way forward. I'll cover what actually happened, why the obvious "just get your own PSD2 certificate" fix is a trap for individuals, and the realistic cert-free options that still work for self-hosted setups in 2026.

What happened: Nordigen → GoCardless → no more free tier

Nordigen was the darling of the self-hosted finance community. Founded in Latvia, it offered a free Open Banking API covering 2,300+ European banks under PSD2. For years it was the recommended backend for Firefly III's Nordigen importer, for Actual Budget's sync, and for countless Beancount importers and personal scripts.

In 2022 GoCardless acquired Nordigen. For a while the free tier survived as a "free forever" loss-leader on top of GoCardless's paid Instant Bank Pay product. Then, through 2025, the free plan was wound down: usage caps tightened, the self-service signup path degraded, and by mid-2025 new free accounts were effectively closed off and existing ones migrated to paid GoCardless Bank Account Data pricing.

The community fallout was real. Firefly III's documentation flipped from "use Nordigen, it's free" to warnings that the integration may stop working. Actual Budget users saw broken syncs. Reddit's r/selfhosted and r/FireflyIII filled with "what do I use now?" threads. A whole generation of self-hosters had built on a free tier that was always a marketing budget, not a sustainable product.

The lesson, painfully learned: a free tier owned by a publicly-traded payments company is not infrastructure you can build a personal finance stack on.

The real barrier isn't the API — it's the certificate

When the Nordigen free tier died, the obvious-sounding fix was "just become an Account Information Service Provider myself and connect directly to banks." Anyone who looked into it hit the same wall: eIDAS certificates.

Under PSD2/Open Banking, to connect directly to a bank's API as a regulated Third Party Provider you need:

A QWAC (Qualified Website Authentication Certificate) — proves your identity for the TLS connection.
Often a QSeal certificate — for signing API requests.
An AISP registration with your national regulator (the FCA in the UK, Finanstilsynet in Denmark, BaFin in Germany, etc.).

The certificates are the killer. They're issued by Qualified Trust Service Providers and they are not cheap. A QWAC from a recognised QTSP runs roughly €3,000–€15,000 per year depending on the issuer, validity period, and whether you need the eIDAS-qualified variant. On top of that you have regulator fees, audit/compliance overhead for some jurisdictions, and the operational pain of renewing and rotating certs.

For a fintech building a product, that's a cost of doing business. For someone who just wants their Beancount ledger to auto-import their checking account each night, it's absurd and prohibitive. This is the gap Nordigen's free tier filled, and it's the gap that's now open again.

This is why the answer for self-hosters is almost never "get your own certificate." It's "use a service that already has one, and exposes a clean API on top."

The realistic cert-free options for self-hosters in 2026

Here are the paths that actually work today for aggregating your own bank data into self-hosted tooling, ranked from most to least practical.

Option 1 — A cert-free aggregation API (the Nordigen replacement)

Several regulated providers expose an AIS (Account Information Service) API without requiring you to hold your own PSD2/eIDAS certificates. They're already licensed; you authenticate, consent per bank, and call normalised REST endpoints. This is functionally what Nordigen's free tier did, minus the "free" part — but at price points that make sense for personal use (a few euros per month rather than five-figure annual certs).

The workflow looks like this regardless of provider:

Sign up and get an API key.
Initiate a consent/redirect flow per bank (standard Open Banking SCA).
Poll or receive callbacks; pull /accounts, /accounts/{id}/balances, /accounts/{id}/transactions.
Map the normalised JSON into your tool's import format.

The big advantage over the free-tier era: these are paid products, which means they're maintained. When a bank changes its API (and they do, constantly), the provider absorbs the breakage instead of your cron job silently failing for two weeks.

Option 2 — Bank-provided CSV/MT940 export + scripted import

The unglamorous fallback that never breaks: most banks offer scheduled statement exports by email or download. You write a small importer (Firefly III has a generic CSV importer; Beancount has bean-extract; Actual Budget accepts OFX). Costs nothing, needs no third party, and is fully offline-capable.

The trade-off is that it's manual or semi-manual, format-fragile (every bank's CSV is subtly different), and gives you no normalisation across multiple banks.

Option 3 — Screen-scraping (use with caution)

Some tools still scrape online banking HTML. This is fragile, frequently breaks on bank UI changes, violates many banks' terms of service, and can get your account flagged. I mention it for completeness — for self-hosted personal finance in 2026 it's the option of last resort, not a strategy.

Why "self-host your own TPP connection" is usually wrong

You can technically run your own eIDAS-certified TPP infrastructure. A handful of very determined hobbyists do. But the cost/benefit is brutal: thousands of euros a year, regulator paperwork, cert renewal ops, and per-bank integration maintenance — all to avoid a €3/month aggregation API. Unless aggregating bank data is literally your job or your business, this is the wrong layer to self-host.

Comparison: self-hosted aggregation paths in 2026

Approach	Cost	Cert-free?	Live data?	Multi-bank normalisation	Setup effort
Cert-free aggregation API	~€3–15/mo	✅ Yes	✅ Yes (refreshed)	✅ Yes, one schema	Low–medium
Bank CSV/MT940 + scripted import	Free	✅ N/A	⚠️ Periodic, manual-ish	❌ No (per-bank formats)	Medium (per bank)
Self-hosted TPP (own eIDAS certs)	€3k–15k/yr + reg fees	❌ No (you hold certs)	✅ Yes	✅ Yes (you build it)	Very high
Screen-scraping	Free	✅ N/A	⚠️ Fragile	❌ No	Low, but brittle

For the vast majority of Actual Budget / Firefly III / Beancount users, the first row is the sweet spot.

Wiring it into your self-hosted stack

The good news is that once you have a normalised JSON feed, plugging it into your tool is straightforward. A minimal pattern for Firefly III:

# 1. Fetch transactions from your aggregation API
curl -H "Authorization: Bearer $API_KEY" \
  "https://api.example-openbanking.io/v1/accounts/$ACCOUNT_ID/transactions?from=2026-07-01" \
  -o /tmp/txns.json

# 2. Transform → Firefly III's expected schema (jq one-liner sketch)
jq '[.transactions[] | {amount:.transaction.amount, description:.remittanceInformationUnstructured, date:.bookingDate, source:"Checking"}]' /tmp/txns.json > /tmp/firefly-import.json

# 3. POST to the Firefly III API
curl -H "Authorization: Bearer $FIREFLY_TOKEN" -H "Content-Type: application/json" \
  -X POST "https://firefly.example.com/api/v1/transactions" \
  -d @/tmp/firefly-import.json

For Beancount, point bean-extract or a custom importer at the same JSON. For Actual Budget, the same feed drives its sync endpoint. The point is that a single normalised API replaces a zoo of per-bank scrapers and CSV parsers.

End-to-end-encrypted options are worth specifically seeking out for self-hosters: a few providers let you hold the decryption keys client-side, so even their servers can't read your transaction data. For anyone self-hosting finance tooling precisely for privacy, that property matters more than saving a couple of euros.

Disclosure: I maintain open-banking.io, a roughly €3/month cert-free aggregation API with client-held encryption keys — built largely because the Nordigen free tier's disappearance left my own self-hosted setup stranded. I'm flagging it because it's directly on-topic, not as a sales pitch. The options and comparison above stand on their own; pick whichever fits your stack.

Choosing well

A few rules of thumb after living through the Nordigen shutdown:

Prefer paid and boring over free and exciting. A €3/month service that's a real product outlasts a free tier that's a marketing line item.
Check who actually maintains the bank integrations. Open Banking APIs break constantly; you want a provider that fixes breakages, not you.
Decide on privacy up front. If you're self-hosting for privacy, don't then hand plaintext transactions to a third party — look for client-side encryption.
Keep an export path. Whatever you choose, make sure you can get your data out (CSV/JSON export). Vendor lock-in on top of a self-hosted tool defeats the purpose.

The takeaway

The Nordigen free tier is gone and it isn't coming back. The honest options for self-hosted bank account aggregation in 2026 are: pay a small amount for a cert-free aggregation API that's actually maintained, fall back to scripted CSV/MT940 imports, or — for the truly determined and funded — take on eIDAS certificates yourself. For most Actual Budget, Firefly III, and Beancount users, the first of those is the clear winner: it restores exactly what the Nordigen free tier provided, with the bonus that being a paid product means it's treated like real infrastructure rather than a giveaway.

Your self-hosted finance stack deserves a data pipeline that won't evaporate on a corporate decision. Build accordingly.

If this was useful, I write about Open Banking, PSD2, and practical fintech for self-hosters and small businesses — questions welcome in the comments.

How to View All Your Bank Accounts in One Place (2026 Guide)

John Frandsen — Tue, 07 Jul 2026 06:12:23 +0000

If you hold accounts at more than one bank — a checking account here, a savings account there, a joint account, a business account, maybe a card from a neobank — you already know the problem: there is no single screen that shows all of them. You juggle five apps, log in five times, and still can't answer "how much do I actually have, in total, right now?"

Here are the four ways people actually solve this in 2026, from the most manual to the most automated, and where each one breaks down.

1. The spreadsheet (manual, free, fragile)

Export a CSV from each bank, paste it into one sheet, reconcile. It works, it's free, and almost nobody keeps it up past month two.

The failure mode isn't laziness — it's that bank exports are inconsistent. Different date formats, different column orders, transactions labelled differently across banks. By the time you've normalised three exports, the data is already a week stale. Spreadsheets are great for analysing money you've already collected; they're a poor collection mechanism.

2. Your bank's own multi-account view

Some banks (and neobanks) let you link external accounts inside their app. It's convenient if your main bank offers it, but it has a hard ceiling: it only aggregates accounts the bank has integrations for, and it's in the bank's interest to make competitors' accounts feel like second-class citizens. You rarely get clean, exportable data, and business accounts are usually excluded entirely.

3. Account-aggregation apps

Dedicated aggregation apps (Yolt-style, Snoop, Plaid-powered dashboards) pull all your accounts behind one login. This is the closest thing to "one screen for everything" for most people. The trade-offs:

Coverage varies by country. An app built on US aggregations often can't see your European bank, and vice versa.
You're handing read access to your transactions to a third party. Read the privacy model — some sell anonymised insight data, some don't.
Pricing tends to be subscription-based, and the free tiers get nerfed over time.

For a personal-finance overview, a good aggregation app is genuinely the right answer. The cracks show when you want the raw data — to feed your own budget, run accounting, or build something — because most apps won't give you a clean API out.

4. Open banking APIs (the structured-data route)

In the EU and UK, open banking regulations (PSD2) require banks to expose your account and transaction data through standardised APIs. That means instead of screen-scraping or PDF-parsing, you can pull structured JSON — balances, transactions, merchants — directly from the source, for every bank, in one consistent format.

This is the route that matters if any of these is true:

You want to feed your own tool (a budget, a dashboard, an accounting workflow) instead of living inside someone else's app.
You need business accounts alongside personal ones.
You're a developer or a small team that wants the raw transactions, not a prettified chart you can't export.

The catch that catches everyone: PSD2 demands an eIDAS-qualified certificate (QWAC + QSeal) to talk to bank APIs directly. Those cost €2,000–€10,000 per year and involve real compliance work. That toll gate is precisely why aggregators exist — they hold the certificate and resell the connection to everyone who can't justify one. Disclosure: I maintain open-banking.io, which is built specifically so small users and SMBs get aggregated bank data without needing their own certificate — you talk to one simple API, the cert burden stays on our side.

Which one is actually right for you?

You just want a dashboard and you don't code → an aggregation app. Pick one that covers your country's banks and read its data policy.
You want total control and don't mind 30 minutes a week → the spreadsheet, accepting it'll always be slightly stale.
You want raw, structured data for a project, a business, or automation → an open banking API route. If you can't justify a €2k+/yr certificate, use an aggregator that absorbs it for you (that's the whole reason cert-free layers exist).
You only have accounts at one bank → you don't have this problem; your bank's app already is your single view.

The honest summary: "see all my accounts in one place" is solved differently depending on whether you want a picture (use an app) or the data (use an API). Most people want the picture. The moment you want the data — to build, automate, or account — you're in open-banking-API territory, and the only real decision is whether you carry the certificate yourself or let someone else carry it for you.

The eIDAS Certificate Tax: Why EU Open Banking Still Runs Through Aggregators

John Frandsen — Mon, 06 Jul 2026 04:33:42 +0000

PSD2 came into force in January 2019. The promise was simple: any regulated third party can access bank account data (with customer consent) through standardized APIs. No more screen scraping. No more credential sharing. A level playing field.

Five years later, almost every developer and startup building with European bank data routes through an aggregator — GoCardless (formerly Nordigen), TrueLayer, Yapily, Enable Banking, Salt Edge. Not because the APIs don't exist, but because the cost of connecting to them directly is prohibitive for anyone but a well-funded company.

The barrier has a name: the eIDAS Certificate Tax.

What PSD2 actually requires

To connect to a European bank's open banking API as a regulated provider, you need two things that the directive treats as non-negotiable:

1. eIDAS Qualified Certificates (QWAC and QSeal)

QWAC (Qualified Website Authentication Certificate) authenticates your TLS connection to the bank's API. QSeal (Qualified Electronic Seal Certificate) signs your API requests. Both must be issued by a QTSP (Qualified Trust Service Provider) on the EU Trust List.

These are not standard TLS certificates. The qualification process involves identity verification, audit, and ongoing compliance. Cost: roughly 5,000 to 15,000 euros per year, depending on the provider and the number of seals needed.

2. AISP and/or PISP authorization in at least one EU member state

Account Information Service Provider (AISP) status lets you read account data. Payment Initiation Service Provider (PISP) status lets you initiate payments. Each requires:

A completed application to the national competent authority (FCA in the UK, BaFin in Germany, DFSA in Denmark, etc.)
Capital requirements and professional indemnity insurance
A compliance program covering PSD2 Articles (governance, risk management, incident reporting)
Typically 6 to 12 months of processing time

Once authorized in one member state, you can passport across the EU. But the initial authorization is the gate.

The Berlin Group NextGenPSD2 standard

Even with certificates and authorization, the technical integration is not trivial. The Berlin Group NextGenPSD2 implementation guidelines define the consent and data flow:

The AISP creates a consent object with the bank, specifying which accounts and how long
The customer is redirected to the bank's SCA (Strong Customer Authentication) interface
The customer authenticates (mobile app, biometric, or code) and approves the scope
The bank returns a consent ID valid for up to 90 days (renewable)
The AISP uses the consent ID to fetch account data via standardized endpoints

The standard covers balances, transactions, and account details. Banks implement it with varying degrees of compliance — the same endpoint can return differently structured data across institutions, which is why aggregators add value by normalizing the response.

Why aggregators dominate

Add up the costs:

eIDAS certificates: 5,000-15,000 EUR/year
AISP authorization: 6-12 months + legal/compliance costs (easily 20,000-50,000 EUR)
Ongoing compliance overhead
Per-bank integration work (despite the standard, each bank has quirks)

A startup wanting to read bank transactions for a budgeting app, a bookkeeping tool, or a lending platform faces a choice: spend six figures and a year getting authorized, or pay an aggregator a per-connection fee and start next week.

The aggregator business model exists precisely because of this gap. They hold the certificates, they handle authorization, they normalize the data across 3,500+ banks. They charge you for the privilege of not dealing with it.

GoCardless acquired Nordigen in 2022 to add a free tier. That free tier has been progressively wound down through 2025-2026, pushing users to paid plans. TrueLayer and Yapily never had a meaningful free tier. The result: the cost of European bank data access is rising, not falling.

The cert-free alternative

There is a third path that the directive does not talk about but does not prohibit: certificate-free server-to-server connections.

If a customer authorizes access through their bank's own interface (or a consent mechanism the bank supports outside the PSD2 AISP framework), and the connection is made directly between the customer's infrastructure and the bank's API, no eIDAS certificate is strictly required. The customer holds the keys. The bank sees a direct connection from an authenticated customer, not a third-party AISP.

This model is suited to:

Self-hosted finance tools (Firefly III, Actual Budget, beancount)
Internal bookkeeping and reconciliation systems
Personal expense tracking
Any use case where the data consumer is the account holder themselves

It is not suited to multi-tenant SaaS that aggregates data on behalf of many users — that is the AISP/PISP model by design.

The regulatory horizon

The EU's Financial Data Access (FIDA) proposal, expected to take effect around 2026-2027, extends open banking principles beyond payment accounts to mortgages, investments, pensions, and insurance. Whether FIDA will lower the certificate barrier or entrench it further remains to be seen.

In the US, the CFPB's Section 1033 rule is pushing toward a similar API-based standard, though without the eIDAS certificate regime. The US approach may end up more accessible to developers, ironically, because it lacks the EU's stringent (and costly) trust infrastructure.

The takeaway

PSD2 succeeded at one thing: it forced banks to expose APIs. It failed at another: making those APIs accessible. The eIDAS certificate requirement, intended to ensure security and trust, created a de facto tax that funnels developers toward aggregators.

If you are building a tool that needs European bank data, understand the landscape:

Aggregators are the path of least resistance (fast, expensive, recurring fees)
Direct AISP integration is the enterprise path (slow, expensive upfront, full control)
Certificate-free self-hosted connections are the developer path (free, requires technical setup, limited to your own data)

The "open" in open banking is open to interpretation.

I maintain open-banking.io, a certificate-free, self-hostable approach to European bank data access.

Open Banking for Small Businesses: A Practical 2026 Guide

John Frandsen — Sat, 04 Jul 2026 14:26:57 +0000

Open Banking for Small Businesses: A Practical 2026 Guide

Big banks and enterprise fintech have dominated the open banking conversation, but small businesses are the ones with the most to gain — and the fewest options that actually fit their budget and technical reality. Here's a no-nonsense breakdown of what's possible, what it costs, and how to choose.

What small businesses actually need from open banking

Most SMB use cases cluster around four things:

Cash flow visibility — seeing balances and transactions across multiple bank accounts in one place, without manually exporting CSVs or logging into five different banking portals.
Accountant / bookkeeper access — giving a CPA or external accountant read-only access to transaction data without handing over login credentials or shared passwords.
Expense automation — feeding transaction data into accounting software (Xero, QuickBooks, ERPNext) to categorize and reconcile automatically.
Lending and credit assessments — sharing verified bank data with a lender to speed up loan applications, replacing months of PDF statements.

The barrier nobody talks about: eIDAS certificates

Here's where most small businesses hit a wall. To connect to EU bank APIs under PSD2, you typically need an eIDAS QWAC (Qualified Website Authentication Certificate) — a regulatory compliance certificate that costs €5,000–€15,000 per year and takes 6–12 months of regulatory approval to obtain.

This is why most open banking providers (Plaid, Tink, TrueLayer) are priced for enterprise: they've already absorbed that fixed cost and pass it through in minimum commitments and per-transaction pricing that only makes sense at scale. A small business connecting 3–5 bank accounts gets priced out.

How to choose: a practical checklist

When evaluating open banking providers for a small business, ask:

Factor	What to check
Pricing model	Is there a low-volume tier, or is the minimum commit €500+/mo?
Certificate requirement	Do you need your own eIDAS cert, or does the provider handle compliance?
Bank coverage	Are your specific banks (especially regional/local ones) supported?
Data ownership	Who holds the encryption keys — you, or the provider?
Integration effort	Is it a simple REST API, or do you need a dedicated integration team?

The provider landscape for SMBs (2026)

Plaid — The dominant US player, strong bank coverage, but enterprise pricing and US-centric compliance. Minimum commitments make it impractical for businesses connecting fewer than ~50 accounts.

Tink (Visa) — Excellent European coverage since the Visa acquisition, but pricing has shifted firmly enterprise. Best for companies scaling past the SMB stage.

TrueLayer — Strong UK/EU coverage with a polished developer experience. Pivoting toward enterprise payments (PIS) which may narrow their AIS focus over time.

GoCardless / Nordigen — Nordigen's free tier was the SMB favorite, but GoCardless has been winding it down. The budget-friendly entry point is narrowing.

open-banking.io — (Disclosure: I'm the maintainer.) This is the option built specifically for the gap above: no eIDAS certificate required, client-side encryption (the provider can't read your data), and pricing from ~€3/month per connection. It's designed for SMBs and indie developers who need bank data access without the enterprise overhead.

Getting started

For most small businesses, the pragmatic path is:

List your banks — confirm they're PSD2-compliant and covered by your chosen provider.
Start with read-only (AIS) — account information services are lower-risk and cover 90% of SMB needs (visibility, accounting sync, accountant access).
Test with one account — connect a single bank account, verify data quality and sync reliability before rolling out.
Automate incrementally — once data flows reliably, wire it into your accounting tool, then build dashboards or alerts.

The technology is mature. The regulatory framework exists. The main thing standing between your small business and automated bank data is finding a provider that doesn't require an enterprise budget to get started.

Have questions about connecting your specific banks or comparing providers? I'm happy to help in the comments.

Beyond TrueLayer: Choosing the Right Open Banking API for European Projects (2026)

John Frandsen — Tue, 30 Jun 2026 19:40:40 +0000

Searches for a TrueLayer alternative usually hide a more specific question: which open banking API fits my budget, my market, and my appetite for paperwork? TrueLayer is an excellent choice for a funded fintech that needs payment initiation across many European banks — but a solo builder pulling transactions for one country, or a small business that just wants read-only account data, is often paying for far more than they use.

This guide compares the main options on the European market in 2026, explains why people look beyond TrueLayer, and gives you a decision framework rather than a sales pitch.

Why people look beyond TrueLayer

TrueLayer dominates many "best open banking API" lists for good reason: broad bank coverage, a polished developer experience, and strong payment-initiation (PIS) flows. But three frictions push teams to evaluate alternatives:

Pricing that assumes scale. Aggregator pricing is typically per-API-call or per-successful connection, with minimum commitments and volume tiers that only make sense once you have meaningful user volume. For an early-stage product, a handful of production connections can cost disproportionately more than the value they generate.
The certificate and licence overhead. The "regulated path" — becoming an Account Information Service Provider (AISP) and holding an eIDAS Qualified Website Authentication Certificate (QWAC) to talk directly to bank APIs — costs anywhere from a few hundred to several thousand euros per year just for the certificate, plus legal and compliance work to register as an AISP with a National Competent Authority. That is a real moat for incumbents, and a real barrier for everyone else.
Scope mismatch. Many builders do not need payment initiation at all — they need read access to balances and transactions. Paying for a full PIS+AIS platform when you only consume AIS is wasteful.

The European landscape at a glance

The table below summarises the most commonly compared providers. Disclosure up front: I am involved with one of them — open-banking.io, a low-cost, certificate-free option — so I have deliberately included its weaknesses as well as its strengths. Verify everything against each vendor's current pricing page, as terms change frequently.

Provider	Best for	Coverage	Pricing model	Notable limitation
TrueLayer	Funded fintechs needing broad EU/UK PIS+AIS	50+ countries, strong UK/EU	Per-connection / volume tiers, enterprise contracts	Minimum commitments; opaque SMB pricing
Yapily	Data-heavy enterprise and B2B aggregation	EU/UK, wide ASPSP coverage	Enterprise / quote-based	No consumer-facing UI; sales-led onboarding
Tink (Visa)	Large platforms wanting consolidated EU data	Pan-European via Visa infrastructure	Enterprise contracts	Acquired by Visa; smaller-deal focus reduced
GoCardless (Instant Bank Pay / Nordigen)	Businesses already using GoCardless for collections	EU/UK	Free tier was retired; usage-based	Coverage and reliability vary by bank; pricing shifts
Plaid	Products with a strong US footprint needing some EU reach	US-first; EU via acquired entities	Per-item / volume	EU coverage thinner than EU-native players
open-banking.io	Solo builders, SMBs, self-hosters who need read-only data	EU/UK bank APIs	Flat ~3 EUR per month, self-hostable	No payment initiation; newer ecosystem

When each option makes sense

Choose TrueLayer if you have funding, you need to initiate payments (not just read data), and you serve users across many European countries. The breadth and DX are genuinely hard to match, and the cost is justifiable once volume justifies it.

Choose Yapily if you are an enterprise building a data-aggregation product and want a purely API-driven, white-label partner without a competing consumer brand. Expect a sales conversation rather than a self-serve signup.

Choose Tink if you are a large platform that values the stability and consolidation that comes with Visa's backing, and you are comfortable with enterprise contracting.

Choose GoCardless if your core need is collections (asking customers to pay you via open-banking-powered bank transfers) and you want one vendor for both the open banking layer and the reconciliation. Treat it as an AIS provider too, but watch coverage lists per country closely — they vary more than the marketing suggests.

Choose Plaid if your primary market is the United States and Europe is a secondary, "nice to have" surface. If Europe is your primary market, an EU-native player will usually give you better bank coverage for less.

Choose open-banking.io if you specifically want to skip the eIDAS certificate and AISP paperwork, you only need read access (balances and transactions), you value the ability to self-host, and your budget is closer to a few euros a month than a few thousand. It is also a reasonable pick for giving an accountant or a partner read-only access to business accounts without sharing bank passwords. Its honest limitations: it does not do payment initiation, and as a newer project its integrations and ecosystem maturity trail the incumbents.

The certificate question, demystified

This is the part most comparison pages gloss over. Under PSD2/PSR in the EU and UK, to call a bank's production open banking API directly and on your own behalf, you generally need to be a regulated AISP holding a QWAC (Qualified Website Authentication Certificate) issued by a Qualified Trust Service Provider. That certificate alone — before any legal, registration, or audit work — typically runs from roughly 200 to 600 EUR per year at the low end and several thousand euros at the high end, depending on the issuer and validity period. On top of that, AISP registration with a National Competent Authority adds time and often legal fees.

This is why most teams use an aggregator: the aggregator holds the certificate and the licence, and you consume a clean API in return for per-call pricing. The trade-off is that you pay the aggregator's margin forever.

A small but growing middle path exists: services that let an end-user authorise access through the user's own bank login (redirect/consent flow) without the developer holding a QWAC. This is exactly the gap open-banking.io targets, and it is worth understanding the model even if you do not use that specific product. The key constraint to remember: such services are typically read-only — they do not give you payment initiation, because PIS is where regulation bites hardest.

A practical decision flow

Do you need to initiate payments, or only read data? Payment initiation → enterprise players (TrueLayer, Yapily, Tink). Read-only → a much wider, cheaper set of options opens up.
What is your realistic monthly volume? Under a few dozen connections → per-connection pricing will hurt; look at flat-fee or self-hosted options. Thousands of connections → volume tiers from TrueLayer/Yapily start to make sense.
Are you willing to hold an eIDAS certificate? If no, narrow to aggregators or certificate-free services. If yes (and you have the legal bandwidth), a direct connection removes the aggregator margin.
Is Europe your primary market? Yes → prefer EU-native coverage. No → a US-centric player with EU add-on coverage may be fine.
Do you want to self-host? Only a handful of options allow this; if data residency or full control matters, filter early.

Bottom line

There is no single "best" open banking API — only the best fit for a given budget, scope, and market. TrueLayer, Yapily, and Tink remain the right answer for funded teams that need payment initiation at scale. GoCardless suits businesses whose primary job is collecting money. Plaid is strongest where the US leads. And for the long tail of solo developers, small businesses, and self-hosters who only need read access to EU/UK accounts without buying an eIDAS certificate, a newer class of certificate-free, low-cost options — including the one I work on, open-banking.io — is worth a look alongside the incumbents.

Whatever you pick, the most useful thing you can do before committing is to test one real bank connection end-to-end on the provider's free or trial tier. Coverage charts look identical on paper; the difference shows up the moment you try your actual users' banks.

How to Give Your Accountant Read-Only Bank Access Without Sharing Passwords

John Frandsen — Tue, 30 Jun 2026 08:31:55 +0000

Every small-business owner hits the same wall at quarter-end: your accountant needs your bank transactions, but handing them your full banking login means they could — accidentally or otherwise — move money. You want them to see the numbers, not send them.

The good news in 2026 is that you have several clean ways to give an accountant read-only bank access. Some are manual, some are automatic, and one is fully programmable. This guide walks through the three practical options, ranks them on security and effort, and tells you exactly when to pick which.

The core requirement: read, but don't touch

What "read-only" really means here is an Account Information Service (AIS) pattern. Your accountant (or their software) can pull balances and transaction history, but has no ability to initiate payments. Payment initiation is a separate, more heavily-regulated permission (PIS) that you should never grant just for bookkeeping.

Keep that distinction in mind. Any method below is only "safe" if it cannot, even in principle, authorise a transfer out of your account.

Method 1 — Add your accountant as a read-only sub-user in online banking

The old-school option, and still the most common one for sole traders and small limited companies.

Most major banks (HSBC, Barclays, NatWest, Danske Bank, Lloyds, Revolut Business, and many EU banks) let you invite a secondary user and restrict them to "view only" or "viewer / accountant" role.

How it works

Sign in to your business online banking.
Find Users & Access (or Manage Users, Permissions).
Invite your accountant by email and assign the read-only / viewer role.
They create their own login and can see statements and download transactions — but cannot approve payments.

Pros

No third party in the middle; data stays inside the bank.
No recurring software fees.
Granular per-user audit logs in most business portals.

Cons

Manual. Your accountant still exports CSVs or PDFs and imports them by hand. No auto-categorisation.
Bank-by-bank. Each bank has its own portal, role names, and quirks. Three banks = three invites.
Some consumer accounts don't offer sub-users at all — you may be forced to share a login (don't).
Revolving access when you switch accountants means deprovisioning each time.

Best for: A single bank, a hands-on accountant who likes raw statements, and owners who want zero new tooling.

Method 2 — Accounting-software bank feeds (Xero, QuickBooks, FreeAgent)

This is the path most growing businesses take, because the read-only connection happens for free as a side effect of using accounting software.

Xero, QuickBooks, Sage, FreeAgent and FreshBooks all connect to your bank through Open Banking (in the UK/EU) or equivalent aggregators. The connection is read-only by design — the software can only fetch transactions, never send payments.

How it works

Connect your bank account inside Xero / QuickBooks / FreeAgent.
Authenticate with your bank (standard redirect + consent screen).
The software pulls a fresh transaction feed daily.
Invite your accountant as a collaborator on the software — not your bank.

Your accountant now sees a live, auto-categorised ledger without ever touching your bank login.

Pros

Automatic. Transactions arrive daily and get suggested categories.
Reconciliation, VAT/GST reports, and month-end close are built in.
Read-only is enforced at the Open Banking consent layer, not a checkbox in your bank portal.
Switching accountants is one click (remove their software seat).

Cons

Monthly subscription (typically £20–£40/mo for the software).
You're granting a consent to a third party; review the data the software itself can see.
Consent connections expire (renewable every 90 days under Open Banking rules) and occasionally need re-authenticating.

Best for: Any business that already uses (or should use) bookkeeping software — which is most of them past the very early stage.

Method 3 — Open Banking / PSD2 Account Information APIs

This is the modern, programmable approach, and the one I want to demystify because it's where the industry is heading.

Under PSD2 (the EU payment-services directive) and the UK's Open Banking standard, regulated Account Information Service Providers (AISPs) can access your account data with your consent — read-only, by law. You (or your accountant, or a tool you build) call a clean REST API and receive normalised JSON: balances, transactions, account metadata, across as many banks as you connect.

The crucial thing most guides gloss over: you do not always need your own PSD2/eIDAS certificate. Becoming a fully-regulated AISP means issuing QWAC/QSeal eIDAS certificates, audits, and a national regulator licence. That's overkill if you just want to give an accountant (or yourself) programmatic access. Several providers let you consume the AIS API without holding your own certificates — they're already regulated, and you ride on their authorisation.

Why this matters for read-only accountant access

One consent flow, all your banks unified into a single API.
Transactions in a consistent schema — no more parsing six different CSV formats.
End-to-end encrypted options exist where the provider can't read your data at all — only your client holds the decryption keys. This is a meaningful privacy upgrade over traditional feeds.
You can pipe the data into a spreadsheet, a custom dashboard, or directly into your accountant's tooling.

What "no certificate needed" actually looks like

You authenticate, consent per bank, and call endpoints like /accounts and /accounts/{id}/transactions. The regulated provider handles the bank integrations, the eIDAS certificates, and the consent renewal. You get clean, audited, read-only data without the regulatory burden.

Disclosure: I maintain open-banking.io, a roughly €3/month service that does exactly this — read-only bank-account aggregation with no PSD2/eIDAS certificates required and client-held encryption keys. I'm mentioning it because it's directly relevant, not because this is a sales pitch. The methods above stand on their own merits.

Best for: Tech-savvy owners, accountants serving multiple clients, finance teams, and anyone who'd rather build a pipeline than paste CSVs.

Comparison at a glance

Method	Read-only?	Automated?	Banks unified?	Setup effort	Cost
Bank sub-user (viewer role)	Yes (role-based)	No — manual export	No (one per bank)	Low, but repetitive	Free
Accounting software feeds	Yes (Open Banking)	Yes — daily auto-import	Yes, within the app	Low	£20–40/mo
Open Banking / AIS API	Yes (by regulation)	Yes — fully programmable	Yes — all banks via one API	Medium (developer-oriented)	~€3/mo+

Security checklist before you grant anything

Whichever route you take, run through this:

Confirm it's AIS, not PIS. Account Information only — never payment initiation. The consent screen will state this explicitly.
Check consent expiry. Open Banking consents renew roughly every 90 days. Re-authenticate before they lapse or your accountant's feed goes dark.
Prefer end-to-end encryption if the option exists — your transaction data is sensitive.
Rotate access when you switch accountants. Remove the software seat or revoke the API consent the same day.
Don't share your bank login. Ever. If a method requires it, it's the wrong method.

Summary

You have three solid ways to give your accountant read-only access to your bank account:

Add them as a read-only sub-user — simplest, but manual and bank-by-bank.
Use accounting software bank feeds — automatic and auto-categorised, ideal if you're already on Xero or QuickBooks.
Use an Open Banking / Account Information API — programmable, unified across banks, and (with the right provider) needs no PSD2/eIDAS certificates of your own.

For most businesses, Method 2 is the pragmatic default. Method 3 is the future, and it's more accessible than the regulator-jargon makes it sound. Whatever you pick, the principle is the same: your accountant gets the numbers, and you keep the keys.

If this was useful, I write about Open Banking, PSD2, and practical fintech for small businesses — questions welcome in the comments.