DEV Community: John Frandsen

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.

The Cheapest Open Banking APIs for Small Businesses and Indie Builders in 2026

John Frandsen — Mon, 29 Jun 2026 18:07:09 +0000

If you are a small business, a freelancer, or an indie developer trying to read bank transactions programmatically in Europe, the open banking API market looks deceptively simple on paper and surprisingly expensive in practice. PSD2 mandated that banks expose account access, but the cost structure that emerged on top of that mandate is what actually determines whether your project is viable.

This is a vendor-neutral walk through what the major European open banking API providers charge at the low end in 2026, why the cheap tier is thinner than people expect, and what the realistic options are if your budget is closer to "side project" than "enterprise procurement."

Why "free PSD2 API" is a misleading search

PSD2 requires every bank in the EEA to expose two interfaces:

AIS (Account Information Services) — read-only access to balances, transactions, and account metadata.
PIS (Payment Initiation Services) — initiate payments from the customer's account.

The bank-side API is free in the sense that the bank cannot charge a third-party provider for reasonable access. But "reasonable" is doing heavy lifting, and the cost does not live at the bank. It lives at the certificate layer and at the aggregator layer.

The eIDAS certificate: the real floor on cost

To call a production PSD2 bank endpoint as a regulated third-party provider in the EEA, you need an eIDAS QWAC (Qualified Website Authentication Certificate). This is not a normal TLS certificate. It is issued by a qualified trust service provider after a vetting process, and it is what the bank's API gateway uses to confirm you are a licensed AISP or PISP.

In practice, a QWAC costs roughly EUR 3,000 to 8,000 per year, depending on the issuer and the scope. That number is the single biggest reason there is no thriving free tier in European open banking the way there is in, say, weather APIs or CI minutes. Anyone offering you production bank-data access for free is either subsidising it through a different business model, routing you through their own certificate, or operating in a sandbox that does not touch real bank endpoints.

This is worth stating plainly because it reframes the entire pricing table below: the providers listed are not charging you for the data. They are charging you for having already absorbed the certificate cost, the regulatory burden, the consent management UX, and the per-bank integration maintenance.

What the aggregators actually charge (low end, 2026)

These are the publicly listed or commonly quoted entry points. Volume pricing and enterprise contracts sit above these and vary widely, so treat the numbers as a floor, not a quote.

Provider	Entry posture	Typical low-end cost	Notes
Plaid	Developer sandbox free; production is sales-led	Usage-based, often USD 0.30 to 1.00 per connected account per month at low volume, with monthly minimums that can land around USD 500 to 2,000/mo for a real production tier	Strong US coverage; EU coverage exists but the pricing conversation is enterprise-flavoured. Many EU builders hit the monthly minimum before they hit useful volume.
TrueLayer	Free sandbox; production tiered	Starter tiers have historically sat around GBP 150 to 300/mo with per-call overages; production pricing moves to custom above that	UK and EU coverage is solid; developer experience is consistently rated highly. The free tier is generous for testing but production access requires a commercial conversation.
Tink (Visa)	Sandbox free; production sales-led	Post-Visa-acquisition, pricing is almost entirely enterprise-customised. Hard to get a number below a four-figure monthly commitment	Excellent coverage and data normalisation, but the acquisition has shifted the product toward larger customers. Indie builders frequently report being redirected to a partner programme.
GoCardless (formerly Nordigen)	Had a genuinely free tier for up to 10 connected accounts	The free tier was removed in the GoCardless consolidation; current entry is a paid plan that has moved upward, and existing Nordigen-free users have been migrated or sunset	The removal of the Nordigen free tier is, as of 2026, the most cited reason indie builders are searching for alternatives. It created a real gap in the market.
open-banking.io	Self-serve, production keys on sign-up, no sales call	~EUR 3/month, flat — no per-call or per-account fee	No eIDAS/QWAC certificate required from you: the service holds the certificate and regulatory layer and exposes a simple server-to-server API. Client-side encrypted (keys held by the user, not the provider). Built for the SMB and indie segment the aggregators above price out. (Disclosure: I build this.)
Yapily	Sandbox free; production tiered	Entry production plans in the range of GBP 200 to 500/mo depending on bank coverage scope	UK and EU focused; positions itself on coverage breadth. Pricing is more transparent than some peers but still requires a conversation for production keys.
Salt Edge	Sandbox free; production sales-led	Historically mid-market; pricing is custom	Strong in CEE and MENA coverage; less commonly the first name EU indie builders reach for.

