PSD2 — The EU Directive That Forced Banks to Open Their APIs

In 2015 the EU passed a directive that did something banks had been resisting for decades: it legally required them to give third-party software controlled access to their customers' accounts. That directive is PSD2 — the Revised Payment Services Directive (Directive (EU) 2015/2366). It came into full legal effect in January 2018, and the technical enforcement deadline landed in September 2019.

This post covers what PSD2 actually does from a technical perspective — the roles it defines, the authentication rules it mandates, the API standards that emerged from it, and what comes next. The follow-up post covers how to actually use it in practice.

What Problem PSD2 Solves

Before PSD2, if you wanted to build a budgeting app that read someone's bank transactions, you had two options:

1. Screen scraping — ask the user for their internet banking credentials, log in as them, and parse the HTML. Used by most fintech apps at the time. Technically against most banks' terms of service, legally grey, and security-wise: terrible.
2. Bilateral agreements — negotiate a data-sharing deal with each bank individually. Expensive, slow, and only available to large companies.

PSD2 replaced this with a regulated API framework. Banks must provide machine-readable access to account data. Third parties get a defined legal role. The user remains in control of what they share and with whom.

The Three Roles

PSD2 defines three types of entity in the payment ecosystem:

ASPSP — Account Servicing Payment Service Provider

The bank (or other account holder). ASPSPs are required to expose a dedicated API interface — they cannot force third parties to use their consumer-facing web portal. They must maintain the API with the same uptime as their retail channel.

Examples: Deutsche Bank, ING, Revolut, N26, Starling.

AISP — Account Information Service Provider

A third party licensed to read account data. An AISP can access balances, transaction history, and account details — but cannot move money. Requires explicit user consent and an AISP licence from a national financial regulator.

Examples: budgeting apps (Copilot, Emma), accounting integrations (Xero, FreeAgent), credit scoring tools.

PISP — Payment Initiation Service Provider

A third party licensed to initiate payment transfers on behalf of a user — without ever seeing or holding the funds. The user authenticates directly with their bank, and the bank executes the transfer. Requires a PISP licence.

Examples: payment processors using bank-to-bank transfer instead of card rails, B2B payment tools, rent collection platforms.

A provider can hold both AISP and PISP licences simultaneously.

Strong Customer Authentication (SCA)

SCA is PSD2's security requirement for authenticating users. It mandates two of the following three factors:

Where SCA applies

• Accessing account data for the first time (and every 90 days for ongoing access — the "90-day rule")
• Any electronic payment over €30 (with exemptions for low-risk/trusted payees)
• Adding a new payee or changing account settings

Exemptions

Not every transaction needs full SCA. Recognised exemptions include:

• Low-value transactions — under €30 (up to a cumulative €100 limit)
• Trusted beneficiaries — payees whitelisted by the user
• Recurring payments — fixed-amount subscriptions where SCA was applied for the first one
• Corporate payments — B2B transactions where the payer is not a consumer
• Low-risk transactions — real-time fraud scoring below thresholds set by the EBA

The 90-day re-authentication rule for AISP access was controversial — it meant users of bank data aggregators had to re-confirm with each bank every 90 days. In 2021 the UK's FCA softened this: AISPs can now ask users to reconfirm consent directly with them rather than requiring a full bank re-authentication each time.

eIDAS Certificates

PSD2 requires that communication between third parties and banks use qualified electronic certificates as defined by the EU's eIDAS regulation. Two certificate types are relevant:

QWAC — Qualified Website Authentication Certificate

Used to establish the TLS connection. Essentially a TLS client certificate that includes the provider's PSD2 role (AISP, PISP, or both) and their national authorisation number. Banks verify this certificate before granting API access.

QSeal — Qualified Electronic Seal

Used to sign the HTTP request bodies. Proves the request was not tampered with in transit.

QWACs and QSeals must be issued by a Qualified Trust Service Provider (QTSP) — a list maintained by each EU member state's national authority. They expire (typically annually) and must be renewed.

Getting eIDAS certificates requires being a licensed payment institution. If you want to build on PSD2 without that regulatory overhead, you use a licensed intermediary (the providers covered in the follow-up post).

The RTS — Regulatory Technical Standards

The nitty-gritty of how PSD2 is implemented technically is defined in Commission Delegated Regulation (EU) 2018/389 — known informally as the RTS on SCA and CSC (Common and Secure Communication).

