PSD2 to PSD3: what’s changing and what to do about it

The third Payment Services Directive and its sister regulation, the PSR, won’t apply until 2027 or 2028, but the work they demand has already started. Payee verification is live for instant euro transfers. Fraud liability is moving onto providers. The contracts that decide who pays when authentication fails need rewriting now.

This is a practical guide to the changes from PSD2 to PSD3, who they affect, and what to do before the clock runs out.

What is PSD3?

The reform comprises two instruments: PSD3, a directive covering licensing and supervision, and the Payment Services Regulation (PSR), a directly applicable regulation that sets out the day-to-day conduct rules. Together they govern how payment service providers (PSPs) authenticate users, handle fraud, share data, and connect to open banking.

The European Commission proposed⁠ both texts on 28 June 2023. The reason was straightforward: PSD2 didn’t fully deliver. The Commission’s own review found⁠ open banking working imperfectly, persistent fraud, and a stubborn preference for cash.

The sharpest gap was fraud. PSD2’s liability rules were built around unauthorised transactions and handled authorised push payment (APP) fraud poorly — the scams where a victim is tricked into authorising a payment themselves. Meanwhile, e-money institutions sat under a separate directive, creating duplication and divergence.

PSD3 and the PSR are the response: one harmonised rulebook, tighter fraud rules, and a single licence for payment and e-money firms.

PSD2 vs PSD3: one directive becomes two instruments

PSD2 was a single directive. Every EU member state transposed it into national law, and they did so differently — producing the divergence and forum shopping that fragmented the single market. PSD3 ends that by splitting the rulebook in two.

PSD3, the directive, retains the functions that genuinely require national administration: authorisation, governance, capital, safeguarding, and supervision of payment institutions. The PSR takes everything that touches day-to-day conduct — customer information, transaction execution, strong customer authentication, fraud liability, and open banking access. Because the PSR is a regulation, it applies directly and uniformly across all member states with no national transposition.

The practical read: PSD3 is mostly a licensing story. The PSR is where your product, fraud, and checkout logic live. When people say ‘PSD3,’ they usually mean the whole package, but the rules that change how you operate sit in the PSR.

PSD3 changes that hit payment operations

If you run payments, four changes deserve your attention.

Fraud liability moves toward providers

Under the new regime, a PSP that fails to implement adequate fraud-prevention mechanisms may be liable for the customer’s loss. The most-discussed case is impersonation fraud. The final agreement kept the basic rule that a payer who authorises a fraudulent payment bears the loss — with one key exception: where a fraudster impersonates the PSP itself, and the victim promptly reports it to the PSP and police, the PSP must reimburse. The direction is unmistakable: fraud is becoming a balance-sheet risk, not just a customer-service one.

Verification of Payee becomes standard

This is where most coverage gets it wrong. The IBAN/name check (Verification of Payee) is not a future PSD3 invention. Euro-area PSPs have had to offer it since 9 October 2025 under the separate Instant Payments Regulation. What the PSR does is generalise the requirement across credit transfers and attach liability: if a PSP fails to flag a mismatch and the payer loses money, the PSP bears it. If you’re building payment flows today, treat VoP as present-tense, not a 2027 line item.

SCA gets more flexible — and more accountable

Strong customer authentication stays, still requiring two of three independent factors. Three shifts matter. First, accessibility becomes a legal right: PSPs must offer⁠ at least one SCA method for customers without smartphones or with disabilities. Second, delegated authentication is explicitly allowed — an acquirer, gateway, or wallet can perform SCA on the issuer’s behalf — but liability follows the party that performs it.

Schemes, technical service providers, and gateways become liable for fraud if they fail to apply SCA. Third, mail-order/telephone-order and certain merchant-initiated transactions get clearer exemptions.

You can block suspicious payments

The PSR gives PSPs the explicit right to block a payment where there is strong evidence of fraud. That’s a meaningful change for real-time risk management.

The common thread: every one of these reassigns responsibility across the chain of parties that touch a transaction. If your authentication, routing, or fraud logic spans multiple providers, the question ‘who’s liable when this fails?’ now has a sharper answer, and you need contracts and monitoring that reflect it.

What changes if you run a PSP or e-money business

For payment entrepreneurs and PSP or EMI operators, the licensing changes are the headline.

One licence, not two

PSD3 merges the payment-institution and e-money-institution regimes. EMD2 is repealed, and EMIs become a sub-category of payment institution. Existing licences are grandfathered for a defined period, but firms must re-authorise under the new framework and update their authorisation files. Initial capital is scaled to the risk and services provided, a departure from PSD2’s flatter thresholds.