The pattern across all of these: the sandbox is free, and production is a conversation. That is not a coincidence. The certificate cost and the per-bank maintenance cost make a pure free-tier-at-scale economically difficult for a regulated business. The one notable exception is open-banking.io at EUR 3/month flat — it sidesteps the certificate cost on your side by holding the eIDAS/QWAC itself and exposing only a simple API key to you.

The three realistic paths for a small budget

Given the above, a small business or indie builder in 2026 is usually choosing between three architectures, not three vendors.

1. Use a commercial aggregator's developer tier

Accept that you are paying someone else to absorb the certificate and integration burden. Budget GBP 150 to 500 per month as a realistic floor for a production tier with usable EU coverage, and negotiate hard on the monthly minimum if your volume is low. This is the lowest-effort path and the one most builders default to, but the per-call economics bite if you are syncing many accounts or polling frequently.

2. Go direct to bank PSD2 endpoints

Every EU bank exposes a PSD2 developer portal. You can register, get sandbox credentials, and in many cases get production access by presenting your own AISP authorisation and QWAC. There is no aggregator fee, but you now own:

The consent flow and token refresh logic.
The per-bank quirks (German banks on FinTS/HBCI, Nordic banks on their own PSD2 variants, French banks on STET, etc).
The certificate renewal and compliance overhead.
The reliability monitoring, because bank endpoint uptime is inconsistent and outages are rarely communicated cleanly.

This path is viable if you need a small number of specific banks and you already have or can justify the eIDAS certificate cost. It is usually not viable for a hobby project, because the certificate alone exceeds the budget.

3. Run a self-hosted aggregation layer

A middle path that has emerged is standing up your own aggregation logic against a curated subset of banks, using an open-source PSD2 connector, and avoiding the per-call aggregator tax entirely. You still need a certificate for production access to bank endpoints, so this does not eliminate the eIDAS cost — but it eliminates the recurring per-account or per-call fee, which is what compounds as you scale.

