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.
Top comments (0)