PSD3 and PSR: Legislative Status and Operator Checklist

PSD3 and PSR need an implementation programme, but its calendar must start with the actual legislative record. On 28 October 2026, Parliament's PSR procedure file and PSD3 procedure file both record approval of the negotiated text in ECON on 5 May 2026, a status of awaiting Council's first-reading position, and an indicative plenary date of 14 December 2026. The earlier expectation of a late-May vote and summer publication should no longer drive an operator's compliance calendar.

The useful response is to separate work that can start from the agreed policy direction from work that needs a final legal provision, technical standard or national implementation measure. That gives product, risk and compliance teams something concrete to do without converting a legislative forecast into a deadline.

Legislative Status and the Implementation Timeline

An implementation period expressed in months needs a defined legal starting event. Do not count from a committee vote, a press release or this article's publication date. Nor should a single headline period be applied to every provision: licensing transitions, technical standards and particular service obligations can have distinct arrangements.

For each deadline in your programme, store the instrument, article, triggering event, affected entity and responsible owner. Add a dependency flag when a date cannot yet be calculated from final publication. This is more useful than a provisional “Q1–Q2 2028” completion promise.

What PSD3 and PSR Cover

PSD3 is the directive track for the payment and electronic money services framework, including authorisation and supervision. PSR is the regulation track for operating requirements. The distinction matters for implementation: a directive calls for national transposition, while a regulation's applicable provisions operate directly.

For a group with several regulated entities, keep the prudential and licensing assessment alongside the product assessment. A shared checkout can still be delivered through different legal entities, permissions and supervisory relationships. A common European operating rule does not eliminate the need to know which entity provides each service.

Fraud Prevention and Liability

The Council's agreement announcement describes fraud-information sharing, IBAN/name checks and liability where providers fail specified preventive obligations. It also addresses scams impersonating a customer's PSP. That is a basis for scoping work; it does not establish unconditional reimbursement for every authorised scam.

Start with the loss paths in your own product: account takeover, impersonation, changed beneficiary details and customer-authorised transfers. For each path, identify the control, evidence retained, customer communication and team deciding reimbursement. Then map the final liability provision to that workflow. Do not price all APP losses as automatically transferred to the PSP or assume the EU model is identical to the UK's.

Verification of Payee also has an existing EU instant-payments legislative context. Do not defer an already-applicable obligation while waiting for PSR, or describe an existing euro-transfer requirement as a future-package invention. Test match, near-match, unavailable and customer-override journeys, retaining the response and displayed warning with the payment record.

Open Banking Access and Consent

The agreement's direction includes reducing barriers for open banking and improving user control over data access. Operators can already inventory API dependencies, consent capture, revocation and customer support handoffs.

Keep a record of each account-servicing provider's observed errors and the evidence needed to investigate them. Separate measured service behaviour from a future legal performance requirement. Do not write an automatic compensation assumption into a business case without the applicable final provision and remedy.

Financial Data Access (FIDA) is a separate legislative workstream. A common architecture for permission management may be sensible, but a shared technical component does not make the two instruments share legal scope, access rights or deadlines. Assess each data category and product against its own framework.

Authentication and SCA

Treat 3DS2 authentication, SCA applicability, exemption requests and issuer authorisation as separate decisions. A network token does not itself prove an exemption is available. Nor does a future clarification imply that every merchant-initiated or recurring payment receives identical treatment.

Before changing checkout logic, identify the relevant final text and any associated technical standards. Then test initial setup, subsequent payments, amended mandates, challenge recovery and authentication evidence passed to the acquirer. Measure conversion and fraud outcomes for the actual customer cohorts instead of assuming fewer challenges always improve the full payment outcome. The SCA exemption playbook covers the current operational distinctions.

Safeguarding: Keep the UK Programme Separate

The FCA's PS25/12 establishes a supplementary UK safeguarding regime, with rules taking effect on 7 May 2026. Its scope includes specified payment and e-money firms and relevant credit unions, with exclusions and qualifications. It is not an early-application milestone for EU PSD3 or PSR.

For an affected UK entity, assign the reconciliation, reporting, audit and resolution-record work to its safeguarding owner. For an EU entity, assess its applicable safeguarding requirements and future PSD3 changes separately. Group-wide policies can share controls, but a UK effective date must not be copied into the EU entity's legal obligations register.

A Practical Operator Sequence

1. Map scope: identify the entity, jurisdiction, service and existing permission for each payment journey.
2. Build a provision register: distinguish current obligations, agreed future changes and dependencies on final text or national measures.
3. Assign product owners: connect fraud, payee verification, consent, authentication and disclosure gaps to actual systems and retained evidence.
4. Estimate dependencies: ask providers which changes they deliver, which require your implementation and which remain subject to final rules.
5. Set acceptance criteria: test customer warnings, challenge recovery, consent revocation, case handling and reconciliation against the applicable requirement.
6. Rebaseline on publication: calculate each deadline from the correct legal event and validate any national transposition or licensing transition separately.

Keep the legal calendar and engineering sequence linked. Discovery, evidence retention and provider scoping can start before a fixed application date; a customer commitment or supervisory declaration needs the final requirement and evidence that the relevant entity meets it. The UK market guide and EU instant-payments guide provide the adjacent jurisdiction and rail context.