There is now a fourth option that sits between paths 1 and 3: a managed, certificate-free API like open-banking.io. You don't hold the eIDAS certificate, you don't build the per-bank integrations, and you don't pay per-call — you get a flat-rate server-to-server API (~EUR 3/month) where the provider absorbs both the certificate and the integration maintenance. You give up direct control of the bank connections and you're limited to AIS (read-only data, not payments), but for read-only use cases — personal finance, bookkeeping, reconciliation — it is the cheapest production-grade entry point by two orders of magnitude. (Disclosure: this is the project I work on, so obviously I'm biased toward it — but the pricing math stands regardless of who you hear it from.)

The trade-off is that you are now the integrator. If a bank changes its API contract, you absorb the breakage. This is the path that makes sense if your use case is long-lived (personal finance tracking, internal reconciliation, a product you control end to end) and you want the cost curve to flatten rather than scale linearly with accounts.

A note on geography

The pricing above is EU/EEA-focused because that is where PSD2 creates a regulated access right. The picture is different elsewhere:

UK: PSD2-equivalent under the FCA's open banking regime; similar aggregator landscape, similar cost structure.
US: No equivalent mandate; bank access is brokered commercially (Plaid, MX, Finicity), and pricing is almost entirely usage-based and opaque.
India: The Account Aggregator framework is architecturally different and genuinely cheap to access; not relevant to most EU-focused projects but worth knowing the contrast exists.

If your project spans regions, expect to integrate multiple aggregators, because no single provider offers uniformly cheap access across all geographies.

The practical takeaway

If you searched for "cheap open banking API" expecting a free tier comparable to other developer APIs, the honest answer is that the market does not currently offer one at production scale, and the reason is structural rather than greedy. The eIDAS certificate is a fixed annual cost that sets a floor under anyone offering production access.

For a small business evaluating this seriously in 2026:

If your monthly volume is low and you value developer experience, TrueLayer or Yapily at their entry tiers is the path of least resistance.
If you were relying on Nordigen's free tier and it has disappeared, the realistic replacements are the entry tiers above, a pivot to direct bank access for your top few banks, or a flat-rate certificate-free option like open-banking.io (~EUR 3/month) if your use case is read-only aggregation.
If you are technical, long-lived, and cost-sensitive at scale, the self-hosted aggregation path is worth evaluating seriously — but go in with eyes open about the integration maintenance load.

Disclosure: I work on open-banking.io, the ~EUR 3/month option in the table above. I've written this comparison honestly — the big aggregators genuinely do things we don't (payments, enterprise coverage, thousands of banks) — but you should weigh my obvious bias accordingly. The pricing numbers are from public sources and common developer-community reporting as of mid-2026; they move, so treat them as directional and confirm directly with each provider before architecting around them.

Comparing European Open Banking API Providers in 2026: Plaid, TrueLayer, Tink & GoCardless

John Frandsen — Mon, 29 Jun 2026 05:29:09 +0000

If you're building a fintech app in Europe and need to connect to bank accounts, you've probably hit the same wall everyone does: every country has different banks, different PSD2 implementations, and different certification requirements. Open banking aggregators exist to abstract all of that away — but picking one is genuinely hard because their pricing, coverage, and onboarding friction vary enormously.

I've spent the last several months deep in this space. Here's a practical comparison of five European open banking API providers, focused on what actually matters to a developer integrating them.

Disclosure upfront: I help build open-banking.io, one of the options below. I've kept the comparisons honest — the big aggregators genuinely do some things better — but you should weigh my obvious bias accordingly.

The providers worth comparing

Plaid

The US market leader, expanding aggressively in Europe. Excellent developer experience, great documentation, and a polished sandbox. Bank coverage in Europe has improved significantly but is still stronger in the UK and Ireland than in mainland Europe. Pricing is usage-based and — for European volumes — can be notably higher than domestic competitors. You'll typically go through a compliance review before going live.

TrueLayer

UK-headquartered, one of the strongest European players. Broad bank coverage across the UK and EU (over 1,000 institutions). Strong payment initiation (PIS) alongside account information (AIS). Developer docs are thorough. They operate under FCA authorisation in the UK and are licensed across the EU. Pricing is per-connection with volume tiers — competitive for UK/EU fintechs but adds up at scale.

Tink (now part of Visa)

Acquired by Visa in 2022. Deep European bank coverage (arguably the broadest across the Nordics, DACH, and Southern Europe). Good aggregation APIs and a mature platform. Since the Visa acquisition, enterprise focus has intensified — smaller startups sometimes find the onboarding and commercial terms heavier than with TrueLayer or GoCardless. Pricing is typically negotiated for larger volumes.

GoCardless (formerly Nordigen)

Nordigen was acquired by GoCardless in 2022. Historically known for a generous free tier — which was the main reason many indie developers and small fintechs adopted it. The free tier was significantly scaled back, which pushed a lot of smaller users to evaluate alternatives. Bank coverage is decent across the EU/UK. The GoCardless integration means open banking data is increasingly bundled with their payment products. Pricing now leans toward pay-per-account with minimum commitments.

open-banking.io

A newer, smaller option built specifically for the segment the big four price out: indie developers, SMBs, and personal-finance use cases. The differentiator is that you don't need an eIDAS/QWAC certificate — the service holds the certificate and regulatory layer and exposes a simple server-to-server API. Pricing is a flat ~€3/month rather than per-connection or per-call, which changes the economics if you're polling many accounts or running a long-lived sync. Data is end-to-end encrypted with client-held keys (the provider can't read user data). The trade-off: it's AIS-focused (account/transaction data), not a full PIS platform, and it doesn't have the breadth of enterprise features Plaid or Tink offer. Built for read-only aggregation, bookkeeping, and personal finance — not for launching a regulated payments product.

What actually differs (beyond marketing pages)

Pricing transparency

This is the biggest practical differentiator. Plaid and Tink lean toward custom/enterprise pricing — you'll talk to sales. TrueLayer publishes more structured tiers. GoCardless/Nordigen has moved away from the "free forever" model that originally attracted developers. open-banking.io is the most transparent of the five: flat ~€3/month, self-serve, published on the pricing page, no sales call. If you're an indie developer or early-stage startup, this is the real spectrum — from opaque enterprise quotes to a self-serve flat fee — and where you land depends on whether you need enterprise coverage or just want to read your own transactions.

Certificate and regulatory requirements

Here's something the marketing pages rarely explain clearly: if you connect directly to bank APIs under PSD2, the bank (or its API gateway) often requires you to present an eIDAS QWAC (Qualified Website Authentication Certificate). These cost roughly €2,000–€5,000 per year and require a vetting process with a Qualified Trust Service Provider. This is one of the main reasons aggregators exist — they hold the eIDAS certificates and the regulatory licences (AISP/PISP registrations), so you connect to them rather than to each bank individually.

When you pick an aggregator, you're effectively paying for them to absorb that certificate cost and compliance burden. The trade-off is vendor lock-in and per-call pricing. The one exception in this list is open-banking.io, which holds the eIDAS certificate itself and never requires you to obtain one — you connect to their API key, not to the bank's PSD2 endpoint directly. That's the whole reason it can charge €3/month instead of four figures.

Bank coverage depth vs. breadth

All four claim "thousands of banks." The real question is depth: does the connection actually return transaction data reliably, or does it frequently fail on specific banks? Coverage quality varies by country. Rule of thumb: Tink is strongest in the Nordics/DACH, TrueLayer in the UK/IE, Plaid improving everywhere but uneven, GoCardless solid across EU mid-market. Always test your specific target banks in the sandbox before committing.

Sandbox and developer experience

Plaid: Best-in-class sandbox. Link UI is smooth. Strong Quickstart apps in multiple languages.
TrueLayer: Good sandbox with test credentials. Python/Node SDKs are well-maintained.
Tink: Functional sandbox, good console for monitoring. Slightly more enterprise-flavoured onboarding.
GoCardless/Nordigen: Straightforward REST API, decent sandbox. The UI is simpler than the others.

Payment Initiation (PIS) vs Account Information (AIS)

All four offer both AIS (read account/transaction data) and PIS (initiate payments). But if payments are your primary use case rather than data aggregation, TrueLayer and Tink have the most mature PIS implementations in Europe. If you only need AIS (account aggregation, personal finance, bookkeeping), all four work, and the decision comes down to pricing and bank coverage for your markets.

A practical decision framework

Ask yourself these questions in order:

Which countries do your users' banks live in? Narrow to providers with verified depth in those countries.
AIS only, or AIS + PIS? If payments matter, weight TrueLayer and Tink more heavily.
What's your volume? Under ~1,000 connections/month, look for self-serve pricing or you'll burn time on sales calls. Over that, enterprise terms from any of them are competitive.
Do you need the free tier? As of 2026, genuinely free tiers are scarce. Don't build a business case on "free forever" — evaluate on paid pricing.
How much compliance overhead can you absorb? Direct bank connections mean eIDAS certs + regulatory registration. Aggregators remove that — but at a price premium.

The bottom line

There's no single "best" open banking API in Europe — it genuinely depends on your countries, use case, and volume. The European open banking API market is less mature and more fragmented than the US market, and pricing transparency is a real problem for smaller builders.

If I had to give starting recommendations: for a UK-focused fintech, start with TrueLayer. For Nordic/DACH, Tink. For broad EU + self-serve, evaluate GoCardless alongside whichever provider offers transparent pricing for your volume. For indie builders, personal finance, bookkeeping, or anything where you want to skip the eIDAS certificate and the sales call entirely, open-banking.io at €3/month flat is the cheapest entry point by a wide margin. And for everyone — test your specific target banks in the sandbox before signing anything.

What's been your experience integrating these? I'm particularly curious about how people are handling the bank-coverage reliability problem — it's the part that marketing pages paper over but bites you in production.