The EU payments package, PSD3 and the Payment Services Regulation, is settled in substance and unfinished in procedure. Parliament and Council reached a provisional political agreement on 27 November 2025, the Council published the final compromise texts on 23 April 2026, and the Parliament’s ECON committee approved the compromise on 5 May 2026. What remains is formal adoption, Council signature, and publication in the Official Journal. Nobody is renegotiating the substance.
That combination is exactly the situation payment firms tend to handle badly. The instinct is to wait for the Official Journal date before committing budget, because the package is not yet law. But the prevailing market expectation is publication in the second half of 2026 with substantive application landing in 2028, and the things the package demands, a payee verification layer, a reimbursement case-management workflow, reworked authentication journeys, are multi-quarter programmes with dependencies on core banking systems and payment rails. A firm that starts when the text is formally final will spend the transition period compressing two years of work into one.
Two clocks, not one deadline
The package splits into two instruments with different timing mechanics. The PSR is a regulation: it applies directly across the EU after its own transition period, and recent implementation commentary converges on early-to-mid 2028 for the main obligations. PSD3 is a directive: it needs national transposition, and one market estimate puts that at 18 months from publication, which gives a mid-2027 to end-2027 transposition window if the Official Journal lands in mid-2026. One live legislative tracker expects publication in June or July 2026, with possible slippage to September for legal-linguistic finalisation and plenary scheduling.
For a firm operating in several member states, the same product can therefore face different cutover dates depending on where the directive is implemented and which obligations sit in the directly applicable regulation. Release planning should treat the PSR track and the PSD3 transposition track as separate programmes with separate dates, rather than one project with a single go-live. Some provisions phase in later still: one mid-2026 implementation note puts a 27-month runway on the payee-verification provisions specifically.
The liability shift is the expensive part
The package is widely understood to extend fraud reimbursement beyond the classic unauthorised-payment cases into authorised push payment and impersonation fraud, with IBAN-name matching as a core mechanism. The operative article text is not yet in the Official Journal, so precise scope should be confirmed against the final publication, but the direction is fixed: expect mandatory payee verification infrastructure and a liability reallocation around impersonation fraud as part of the go-live burden in 2027–2028, not a 2026 compliance item.
Reimbursement liability changes the economics of scam detection. When an impersonation scam becomes a reimbursable event rather than a customer loss, every APP fraud your controls fail to stop lands on your own income statement. That moves detection upstream: real-time scoring of outbound payments, payee-name mismatch handling inside the payment journey, and a claims process that can gather evidence, route liability, and decide reimbursement at volume. Firms that treat this as a legal-team problem will discover it is a payments-engineering problem wearing a legal wrapper.
What to build in 2026
Because the compromise texts are fixed, the remaining risk in this package is implementation effort, not policy reversal. That makes the following items safe to start now:
- A payee verification service. Internal or vendor-integrated, it needs to check beneficiary names, return standardised match outcomes to the payment journey, and log evidence for later disputes. The interface design matters as much as the matching: how a close-match result is presented to the payer will be examined whenever liability is argued.
- A reimbursement case-management workflow. Intake, evidence collection, liability routing, and reimbursement decisioning for impersonation and APP fraud claims. For most PSPs this is a new operational function, not an extension of an existing queue.
- An SCA journey inventory. The final authentication articles are not spelled out in the circulating summaries, so treat SCA as a change-management item: catalogue every authentication journey, exemption path, fallback, and step-up trigger now, so they can be modified quickly once the final text applies.
- Consent and API observability. The open-banking side of the package will be felt in third-party access operations. Consent state tracking, uptime monitoring, a proper error taxonomy, and dispute evidence for interface performance all need to exist before a supervisor asks for them.
The audit trail decides the disputes
Everything above generates disputes, and disputes are decided on records. When a customer claims they were scammed despite a name-match warning, the firm needs the event-level record: what the verification service returned, what the customer was shown, what they confirmed, what the fraud engine scored, and when. When a supervisor asks why a reimbursement claim was refused, the case file needs the same lineage.
That means designing the evidence layer alongside the controls, not after them. Every payee check, fraud signal, authentication event, and reimbursement decision should write a durable record with timestamps and the exact data presented to the user. The common failure mode is a verification service that logs its match result but not the rendering, leaving the firm unable to prove what the payer actually saw. Retention, replayability, and access for dispute handlers are engineering requirements with a direct P&L consequence once the liability rules bite. The firms that will absorb this package cheaply are the ones treating 2026 as the year to build the plumbing, while the deadline still looks comfortably far away.
FAQ
Is it worth committing budget before the Official Journal publication?
Yes, for the long-lead items. The compromise texts were published in April 2026 and the committee vote is done, so the remaining risk is timing slippage, not substance change. Payee verification, reimbursement case management, and SCA journey inventories carry delivery risk that dwarfs any residual uncertainty in the text. Start with the items that pay off regardless of the exact application date.
We already run chargeback operations. Can that team absorb APP reimbursement claims?
The investigators transfer; the workflow does not. Chargebacks ride card scheme rules with defined reason codes and network arbitration. An impersonation-fraud reimbursement claim is a liability decision on a credit transfer, where the firm assembles its own evidence, applies its own liability routing, and answers to a supervisor rather than a scheme. Expect new intake flows, different evidence standards, and tighter decision clocks.
The payee-verification provisions may phase in later. Can we defer that build?
Deferring it is usually a mistake even if the legal deadline sits later, with one mid-2026 note citing a 27-month runway for those provisions. Payee verification is the mechanism that limits your losses once impersonation fraud becomes reimbursable, so running it early reduces exposure before it is mandatory. It is also the build with the longest tail: matching quality, counterparty data, and the payer-facing presentation all take iterations to get right.