PSD3

PSD3 is not a wholesale reinvention of EU payments regulation — it is a targeted update to address what did and did not work in PSD2’s 2018–2020 transposition cycle. For operators managing European payment flows, the relevant changes cluster around three areas: open banking, SCA, and fraud liability.

Why PSD3 After PSD2

PSD2 achieved its primary goals — mandating open banking access and introducing SCA — but with significant friction:

Open banking underdelivered: Banks implemented PSD2 APIs inconsistently. Screen-scraping fallbacks remained necessary; uptime and latency requirements were uneven; access conditions for third-party providers (TPPs) varied. Payment initiation and account information services never reached the conversion rates the Commission expected.

SCA created friction without consensus: SCA’s rollout fragmented UX across the EU. Exemption interpretation varied by member state and by issuer. The 90-day reauthentication requirement for account aggregation apps caused poor user experience that the industry fought repeatedly via derogation requests.

APP fraud liability gap: Authorised push payment (APP) fraud — where victims are tricked into initiating payments themselves — sat outside PSD2 protections because the transaction was technically authorised. PSD3 shifts liability in cases of fraud where the PSP failed to flag high-risk indicators.

Key PSD3 Changes

Open banking access improvements: PSD3 requires banks to maintain dedicated open banking interfaces with defined uptime (99.5% SLA), latency requirements, and fallback mechanisms. Banks can no longer use interface design to create friction for TPPs accessing accounts on behalf of customers.

SCA clarifications: The 90-day periodic authentication requirement for account information services is being relaxed. SCA exemption thresholds and conditions are being standardised to reduce member-state fragmentation. Payment initiation flows are expected to become more consistent across the bloc.

Non-bank access to payment systems: PSD3/PSR extends the right of non-bank PSPs to directly access payment systems (including interbank settlement rails) under safeguarded conditions. Currently, non-bank PSPs must access payment systems through a bank sponsor, adding cost and dependency.

Fraud intelligence sharing: PSPs are given a framework (and in some cases an obligation) to share fraud intelligence with each other — modelling the UK’s Confirmation of Payee and Payment Systems Regulator approach.

PSD3 vs. PSR

The PSD3/PSR package has an unusual structure:

• PSD3 is a directive: it requires transposition by EU member states. National legislatures implement it, creating scope for variation. Timeline: EU adoption likely 2025; member state transposition ~18 months after.
• PSR (Payment Services Regulation) is a regulation: it applies directly in all EU member states without transposition, eliminating fragmentation for the provisions it covers. PSR covers the core payment service rules; PSD3 covers licensing and supervision.

This structure means some provisions will be uniform across the EU immediately; others will vary by how quickly member states transpose PSD3.

Operator Implications

If you accept EU cards: The SCA rule changes in PSD3 may affect which exemption strategies remain valid and how TPP-initiated payment flows work. Monitor the final text closely as it progresses through EU legislative process.

If you use open banking in the EU: PSD3’s API performance requirements and fallback mandates should improve TPP access reliability — particularly for payment initiation in markets where bank API quality has been poor.

If you operate in the UK: The UK’s post-Brexit PSR (Payment Systems Regulator) framework and Financial Services and Markets Act 2023 are evolving separately from PSD3. UK open banking rules are not governed by PSD3, though there is regulatory convergence pressure.