A faster route for crypto firms

Crypto-asset service providers already authorised under MiCA get a streamlined path to payment-services authorisation, since the regulator has already vetted their governance, AML, and capital. The logic is to avoid duplicating checks MiCA already covers.

Open banking with real enforcement

PSD2 introduced open banking but left banks with wide latitude over how they exposed their interfaces, and in practice many third-party providers met inconsistent performance and friction. The PSR tightens that. Banks must run at least one dedicated data-access interface that performs at least as well as their own app; the old fallback model gives way to a structured contingency mechanism; and screen-scraping is prohibited. National regulators are expected to act ‘without delay’ against interfaces that miss performance standards. Account information service providers also gain passporting rights. If you build on bank APIs, the reliability floor rises.

PSD3 timeline: when this actually lands

PSD3 is close, but not yet law. Here’s where it stands.

The package was politically agreed on 27 November 2025. The final compromise texts were published on 23 April 2026, and the Parliament’s ECON committee approved⁠ them on 5 May 2026. What remains is the final plenary vote, formal Council adoption, legal-linguistic review, and publication in the EU Official Journal — expected around mid-2026, though it could slip to September.

Once published, the PSR enters into force 20 days later, and most rules apply after roughly a 21-month transition, putting real application in 2027 or 2028. One carve-out: the payee name/IBAN verification provisions apply about six months after the rest. PSD3, as a directive, runs on a similar transposition clock.

Worth tracking alongside PSD3: the Financial Data Access (FIDA) regulation, proposed in the same package, which would extend open-banking-style access to investments, pensions, and insurance. It’s still in trilogue and won’t be operational until the end of the decade. PSD3 doesn’t wait for it.

A PSD3 readiness roadmap for payment teams

Application lands in 2027–2028. Preparation lands now. Start here.

1. Run a gap analysis (compliance + product). Map your current PSD2 setup against the agreed PSD3/PSR texts — authorisation status, fraud controls, SCA flows, API infrastructure, and contracts. Identify what the move from directive to regulation removes and what it adds.
2. Implement Verification of Payee now (product). It’s already mandatory for SEPA Instant, and the PSR extends it. If you offer credit transfers, build the IBAN/name check and the mismatch-warning flow before liability attaches.
3. Rewrite the SCA-chain contracts (legal + payments ops). Delegated authentication shifts liability to whoever performs SCA. Update agreements with acquirers, gateways, wallet providers, and technical service providers so responsibility is allocated explicitly.
4. Harden fraud monitoring (payments ops + risk). You’ll need risk- and behaviour-based transaction monitoring, the ability to block suspect payments, and a path to participate in fraud-data sharing between PSPs.
5. Audit your open banking APIs (product + engineering). Test against the new performance and uptime expectations; the fallback exemption is going away.
6. Start re-authorisation early, if you’re a PI or EMI (compliance). Assembling the application package — governance, capital, and safeguarding evidence — takes time, and national regulators will face a queue. Engage your competent authority early.

Underneath all of this is one operational fact: PSD3 reassigns liability among all parties in a payment, and most serious payment operations now span multiple providers, rails, and authentication methods. Pulling SCA logic, routing, and provider-chain liability into a single control layer is what keeps that manageable.

A unified payment operating system like Corefy, with 600+ provider integrations⁠ and built-in routing and cascading, lets a payments team apply the same authentication and fraud logic across its whole stack instead of reconciling dozens of provider behaviours by hand. The compliance work shifts from rebuilding to configuration.

Key takeaways

• One directive becomes two instruments. The PSR carries the conduct rules and applies directly across the EU; PSD3 keeps licensing and supervision. That split ends the national divergence PSD2 created.
• Fraud becomes a balance-sheet risk. Providers can be liable for inadequate fraud prevention, with mandatory reimbursement where a fraudster impersonates the PSP and the victim reports promptly.
• Verification of Payee is already here. The IBAN/name check has been mandatory for SEPA Instant since October 2025; the PSR extends it across credit transfers and attaches liability for missed mismatches. Treat it as present-tense.
• SCA gets more flexible and more accountable. Two-factor stays, accessibility becomes a legal right, and liability follows whoever performs delegated authentication — including schemes, gateways, and technical service providers.
• One licence for PSPs and e-money firms. EMD2 is repealed, and EMIs become a sub-category of payment institution, requiring re-authorisation. Open-banking API obligations get real enforcement teeth.
• Application lands in 2027–2028, but the work is a 2026 job. Gap analysis, VoP, SCA-chain contracts, and API performance can't wait for the Official Journal.