PSD3/PSR: Turning the Provisional Agreement into a 2026-2027 Engineering Backlog

The PSD3/PSR provisional agreement is not the final text, but it locks enough scope that waiting for the Official Journal is now the expensive option.

On 21 November 2025 the European Parliament and Council announced a provisional political agreement on the payments package: the third Payment Services Directive (PSD3) and the directly applicable Payment Services Regulation (PSR). The final compromise texts still have to clear legal-linguistic revision and formal adoption, and the article numbers you cite today may move. But the substance that drives engineering work is settled enough to plan against, and most of it takes longer to build than the transition period allows. Firms that wait for the definitive text before opening a backlog will start the clock already behind.

What the timeline actually gives you

Treat the dates as directional, not fixed. Formal adoption and Official Journal publication are widely expected during 2026; the PSR is then set to apply after a transition period of around 18 months, with the Council having pushed for closer to 24. On the current trajectory that lands core application somewhere in the second half of 2027 or early 2028. Two carve-outs matter for sequencing: the payee-verification obligation is expected to run on a longer clock than the general PSR, and the licence grandfathering under PSD3 gives existing payment institutions and e-money institutions a defined window — reported at 24 months, extendable — to re-authorise against the new prudential framework.

None of those numbers should be quoted to a board as settled until the final text confirms them; verify each against the adopted regulation and the transposing national law when they land. What they tell you now is the shape of the runway. “2027 to 2028” reads as distant on a strategy slide. It is not distant for anything that touches account data, authentication or interbank messaging, where 18 months of calendar time routinely becomes 9 months of usable engineering once you subtract discovery, procurement, testing and change freezes.

Verification of Payee is the long pole

The single most demanding requirement is Verification of Payee: before a credit transfer is authorised, the payer’s provider must check that the payee name matches the account identifier and warn the payer where it does not. The service has to be free to the user and return a result in a handful of seconds. EU firms in the instant-payments regime have already met a version of this, but the PSR extends the logic more broadly, and the engineering is the same regardless: a real-time matching service, a name-normalisation and fuzzy-match capability that is neither so strict it rejects legitimate payees nor so loose it waves fraud through, and a synchronous call sitting in the critical path of every payment initiation.

That is a latency-budget problem before it is a compliance problem. If your payment-initiation flow has no room for an extra synchronous hop, you are looking at caching strategies, timeout-and-fallback behaviour, and a matching engine whose thresholds are tunable in production rather than baked into a release. Build the match logic as configuration you can adjust against real false-positive and false-negative rates, the same discipline that separates a workable controls engine from a brittle one — an argument I have made at length about turning a rulebook into a configurable controls engine rather than hard-coded logic. This is a low-regret workstream: better payee matching reduces misdirected-payment losses whether or not the final text shifts.

Strong authentication becomes an accessibility obligation

The PSR keeps strong customer authentication but reframes it. The agreement treats access to SCA as a right and requires providers to offer at least one method that does not depend on a smartphone, so that customers without a device, with a disability, or with low digital confidence are not locked out. If your authentication estate assumes an app and a push notification, that assumption is now a gap. You need at least one supported non-smartphone path, designed and tested, not bolted on.

There is a second consequence that catches firms out. Where you delegate authentication to a third party — a wallet, a gateway, a payment orchestrator — that delegation is treated as outsourcing, which pulls it into your operational-resilience and third-party governance obligations, and the delegating provider keeps the liability. If you have been treating a wallet’s authentication as someone else’s problem, the PSR says otherwise. That is a supplier-register and contract question to raise in 2026, not after the text applies.

Open banking access, rebuilt

The PSR reworks data access. The much-litigated fallback interface is set to go, replaced by a mandatory dedicated interface that must perform on a par with a bank’s own channels, with an explicit list of prohibited obstacles and formalised documentation, testing and reporting duties. Users get a permission dashboard to see and revoke the access they have granted. For account-holding institutions this is real interface work: performance parity is measurable, the prohibited-obstacle list is enforceable, and a supervisor can test both. For third-party providers it is a question of which of your integrations depend on behaviour the PSR now bans, and how quickly the banks you rely on will ship compliant interfaces.

Alongside this sits fraud-information sharing: the PSR is expected to give PSPs a clearer legal basis to exchange specified fraud data with each other, under GDPR safeguards and with a data protection impact assessment behind it. The data pipes and the governance for that consortium exchange take time to stand up, and the DPIA cannot be an afterthought.

The backlog to open now

1. A Verification of Payee service with a tunable matching engine and a defined latency budget in the payment-initiation path.
2. At least one non-smartphone SCA method, designed, built and accessibility-tested.
3. A register of every delegated-authentication arrangement, reclassified as outsourcing with the contracts and audit rights that implies.
4. A dedicated-interface plan measured against performance parity and the prohibited-obstacle list, plus a permission dashboard.
5. The data pipeline and DPIA for inter-PSP fraud-information sharing.

Each of those is defensible on its own terms today — less fraud, better access, cleaner supplier governance — which is what makes them low-regret while the text is provisional. The pattern is the one I keep returning to on EU deadlines: a distant application date is a reprieve that is really a trap, because the work does not compress. Put PSD3/PSR on the same board view as everything else converging in this window — the kind of single-page picture I set out in the 2026-2028 EU digital-law deadline calendar — and sequence it against your real delivery capacity, not against the headline year.

The provisional agreement did you a favour. It told you what to build before it told you exactly when. The firms that treat that as permission to start are the ones that will not be re-authorising in a panic.