PSD3: What It Requires and Who It Applies To

What is PSD3?

PSD3, formally "Proposal for a Directive on Payment Services and Electronic Money Services in the Internal Market" (COM(2023) 366 final), is a legislative proposal the European Commission published June 28, 2023 to replace PSD2 (Directive 2015/2366/EU), which has governed EU payment services since January 2018.

PSD2 opened the market. It introduced open banking APIs, mandated strong customer authentication, and let fintechs initiate payments and aggregate account data. That was real progress. But implementation diverged sharply across 27 member states. Open banking APIs were unreliable. Authorized push payment fraud rose, and liability frameworks left consumers with little recourse after being tricked into authorizing fraudulent transfers. The Commission's 2022 review found that API quality was insufficient and that enforcement was inconsistent enough to fragment the single market for payments.

PSD3 fixes those structural gaps. It's published alongside a companion Payment Services Regulation (PSR, COM(2023) 367 final). The PSR is a regulation, so it applies directly in all 27 member states the day it enters into force, with no national transposition required. The directive itself needs an implementation period after entry into force before compliance obligations apply to firms.

As of late 2024, both texts were in final trilogue negotiations between the European Parliament, Council, and Commission. Entry into force is expected in 2025 or 2026. The European Banking Authority had been calling for these reforms since 2022. Their Opinion on the PSD2 Review (December 2022) is the most detailed public document on what supervisors expected the next directive to fix, and it maps closely onto what PSD3 actually delivers.

Who does PSD3 apply to?

PSD3 applies to any firm providing payment services or issuing electronic money within the EU, or providing services to EU-based customers. There's no revenue or asset-size threshold.

Covered entity types:

• Banks and credit institutions: All EU-authorized banks holding payment accounts or executing payment transactions. This includes every retail bank, private bank, and savings institution with EU authorization.
• Payment institutions (PIs): Firms licensed to provide payment initiation, account information services, or money remittance. Revolut, Wise, and similar fintechs operating under EU PI licenses fall here.
• Electronic money institutions (EMIs): PSD3 absorbs the separate EMI licensing category into an expanded PI framework. Current EMIs get 24 months after the directive enters into force to re-authorize under the new classification.
• Account information service providers (AISPs): Third-party fintechs that aggregate account data across multiple banks for consumers. Open banking aggregators are a core example.
• Payment initiation service providers (PISPs): Fintechs that trigger credit transfers directly from customer bank accounts on behalf of merchants or users.
• E-commerce platforms and marketplaces: Where they handle payment transactions as a functional part of their commercial activity.
• Crypto-asset service providers (CASPs): To the extent they handle fiat-denominated payment services. The crypto-specific framework sits under MiCA; the fiat payment side sits under PSD3.

Non-EU firms serving EU consumers through passported licenses fall within scope for that portion of their business. UK firms, after Brexit, operate under the separate Payment Services Regulations 2017 and FCA supervision. That regime is converging with PSD3 in its direction of travel, but the two aren't legally equivalent.

The 27 EU member states each designate a national competent authority to supervise these entities. The EBA coordinates across those 27 supervisors and issues binding technical standards.

What does PSD3 require?

PSD3's core obligations, read together with the companion PSR, cover seven distinct areas:

1. Authorized push payment (APP) fraud liability: Banks and PSPs must refund consumers manipulated into authorizing fraudulent transfers, where the PSP failed to detect social engineering patterns or didn't apply required fraud warnings. Liability is split between the payer's PSP and the payee's PSP. The EBA's review estimated APP fraud losses exceeded €1.7 billion annually across the EU during the PSD2 period. PSD3 closes the liability gap that left most of those losses with consumers.

2. Strong customer authentication (SCA): PSD2's SCA requirements carry forward and tighten. The PSR specifies that if a PSP's remote electronic transaction fraud rate exceeds 0.13%, the low-risk transaction exemption suspends automatically until rates return below threshold. PSPs must monitor this in real time, not annually.

