Risk And Compliance 11 min read

PSD3 and PSR: The ECON Vote, the 21-Month Implementation Clock, and What Operators Should Be Doing Now

EU Parliament's ECON Committee approved PSD3 (55–3–5) and PSR (50–2–2) on May 5, 2026. Plenary expected late May. OJ publication targets June/July. The 21-month implementation clock starts at publication — operators have ~24 months total.

PB
By Shaun Toh
TL;DR

ECON approved PSD3 (55–3–5) and PSR (50–2–2) on May 5, 2026. Plenary expected late May, OJ publication June/July, 21-month application clock starts then. Operators have ~24 months to rebuild fraud liability, SCA, open banking, and safeguarding architecture.

The European Parliament’s Committee on Economic and Monetary Affairs (ECON) approved the PSD3 and PSR texts on May 5, 2026 — a critical procedural milestone in the EU’s most consequential payments regulatory overhaul since PSD2 took effect in 2018. PSD3 passed 55 votes in favour, 3 against, 5 abstentions. PSR passed 50–2–2. The plenary vote is expected later in May 2026, followed by legal-linguistic review and publication in the Official Journal of the European Union — anticipated for June or July 2026 (with possible slip to September). The 21-month application clock starts at OJ publication, putting effective date in Q1–Q2 2028 under the standard scenario.

For operators, this is the regulatory event of the decade. PSD2 reshaped the European payments market for nearly ten years; PSD3 and PSR will define operator obligations through 2035 and beyond. The 21-month implementation runway is generous compared to many financial services regulations, but the substantive changes — particularly around fraud liability, SCA, Verification of Payee, safeguarding, and the introduction of the parallel FIDA regulation for financial data access — require infrastructure rebuilds, not configuration tweaks. This article walks through what was approved, what changes from PSD2, what operators should do in the 24-month window before effective date, and what to watch as the texts move through final adoption.

What Was Approved on May 5

The ECON Committee vote endorsed the trilogue agreement texts that COREPER (the Council of the EU’s permanent representatives committee) had endorsed on April 22, 2026. The texts approved by ECON cover two distinct legal instruments:

PSD3 — Payment Services Directive (Third) — a directive replacing PSD2 (Directive (EU) 2015/2366). Directives require member states to transpose the rules into national law within a specified period, allowing national flexibility on certain details. PSD3 governs payment institution authorisation, supervision, licensing thresholds, and prudential requirements.

PSR — Payment Services Regulation — a directly applicable regulation (no national transposition required). PSR governs the operating rules: fraud liability, SCA exemptions, open banking access, fee transparency, consumer rights, and the rules of the road for any operator providing payment services to EU customers.

The split between PSD3 and PSR is itself a regulatory upgrade. Under PSD2, the consolidated directive created national variation in operating rules (a German fee disclosure obligation could differ from a French one), which raised compliance costs for cross-border operators. By moving operating rules into a regulation (PSR), the EU eliminates that variation — one set of rules across all 27 member states.

The vote count is informative: PSD3 with 55–3–5 and PSR with 50–2–2 indicates broad cross-party consensus. The texts that emerged from trilogue (the negotiation between Parliament, Council, and Commission) are unlikely to face significant amendments in plenary. Operators should plan around the texts as they stand today.

The Implementation Timeline

The compliance clock works as follows:

PSD3 and PSR Operator Readiness Clock — timeline from April 22, 2026 (COREPER endorsement) through May 5, 2026 (ECON Committee approval: PSD3 55-3-5, PSR 50-2-2), late May 2026 (Parliament plenary vote expected), June–July 2026 (Official Journal publication, possibly slipping to September), through to Q1–Q2 2028 (general application date — 21 months after OJ publication). Safeguarding rules apply earlier from May 2026.

The PSD3/PSR readiness clock — from ECON vote to general application takes ~24 months in the standard scenario, but safeguarding rules kick in earlier (May 2026).

  • April 22, 2026 — COREPER endorsed trilogue texts
  • May 5, 2026 — ECON Committee approved texts (55–3–5 PSD3; 50–2–2 PSR)
  • Late May 2026 — Plenary vote expected (rubber-stamp, given ECON margins)
  • June–July 2026 — Legal-linguistic review and publication in OJEU (may slip to September)
  • OJ publication + 21 months — Generally applicable date for most provisions
  • Q1–Q2 2028 — Effective compliance date under standard scenario (Q3 2028 if OJ slips to September)

