PSD2 forced banks to grant third parties access to accounts and made strong authentication the default. PSD3 and a new Regulation tighten the screws, close the loopholes, and move the hard rules into directly-applicable law.
The second Payment Services Directive (PSD2, Directive (EU) 2015/2366) is the law that reshaped European retail payments. It did two big things. First, it mandated strong customer authentication (SCA) — two of three independent factors (something you know, have, are) for most electronic payments, with dynamic linking tying the authentication to a specific amount and payee. Second, it created regulated third-party access: banks must let licensed AISPs (account information) and PISPs (payment initiation) reach customer accounts, with the customer’s consent, through dedicated interfaces.
That second piece is what the market calls open banking. PSD2 is the legal engine underneath it. The headline failure of PSD2 was execution: fragmented APIs, inconsistent national supervision, friction-heavy SCA exemptions, and a fraud picture that kept shifting (authorised push payment fraud, in particular, fell outside the original frame).
PSD2 is a directive: it sets objectives that each of the 27 member states transposes into national law. That transposition is where the fragmentation crept in. The reform splits the regime into two instruments deliberately.
| Instrument | Type | What it carries |
|---|---|---|
| PSD3 | Directive (transposed nationally) | Licensing and authorisation of payment & e-money institutions, supervision, access to payment systems and accounts |
| PSR | Regulation (directly applicable) | Conduct rules: SCA, fraud liability, open-banking interfaces, transparency, the hard requirements that apply uniformly EU-wide |
Putting the conduct rules in a regulation means they apply identically in every member state the day they take effect — no transposition gap, less room for national divergence. That is the single most important structural change.
IBAN/name mismatch checks (aligning with Verification of Payee), liability where a fraudster impersonates a bank (“spoofing”), and a sharper allocation of who eats the loss.
Removes the much-hated “fallback interface” obligation in favour of clearer performance standards for dedicated APIs, with permission dashboards so users can see and revoke data access.
Clearer exemptions, accommodation for users who cannot easily use a smartphone, and explicit room for the EUDI wallet as an authentication means.
Non-bank PSPs get more direct access to payment systems and to safeguarding accounts at central banks, narrowing the bank advantage.
The trilogue concluded with a provisional political agreement on 27 November 2025. The Council published final compromise texts on 23 April 2026 and COREPER endorsed them on 22 April 2026; the Parliament’s ECON committee and plenary are completing their votes through May 2026. After legal-linguistic review, publication in the Official Journal is anticipated around June–July 2026 (possibly slipping to September), with the rules generally applying roughly 21 months after publication — so practical application lands in 2028.
Until PSD3/PSR apply, PSD2 governs. Do not switch off PSD2 compliance programmes; you are running both in parallel for the next two years.
The Financial Data Access (FiDA) Regulation — open finance beyond payments — was proposed alongside PSD3 but is on a different, slower track. Do not conflate the two.
If you run a bank or PSP: the expensive work is not new features — it is the move from directive to regulation. Divergent national interpretations you relied on will disappear. Audit every SCA exemption and every open-banking interface against the PSR text now, because there will be no transposition window to hide in.
If you are a fintech or TPP: PSD3/PSR is broadly good news — better API performance standards, permission dashboards, fairer system access. But the fraud-liability rebalancing cuts both ways; model your exposure under the new spoofing and IBAN-mismatch rules before you price.
Cost of being wrong: treating this as a 2028 problem. The 21-month clock starts at OJ publication, and authentication, API, and liability changes are multi-quarter engineering programmes. The firms that wait until the text is final will be the ones explaining a missed deadline to a regulator.