PSD3 will expand regulatory scope far beyond PSD2’s payment institution framework, imposing operational resilience, data governance, and governance requirements that demand immediate system and staffing changes across UK and EU banks. Payment Service Providers unprepared for these changes face enforcement action, operational disruption, and competitive disadvantage as larger players consolidate market share in open banking.
The Payment Services Directive 3 (PSD3) represents the most material evolution in European payments regulation since PSD2 came into force in 2018. Yet most banks and payment service providers have not begun systematic preparation. Unlike PSD2—which centred on strong customer authentication and API mandates for current accounts—PSD3 fundamentally restructures the regulatory perimeter itself, introducing new classes of regulated entities, tightening operational resilience standards, and mandating governance practices that existing compliance frameworks cannot simply bolt on.
This article addresses the specific operational and strategic gaps UK and EU banks must close before PSD3 enforcement begins, with practical implications for compliance heads, treasury managers, and payment operations leads.
What Is PSD3 and Why Does It Matter Right Now?
PSD3 is the European Commission’s legislative update to payments regulation, formally adopted and now in the implementation phase across EU member states and being adapted for UK law post-Brexit. It extends regulatory requirements to wallet operators, peer-to-peer (P2P) payment services, and certain embedded finance providers previously outside the direct regulatory net. It also mandates operational resilience standards aligned with DORA compliance frameworks, establishes new data access rights for third-party payment initiation service providers, and creates a fast-track licensing pathway for authorised payment institutions—a fundamental shift in market structure. For UK banks, Treasury consultation and parliamentary process have signalled similar scope, though separate from EU implementation.
The Core Structural Changes: PSD3 vs PSD2 at a Glance
PSD2’s regulatory architecture was binary: it separated payment service providers into two regulated classes—payment institutions and e-money institutions—and imposed authentication and security rules on account-holding banks and third-party initiators. PSD3 does not replace this framework; it extends it.
1. Expansion of Regulated Entities
PSD3 introduces new regulatory categories, most materially digital wallet operators and embedded finance providers who previously operated in regulatory grey space. Under PSD2, a wallet operator storing funds and processing transactions without holding a formal payment institution license could operate with minimal direct FCA or EBA oversight. PSD3 closes this gap. Any entity facilitating payment transactions—including cryptocurrency wallet operators and fintechs offering payment-as-a-service features—must now apply for authorisation or seek exemption through explicit documentation.
This matters operationally because it expands the universe of entities banks must now integrate with via regulated channels, increases KYC and AML friction on third-party onboarding, and forces fintech partnerships to undergo formal regulatory approval rather than contractual carve-outs.
2. Operational Resilience and ICT Risk Alignment
PSD3 explicitly references Digital Operational Resilience Act (DORA) standards, mandating that all payment service providers implement impact tolerance thresholds, critical function mapping, and ICT incident reporting aligned with DORA Annex I thresholds. This is not optional alignment; it is mandatory. PSD2 had no formal operational resilience requirement at the payment provider level—only generic governance rules in the PSD2 Regulatory Technical Standards (RTS).
In practice, this means banks and payment institutions must now establish a DORA-aligned critical function map specific to payment operations, conduct operational resilience assessments for payment-critical systems (including third-party payment gateways, card networks, and settlement infrastructure), and implement incident response playbooks with specified alert thresholds and escalation paths.
3. Data Access and Governance Tightening
PSD2 mandated API access for account information and payment initiation. PSD3 extends this to require banks to provide standardized data feeds to authorised third parties in machine-readable format and establishes a new category of “data access service providers”—entities that aggregate or re-package payment data on behalf of other regulated firms. This creates a multi-layer data governance requirement.
Critically, PSD3 also imposes explicit data minimization rules: banks must limit data sharing to what is strictly necessary for the payment service and must contractually enforce this principle with all third parties. This requires audit capabilities banks often lack, particularly when third-party integrations have been in place since PSD2 implementation.
Specific Regulatory Changes Affecting Bank Operations
Customer Authentication and Strong Customer Authentication (SCA)
PSD2’s SCA framework remains in place, but PSD3 tightens exemption thresholds and introduces “soft” SCA rules for very-low-value transactions and recurring payments in subscription services. Banks and payment institutions must now implement risk-based SCA assessment tools that can calibrate exemptions per customer and transaction type without simply defaulting to the standard €30 or £30 threshold.
This shifts compliance from a static rule (“exempt payments under €30”) to a dynamic risk decision. Most banks’ current SCA implementations cannot do this at transaction scale, requiring investment in real-time risk engines or third-party SCA service providers.
Contingency and Continuity for Payment Processors
PSD3 explicitly requires that banks and payment processors maintain redundant payment clearing and settlement arrangements and test continuity plans quarterly (not annually as most institutions do now). The regulation references G-SIB-level liquidity and operational resilience standards, applying them to mid-market and smaller payment processors for the first time.
For a mid-sized payments team, this means identifying secondary settlement partners, implementing real-time settlement monitoring, and conducting tabletop exercises that involve treasury, operations, and technology teams. Many banks have these in place for interbank payments but not for consumer payment processing.
Third-Party Risk and Outsourcing Governance
PSD2 required banks to manage third-party risk through contractual terms and periodic audits. PSD3 mandates specific governance gates: banks must conduct formal third-party risk assessments prior to engagement, maintain a register of critical outsource arrangements, establish exit protocols, and—critically—perform an annual technology risk assessment for any third party providing ICT or payment system services.
This has direct budget implications. Banks using third-party payment gateways, card processors, or fintech integration platforms must now budget for annual third-party risk reviews, technology assessments, and exit planning—costs that were previously implicit or informal.
The Algoy Perspective
What most banks are overlooking is that PSD3’s operational resilience and data governance requirements cannot be implemented through compliance remapping alone. They require functional changes to how banks operate payments infrastructure.
A bank might have acceptable SCA rules and API documentation under PSD2, but PSD3 demands that those banks can demonstrate—in real-time—that payment data is being shared only for authorized purposes, that third-party processors meet impact tolerance thresholds, and that every material payment system has a tested continuity plan. These are not compliance questions; they are architecture and operations questions.
The uncomfortable truth is that most mid-market and smaller banks will not have in-house capability to execute this transition. They will outsource it—either to Big Four consulting firms (at cost), to cloud infrastructure providers (at operational dependency risk), or to managed compliance vendors (at ongoing SaaS cost). The structural winners will be established payments platforms (Stripe, Wise, Adyen) that can absorb the compliance cost across scale and smaller banks that consolidate payments operations with larger regional or pan-European partners.
Practical Implementation Roadmap for Compliance and Payments Teams
Phase 1: Regulatory Mapping (Months 1–3)
Establish a formal regulatory implementation programme. Appoint a PSD3 programme lead (internal or external) reporting to the Chief Compliance Officer. Map each new PSD3 requirement to current state operations and identify gaps. Document which gaps require technology investment, which require process change, and which require staffing.
Phase 2: Operational Resilience and ICT Risk (Months 3–8)
Conduct a DORA-aligned critical function assessment specific to payment operations. Identify which payment systems (card processing, open banking APIs, settlement gateways) qualify as critical. For each, establish impact tolerance thresholds, define recovery time objectives, and map dependencies. Commission independent assessments if internal capability is limited.
Phase 3: Data Governance and Third-Party Integration (Months 6–12)
Audit all existing third-party integrations (payment APIs, data feeds, SCA service providers). Document what data is being shared, to whom, and for what purpose. Identify integrations that violate PSD3 data minimization rules. Implement contractual amendments or integration redesigns. This phase is typically the longest because it often involves renegotiating established partnerships.
Phase 4: Testing and Documentation (Months 9–18)
Conduct operational resilience tests (tabletop exercises for payment disruptions, failover tests for critical payment systems). Document all findings and remediation. Prepare regulatory submission documentation.
Frequently Asked Questions
When does PSD3 enforcement actually begin?
The EU has signalled phased implementation, with most core requirements effective by late 2026 or early 2027, though member states retain discretion on transposition timing. The UK is running a separate consultation process; implementation is likely 12–18 months behind the EU. Most banks should assume 18 months of implementation time from now.
Does PSD3 apply to non-EU banks operating in Europe?
Yes. Any bank or payment service provider processing payments denominated in EUR or providing payment services to EU customers must comply, regardless of home jurisdiction. UK banks remain subject to UK implementation; UK banks processing cross-border EUR payments must comply with EU PSD3 rules for those transactions.
What is the difference between PSD3’s data access rules and GDPR?
PSD3 is more specific: it defines exactly what data banks must share with authorised third parties and in what format. GDPR defines how personal data can be used. Both apply simultaneously. A bank must comply with PSD3’s data-sharing mandate while also ensuring GDPR-compliant processing of that shared data.
Will PSD3 implementation increase payment costs for consumers?
Likely, in the short term. Banks will pass through compliance costs via higher fees for payment initiation services or reduced incentives for third-party aggregators. However, increased competition from new wallet operators and P2P services (now regulated) may offset this over time.
Sources and Further Reading
- EBA News and Press — EU Banking Authority guidance on PSD3 implementation and regulatory technical standards for payment service providers.
- FCA News — UK Financial Conduct Authority announcements and consultation documents on UK payments regulation and PSD3 adaptation.
- McKinsey Financial Services — Strategic analysis and implementation frameworks for payments regulation and digital transformation in banking.