That timeline gives operators approximately 24 months from now to rebuild infrastructure for the new regime. Three caveats:

1. Some provisions kick in earlier. New requirements around how PSPs and e-money firms segregate, report, and audit safeguarded customer funds are set to take effect from May 2026 — ahead of the broader PSR package. Operators should not wait for the 2028 effective date on safeguarding compliance.

2. National transposition for PSD3 may vary. Member states have a transposition period for PSD3 (the directive component). National implementation choices on certain details (e.g., specific licensing thresholds, supervisory powers) may create some country-by-country variation even within PSD3 — operators with multi-country EU exposure should track national transposition closely.

3. FIDA — Financial Data Access — is a parallel track. The FIDA regulation, governing access to financial data beyond payment accounts (e.g., insurance, savings, investments, mortgages), is moving on a related timeline. Open banking under PSR applies to payment account access; FIDA expands the data access framework to broader financial product categories. Operators building open finance products should treat PSR + FIDA as a single regulatory programme, not two unrelated workstreams.

What Changes Most for Operators

Five substantive shifts deserve focused operator attention:

1. Verification of Payee (IBAN/Name Matching) Becomes Mandatory

Under PSR, PSPs processing credit transfers — including instant credit transfers, SEPA standard, and cross-border within the EU — must verify that the IBAN matches the name of the intended payee before authorising the payment. This is not new conceptually (the EU Instant Payments Regulation already mandated VoP for SCT Inst), but PSR extends it across all credit transfer flows.

Operational implications:

  • The technical implementation requires IBAN-to-name resolution at scale, with low-latency queries to the payee bank’s directory or a centralised matching service.
  • For cross-border flows, the matching service must work across all EU member states — single-country operators need to integrate the EBA CLEARING or equivalent.
  • For corporate flows (where the named payee is a company, not an individual), matching against business registry data is a separate workflow with different latency and accuracy characteristics.
  • The user experience must accommodate near-match scenarios (different transliterations of names, abbreviated business names) without creating excessive friction or false-positive blocks.

2. Fraud Liability Shifts (Authorised Push Payment Fraud)

The single largest economic change in PSR is the shift of liability for authorised push payment (APP) fraud — i.e., fraud where the customer is tricked into authorising a payment to a fraudster — from consumer to PSP in defined scenarios. PSP liability triggers when:

  • The PSP failed to perform Verification of Payee correctly
  • The PSP failed to detect impersonation of legitimate businesses or authorities
  • The PSP failed to act on reasonable indicia of fraud

This is a structural risk transfer. Under PSD2, APP fraud losses sat overwhelmingly with consumers; the UK already moved to mandatory PSP reimbursement in October 2024 with mixed but substantial PSP loss exposure. PSR brings the EU to a similar place. Operators need to:

  • Model expected APP fraud loss exposure under the new liability regime
  • Re-price products where fraud loss exposure materially affects unit economics
  • Invest in fraud detection capability — the UK experience shows that PSPs that built strong APP detection (transaction monitoring, behavioural signals, social engineering indicators) absorbed the liability shift; PSPs that did not faced material losses

For deeper context on the AI-driven fraud detection layer that operators are deploying, see the AI Fraud Detection in 2026 article.

3. Open Banking and FIDA — Access Rules Tighten

Under PSD2, open banking gave Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs) the right to access payment accounts via dedicated APIs. The implementation was uneven across member states — some banks built minimal-compliance APIs, others built rich access; AISPs/PISPs faced inconsistent uptime, latency, and feature parity.

PSR tightens the access rules:

  • Banks must provide API access at parity with their own customer-facing channels (no more “second-class” APIs for third parties)
  • Standard performance metrics — uptime, latency, error rate — must be published and audited
  • New compensation rules apply when banks fail to meet performance standards

FIDA extends this access model beyond payment accounts to insurance, mortgages, savings, investments, and pensions. The regulatory architecture is similar — schemes (industry-defined data sharing frameworks) are formalised, and Financial Information Service Providers (FISPs) get access rights mirroring AISP/PISP rights under open banking.

