PSD3 Explained: What the Next Payments Rulebook Means for Builders

29/07/2026 - Product development

If you build payment products in Europe, you’ve been living under PSD2 for almost a decade. That era is ending. On 27 November 2025, the European Parliament and Council reached political agreement on PSD3 and its companion regulation, the PSR (Payment Services Regulation). National representatives signed off on the final text on 22 April 2026, and publication in the Official Journal is expected around June or July 2026 — though a slip to September wouldn’t surprise anyone who has watched EU legislation move before.

Here’s the part that matters for planning: the PSR applies directly just 20 days after publication, but PSD3 itself needs national transposition, with a targeted applicability somewhere around Q2/Q3 2028. In practice, that gives payment service providers roughly until the start of 2027 to get their implementation plans in order, even though the finish line stretches further out.

What’s actually changing

PSD3 folds the separate e-money and payment institution licensing regimes into one, which simplifies life for anyone running both wallet and payment rails. It tightens authentication and fraud liability rules, especially around authorised push payment (APP) fraud — banks and PSPs will carry more responsibility for reimbursing victims, which means fraud detection stops being a nice-to-have and becomes a hard compliance requirement. IBAN-name matching (confirmation of payee) is being extended more broadly across the euro area. And critically, the open banking provisions get real teeth: dedicated, well-maintained APIs become mandatory, and the fallback option of screen-scraping is finally being phased out for good.

Why this is a build problem, not just a legal one

Every one of those changes lands on your architecture, not just your policy documents. Confirmation-of-payee checks need to be wired into the payment flow without adding friction. APP fraud liability means your transaction monitoring and risk-scoring need to be defensible in an audit, which means logging, explainability, and traceability from day one. And if you’ve been relying on a screen-scraping fallback for account access, that clock is running out — you need production-grade, well-documented APIs that can handle real load, not a workaround.

We’ve been building payment infrastructure since before “fintech” was a word — Maxcode has been a key technical partner in the iDEAL ecosystem since 2005, so we’ve watched more than one generation of payment regulation turn into architecture decisions. PSD3, PSR, confirmation of payee, APP fraud liability — this is how we think, not a crash course we take on your dime. Our senior engineers sit directly with your team, translating the regulation into an actual sprint plan — API design, fraud-detection logic, licensing-adjacent architecture — and we ship it in weekly releases, not a big-bang launch in month 20 of a 21-month window. Fast and compliant aren’t a trade-off for us. If you want a dedicated, hands-on partner to turn PSD3 into working software, that’s the conversation to start now, not in 2027.

If PSD3 is already showing up in your 2027 planning, that’s exactly the conversation we have every day. Get in touch with the Maxcode team and let’s scope out what it actually takes to build for it.

This content is provided for general informational purposes and reflects the regulatory landscape as understood in July 2026. It does not constitute legal advice. Organizations should consult qualified legal counsel to assess how these regulations apply to their specific situation.

Share this article