3. Open banking API reliability: Payment account providers must publish monthly API performance statistics covering uptime, latency, and error rates. APIs must hit minimum performance standards. Screen scraping is prohibited where a compliant dedicated interface exists. The PSR requires a documented fallback access route if the primary API is unavailable.

4. Fraud data sharing: PSPs must share transaction-level fraud signals with other PSPs through recognized schemes. This surfaces mule account networks and social engineering patterns that individual firms can't detect alone. The cross-institution information flow principle echoes FATF Recommendation 16 on wire transfer data sharing, applied here to domestic and cross-border payment fraud.

5. IBAN-name verification: Before executing a credit transfer, PSPs must check that the payee account name matches the IBAN. Mismatches must be flagged to the payer before the transfer proceeds. This overlaps with the Instant Payments Regulation (EU 2024/886) for instant credit transfers, but PSD3 embeds it as a baseline requirement for all credit transfers.

6. Licensing consolidation: The EMI category merges into PIs. Former EMIs have 24 months post-entry-into-force to re-authorize. No immediate disruption, but firms need to plan the re-authorization process.

7. Consumer protection: Unauthorized transaction disputes must resolve within 15 business days, or 35 for complex cases. Customers retain the right to claim refunds up to 13 months after an unauthorized transaction. Pre-contractual fee disclosures must be provided before any service agreement is signed.

What evidence do regulators expect?

Supervisors examining PSD3 compliance look for documented controls, system-generated logs, and test results. Based on EBA supervisory guidance and the directive text, here's what an examiner will request:

Authentication records:

• Transaction-level logs showing which SCA method applied per transaction and why
• Documentation of exemption decisions, with the fraud rate data that justified each one
• Penetration test results and vulnerability assessment reports for authentication systems
• Proof of real-time fraud rate monitoring against PSR thresholds

Fraud detection and APP fraud liability:

• Transaction monitoring rule sets, thresholds, and tuning change history
• Logs of APP fraud complaints received, investigated, and resolved
• Written decisions for cases where refund was denied, with stated reasoning
• Bilateral agreements with counterparty PSPs on liability-sharing procedures

Open banking:

• Monthly API performance dashboards covering uptime, latency, and error rate
• AISP and PISP access logs with customer consent records attached
• Fallback access mechanism documentation

IBAN-name verification:

• System logs showing checks performed before each credit transfer
• Records of mismatches detected, warnings displayed to customers, and transfers halted

Fraud data sharing:

• Documentation confirming participation in a recognized sharing scheme
• Records of data contributed and received, with retention timestamps showing at least five years

Governance:

• Board-approved policies on SCA exemption selection and APP fraud liability
• Staff training records covering PSD3-specific obligations
• Written escalation procedures for when fraud rate thresholds are breached

Firms that've deployed KYC and identity verification automation tend to have the transaction-level authentication log infrastructure already in place. Those relying on manual review face a harder job producing the granular per-transaction records examiners expect.

Common failure modes

Here's how firms actually get cited, based on enforcement actions under PSD2 and early PSD3 supervisory signals:

• SCA exemption overuse without threshold monitoring: Firms apply the low-risk transaction exemption but don't track whether their fraud rate stays below 0.13%. When rates drift above the ceiling, the exemption becomes invalid retroactively. Supervisors have caught this in post-incident reviews where firms couldn't produce real-time monitoring records.

• APP fraud classified as user error: PSD3 shifts liability. Firms that still treat APP fraud as the customer's problem, without examining whether their fraud warnings or monitoring were adequate, will face enforcement. Italian supervisors cited multiple payment institutions under PSD2 for exactly this failure: the fraud happened, the customer complained, and the PSP had no documented process for evaluating its own culpability.

• API availability not documented: Several banks had open banking APIs that met uptime targets but couldn't produce the monthly performance reports PSD3 mandates. The reporting obligation is separate from actual performance. Both must be documented.

• IBAN-name checks without audit trails: The check was performed but results weren't logged. Examiners want records showing what was verified, when, and what happened when a mismatch occurred. Assertions don't satisfy this requirement.

