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

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

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.