Key rules from the RTS:

• ASPSPs must offer a dedicated API interface (a fallback via the consumer portal is permitted but strongly discouraged)
• The API must be freely accessible for testing — from 14 March 2019, banks were required to have sandbox environments live
• APIs must match the availability and performance of the consumer-facing channel
• All communication must use TLS 1.2 or higher
• ASPSPs cannot require TPPs (third-party providers) to register with them individually beyond presenting their eIDAS certificate and consulting the national regulator directory

The RTS deliberately avoids specifying a single API standard — which is why fragmentation followed.

API Standards: The Fragmentation Problem

Because the RTS doesn't mandate a specific API format, each bank technically could design their own. Most of the SEPA zone converged on a small number of industry standards, but the landscape is still fractured:

NextGenPSD2 (The Berlin Group)

The dominant standard in continental Europe. Defined and maintained by The Berlin Group, a pan-European payments interoperability consortium. Covers:

• Account information (balances, transactions, details)
• Payment initiation (SCT, SCT Inst, SDD)
• Consent management

The Berlin Group's NextGenPSD2 spec has strong adoption in Germany, Austria, the Netherlands, and many other EU markets.

STET (France)

Developed by the French clearing house STET. Broadly aligned with NextGenPSD2 as part of a convergence effort, but with French-specific quirks. Used by French banks.

Open Banking UK

A separate, UK-specific standard built by Open Banking Limited (a non-profit mandated by the Competition and Markets Authority). More tightly specified than Berlin Group — which makes it more consistent across UK banks, but slightly different from the EU standards. Following Brexit, UK open banking is no longer PSD2-governed but continues under CMA oversight.

Slovak Banking API, PolishAPI, and others

National variants. Poland, Slovakia, and others built their own standards rather than adopting Berlin Group wholesale. This is one of the key friction points in the ecosystem — your API client for a German bank will not work unmodified with a Polish one.

The Consent Model

All PSD2 data access requires explicit user consent linked to a specific scope and time period. The consent lifecycle:

1. TPP creates a consent object — specifying which accounts, which data (details/balances/transactions), and for how long
2. User is redirected to their bank for authentication and approval (the "OAuth-like redirect flow")
3. Bank issues an authorisation — the TPP receives an access token or similar credential
4. Access window begins — the TPP can read data for the agreed period (max 90 days without re-auth)
5. User can revoke at any time via their bank's portal

This is conceptually similar to OAuth 2.0 but is not quite standard OAuth — each bank's implementation varies, which is part of why aggregator middleware exists.

Payment Initiation Flow (PISP)

A PISP payment doesn't move money through the PISP's own accounts. The flow is:

User → chooses to pay via bank transfer in merchant's checkout
  ↓
PISP → creates a payment initiation request with the user's bank
  ↓
User → redirected to their bank, authenticates with SCA, confirms payment
  ↓
Bank → executes the SEPA Credit Transfer
  ↓
PISP → receives confirmation, notifies merchant
  ↓
Merchant → fulfils order

The funds go directly from the user's account to the merchant's account. The PISP never touches the money — they just initiate and confirm. This is why bank-to-bank payment is structurally cheaper than card: no card network fees, no acquiring bank margin.

What PSD3 Changes

The European Commission proposed PSD3 in 2023, with implementation likely in the late 2020s. Key changes:

• Financial Data Access (FIDA) — extends the open banking model beyond payment accounts to include savings, investments, insurance, and pension data
• Better API standards — push toward mandating consistent interfaces rather than leaving it to industry bodies
• Improved SCA — rationalisation of exemptions and stronger fraud liability rules
• Open Finance — the successor concept, extending data sharing across the entire financial sector, not just payment accounts

PSD3 is expected to substantially reduce the fragmentation problem that makes building pan-European open banking integrations annoying today.

The Licensing Reality

To connect directly to bank APIs under PSD2 you need:

1. AISP and/or PISP licence from your national financial regulator (FCA in the UK, BaFin in Germany, DNB in the Netherlands, etc.)
2. eIDAS QWAC and QSeal certificates from a QTSP
3. Registration in the EBA Register (or equivalent national register)
4. The ability to implement the API standard for each bank you want to connect to

The licence process typically takes 3–12 months and requires demonstrating capital adequacy, governance, security controls, and business continuity planning.

For most developers and companies, this is not feasible — which is why the aggregator middleware market exists. That's what the follow-up post covers.