What is PSD2, and what changes with PSD3?

What PSD2 actually forced

Two things, and they are often confused.

Access. A licensed third party can, with your consent, read your account information or start a payment from your account. Your bank cannot refuse on the grounds that it would rather you used its own app. This is the legal foundation of European open banking. It did not create a business model. It created a right.

Authentication. Most electronic payments require strong customer authentication: two independent factors from the categories of something you know, something you have, and something you are. This is why the extra step appeared at European checkouts, and it is enforced in card payments through 3D Secure.

There are exemptions, and the exemptions are where the commercial fight happens. Low-value transactions, recurring payments of a fixed amount, trusted merchants and transaction risk analysis can all avoid the extra step. A payments team's authentication strategy is largely a strategy about which exemptions it can defend.

The things PSD2 did badly

The access rules were a directive, which means each member state wrote its own version. The result was a single market with twenty-seven interpretations, and open banking APIs whose quality ranged from excellent to functionally hostile.

Authorised push payment fraud, where a person is tricked into sending money themselves, sat almost entirely outside the framework. The rules were built around unauthorised transactions. If you authorised it, you generally wore it, however you were deceived.

And the e-money and payment institution regimes were separate, which meant broadly similar businesses were licensed under different rulebooks.

What PSD3 and the PSR change

The package splits in two. PSD3 is a directive covering authorisation and supervision, and it consolidates the payment institution and e-money institution regimes into one licence. The PSR is a regulation covering conduct: strong customer authentication, fraud, refunds, open banking API performance, and payee verification. Being a regulation, it applies directly, without twenty-seven local translations.

The substantive shifts worth planning for:

A payee name check. The account name must be verified against the account identifier, with liability attached when it is not. This is the single biggest operational change for anyone holding accounts.

Fraud liability that extends further, including in defined cases to parties outside the traditional payment chain.

Enforceable open banking performance, so an API that technically exists but practically fails stops being compliant.

The texts reached political agreement in late 2025, with the final compromise texts published in April 2026 and publication in the Official Journal expected across mid-2026. Application follows roughly twenty-one months after publication, which puts real obligations in the second half of 2027 and beyond, with the payee verification duty later still.

PSD2 was a landlord told to give tenants a key to the shared garden. Some landlords cut a good key, some cut one that jammed, and the rule did not say how smoothly the key had to turn. PSD3 is the same instruction rewritten to specify the key, the lock, and what happens to the landlord when the gate sticks.

What to do about it now

Nothing about the timeline invites panic, but two workstreams have long lead times. Payee verification requires a name-matching capability and a decision about what you do with a near match, which is a product question as much as a compliance one. And if you hold both a payment institution and an e-money licence, the consolidated regime is a chance to simplify rather than a box to tick.

Where you meet it

Every European checkout that bounces you into your banking app. Every budgeting tool that reads your balance. Every "we could not verify the payee name" warning your bank has started showing you.