DEV Community

John Frandsen
John Frandsen

Posted on

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

#banking #webdev #fintech #openbanking

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

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

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

Why developers look for a Plaid alternative in Europe

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

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

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

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

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

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

In practice, this means:

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

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

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

The main Plaid alternatives in Europe: compared

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

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

A note on each

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

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

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

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

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

The flow every European open banking API shares

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

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

Let's see that in code.

Code examples

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

1. Initialize a bank session (consent) 

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

Response (abbreviated):

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

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

2. List accounts 

import os, requests

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

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

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

3. Fetch balances and transactions 

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

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

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

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

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

4. A complete Python helper

Here's a small reusable client you can adapt:

import os, requests
from datetime import datetime, timedelta

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

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

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

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

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

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

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

How to choose: a decision guide

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

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

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

Pitfalls to avoid when switching from Plaid

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

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

Official references

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

Summary

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

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

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

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

Top comments (0)