For operators building open banking or open finance products, see the UK and EU Variable Recurring Payments article for VRP context, which is one of the killer use cases that PSD3/PSR scaffolding makes more durable.

4. SCA Exemption Rules Clarified

3DS2-driven SCA has been operational since PSD2 RTS implementation (2019). PSR clarifies several SCA exemption scenarios that have been operationally ambiguous:

  • Low-value contactless transactions — exemption thresholds harmonised across member states (currently varying)
  • Merchant-Initiated Transactions (MITs) — clearer rules on when MIT scope applies and when SCA on initial mandate is sufficient for subsequent transactions
  • Trusted beneficiary lists — formalised in PSR with specific rules on how customers manage their lists
  • Recurring transactions — clearer treatment of subscription models, including the interaction with VRP-style flows

The clarifications are generally favourable for operators (fewer SCA challenges = better conversion), but require updates to checkout flows and exemption logic.

5. Safeguarding Requirements Take Effect Earlier

New requirements around how PSPs and e-money firms segregate, report, and audit safeguarded customer funds are set to take effect from May 2026 — well ahead of the broader PSR effective date. The new rules tighten:

  • Segregation requirements (specific account structures and titling)
  • Audit cadence and methodology (independent audit, with prescriptive testing requirements)
  • Reporting to national supervisors
  • Diversification rules for safeguarded fund holdings

Operators should treat this as the most urgent operational compliance item in the package — the May 2026 effective date is now (depending on when this article is read), and the operational impact of failed safeguarding audits is severe (including potential licence withdrawal).

What Operators Should Do in the 24-Month Window

A practical sequence for the next 24 months:

Months 1–3 (now through Q3 2026): Safeguarding architecture audit. Identify gaps against the new segregation, audit, and reporting rules taking effect from May 2026. Engage your auditor on the new methodology.

Months 3–6: Verification of Payee technical scoping. Define the integration architecture for IBAN/name matching across your transaction flows. Engage with your acquirer or PSP on their VoP roadmap. Identify cross-border and corporate-flow edge cases.

Months 6–9: Fraud liability modelling and re-pricing. Model expected APP fraud loss exposure under the new regime. Re-price products where the shift materially affects unit economics. Invest in fraud detection enhancements before the liability shift takes effect.

Months 9–12: Open banking and FIDA strategy. Decide whether to build, buy, or partner for open banking and open finance access. The PSR/FIDA framework rewards operators with strong API products; the cost of building from scratch is rising.

Months 12–18: SCA flow updates. Update checkout, MIT, and exemption logic for the clarified rules. Test the updated flows for conversion impact (the clarifications are generally favourable, but specific implementations matter).

Months 18–24: Final readiness, audit, and monitoring infrastructure. Build the compliance evidence package for your supervisor. Confirm cross-border passporting arrangements remain valid under PSD3’s amended authorisation regime.

This is a 24-month operational programme, not a tick-box compliance exercise. Operators that treat PSR/PSD3 as configuration changes will face material compliance and competitive risk by 2028.

What This Means for Operators

PSD3 and PSR are the most consequential European payments regulations of the next decade. The May 5, 2026 ECON vote moves the package decisively toward final adoption — plenary in late May, OJ publication around June/July (possibly September), 21-month application clock starting then.

The substantive changes are not incremental. Mandatory Verification of Payee, structural shift in APP fraud liability, tighter open banking access rules, clearer SCA exemption rules, and prescriptive safeguarding requirements together require infrastructure rebuilds and unit economics re-pricing across the operator base.

For operators with EU customer flows, the next 24 months is the planning and build window. The operators who emerge well-positioned in 2028 will be those who treated PSR as an operational programme starting now — not those who waited for transposition deadlines and effective dates.

For deeper regulatory context on the EU instant payments framework that PSR builds on, see the EU Instant Payments Regulation article. For UK operators evaluating the parallel UK regulatory programme, see the United Kingdom market guide. For the broader open banking context, see the Variable Recurring Payments article.

The 21-month clock is generous on paper, tight in practice. Start now.

Shaun Toh By Shaun Toh · Director, Digital Payments · Razer

Related briefings