• Fraud data sharing participation on paper only: Firms that are nominally members of a sharing scheme but can't demonstrate they acted on signals received will be flagged. Membership isn't enough; documented response processes are required.

• Stale consumer-facing documentation: T&Cs and pre-contractual fee disclosures must reflect PSD3 obligations from the first day of applicability. Firms that update back-office controls but leave consumer documents unchanged get cited.

The Commission's 2022 PSD2 review documents what went wrong under PSD2. Read it as a preview of PSD3 enforcement priorities.

Penalties for non-compliance

PSD3 sets minimum penalty thresholds. Member states can exceed them; they can't go below.

Under the directive, national competent authorities must have powers to impose:

• Administrative fines of at least €5 million or 10% of total annual turnover (whichever is higher) for serious institutional breaches
• Personal fines of at least €700,000 on individuals responsible for the breach
• Temporary bans on exercising management functions
• Mandatory public disclosure naming the firm, the nature of the breach, and the penalty amount

These are floors, not caps. France and Germany have historically imposed above-minimum fines for payment services failures.

Lithuania is a useful benchmark because it licenses a large share of EU-passported fintechs. The Bank of Lithuania's enforcement register (lb.lt/en/sanctions) shows multiple payment institution fines in the €200,000 to €1 million range for SCA failures and inadequate fraud controls under PSD2. PSD3's higher minimum floors will push those figures up.

The UK's FCA shows the scale regulators reach when systemic controls are weak. Between 2018 and 2023, it issued over £150 million in aggregate fines to financial firms for AML and payment control failures. Its fine against Santander UK for AML deficiencies spanning its payment operations illustrates that regulators treat payment processing failures as a serious enforcement priority, not a technicality (FCA enforcement actions, fca.org.uk).

License suspension is the existential risk for smaller fintechs. A supervisor can revoke a PI license for serious or repeated breaches. Under PSD3, public disclosure of enforcement actions is mandatory for material breaches, adding reputational cost on top of financial penalties.

Related regulations and frameworks

PSD3 fits into an interconnected set of EU and international requirements. It doesn't stand alone.

DORA (Digital Operational Resilience Act), which applied from January 2025, covers ICT risk management and incident reporting for financial entities. PSD3's API uptime requirements and SCA system resilience provisions overlap with DORA directly. Firms subject to both should expect joint supervisory examinations. There's no legal conflict; the two frameworks are additive.

The EU Anti-Money Laundering Regulation (AMLR) and the Sixth AML Directive handle the AML obligations payment institutions carry. PSD3's fraud data sharing provisions intersect with FATF Recommendation 20 on suspicious transaction reporting. A payment flagged under PSD3 fraud sharing may simultaneously require a suspicious transaction report (STR) under AML rules. Compliance teams need both sets of thresholds in their monitoring systems.

MiCA (Markets in Crypto-Assets Regulation) and PSD3 interact wherever a CASP handles fiat-denominated payments alongside crypto services. MiCA governs the crypto side; PSD3 governs the fiat payment side. Both apply.

The EU Transfer of Funds Regulation (TFR), which extended the travel rule to crypto-asset transfers, requires originator and beneficiary data to accompany wire transfers. PSD3's IBAN-name verification requirement works alongside TFR's data accuracy obligations for cross-border transfers.

For UK firms, the equivalent framework is the Payment Services Regulations 2017 and the FCA's access-to-payment-systems regime. That regime is not PSD3 and doesn't apply by default to UK-only operations. Firms serving both UK and EU customers need both frameworks mapped and managed separately.

How FluxForce supports PSD3 compliance

PSD3 compliance rests on three operational capabilities: real-time APP fraud detection with documented evidence trails, SCA exemption scoring with audit-ready logs, and open banking API performance monitoring. FluxForce AI agents address all three. Nova Sentinel monitors payment flows for APP fraud and social engineering patterns. It produces the transaction-level audit records examiners expect. Aiden Flux automates SCA exemption scoring against PSR thresholds, logs every exemption decision, and flags threshold breaches proactively. API performance dashboards provide the monthly uptime and latency records the directive mandates. Book a demo to see how these work in a live payment environment.