PSD3 & PSR: What Fintech and Payment Companies Must Prepare for Now

The EU's payment services framework is undergoing its most significant overhaul since PSD2 came into force in 2018. The European Commission's proposal package — comprising a revised Payment Services Directive (PSD3) and a new, directly applicable Payment Services Regulation (PSR) — will reshape how payment institutions, e-money institutions, banks, and fintechs operate across the bloc.

The structural shift from a directive to a regulation for the core operational rules is itself significant: unlike PSD2, which required national transposition and resulted in fragmented implementation across member states, the PSR will apply identically in all 27 EU countries from day one. For payment businesses operating across multiple markets, this eliminates one of the most painful compliance headaches of the PSD2 era — but it also means there are no friendly national implementations to shelter behind.

Understanding what's actually changing — and separating material compliance obligations from incremental adjustments — is the challenge for compliance teams now preparing for a framework that will apply in 2026 and beyond.

The PSD3 / PSR Architecture: What's Changing and Why

The PSD2 review that preceded PSD3 found three categories of persistent problems: inconsistent national implementation of PSD2 created regulatory fragmentation; open banking growth was stalled by uneven API quality and restrictive bank behaviour; and payment fraud had increased materially despite Strong Customer Authentication requirements being in place.

The Commission's response is a two-instrument package:

• PSD3 (Directive): Covers licensing, authorisation, and supervision of payment institutions and e-money institutions — matters that require national law to be effective. PSD3 harmonises the regime more tightly than PSD2 but still requires national transposition.
• PSR (Regulation): Covers operational rules — SCA, open banking access rights, liability for fraud, payment information requirements — that should apply uniformly. The PSR is directly applicable without transposition, eliminating the fragmentation that plagued PSD2.

For compliance purposes, most of the day-to-day obligations that affect payment operations — SCA, open banking, liability — will come from the PSR. The licensing and authorisation framework comes from PSD3.

Major Changes That Matter for Compliance Teams

1. Fraud Liability: The IBAN-Name Check and IBAN/Name Mismatch Rules

One of the most operationally significant changes in the PSR is the mandatory extension of IBAN-name verification checks — currently implemented in some member states for credit transfers — across the EU, combined with a revised liability regime for authorised push payment (APP) fraud.

Under the PSR:

• Payment service providers must offer payee name verification for credit transfers where the payer provides an IBAN
• If an IBAN-name mismatch is flagged and the payer proceeds anyway after being warned, liability shifts to the payer
• If a PSP fails to implement the check correctly, or fails to warn the customer of a mismatch, the PSP bears liability for the resulting fraud loss

For payment institutions and banks, this requires building or integrating with IBAN verification infrastructure — a significant technical requirement if you're not already offering it. The verification must cover EU cross-border transfers, not just domestic payments, which dramatically increases the complexity.

2. Strong Customer Authentication: Refinements and Exemptions

The PSR retains SCA as a core security requirement but makes targeted changes to the exemption framework that matter operationally:

• Low-value contactless payments: The threshold for SCA-exempt contactless transactions increases from €50 to €150 per transaction, with a cumulative limit of €500 before SCA is required. This is a meaningful change for retailers and acquirers designing checkout flows.
• Trusted beneficiary lists: The PSR formalises and clarifies the trusted beneficiary exemption, allowing payment service users to pre-authorise payees for SCA-free transactions above existing thresholds. The rules for managing, updating, and removing trusted beneficiaries are standardised.
• Transaction risk analysis (TRA): The TRA exemption framework is revised with updated fraud rate thresholds and clearer requirements for what TRA models must assess. PSPs relying on TRA exemptions will need to re-evaluate their models against the new thresholds.
• Open banking SCA delegation: The PSR clarifies that TPPs (third-party payment service providers accessing accounts via open banking APIs) can apply for SCA delegation from the account-holding PSP, enabling smoother user experiences in open banking payment flows.

3. Open Banking: Upgraded Access Rights and API Standards

The open banking provisions in the PSR are a significant strengthening of the PSD2 framework, directly addressing the complaints from fintechs and TPPs about degraded API quality and bank obstruction.

Key changes for open banking compliance:

• Mandatory dedicated interface performance standards: Banks must ensure their open banking APIs meet minimum performance standards — uptime, response time, error rates — that are measurable and enforceable. This is new; PSD2 had no binding performance requirements.
• Fallback interface removal: PSPs that demonstrate their dedicated API meets the performance standards will be exempted from the obligation to maintain a fallback interface (screen scraping fallback). This is a bilateral shift: good APIs get rewards; poor APIs face enhanced oversight.
• Data richness requirements: The PSR requires that open banking APIs provide access to a broader set of account data — including transaction categorisation data where available — than PSD2 required. This directly enables more sophisticated open banking use cases.
• Permission management dashboards: Payment service users must be provided with a dashboard showing all active TPP permissions, with the ability to revoke them individually. Account-holding PSPs must implement these dashboards, creating a new UX and operational requirement.

4. Consumer Protection and Refund Rights

The PSR significantly expands consumer protection for payment fraud, addressing the increasingly sophisticated social engineering attacks that SCA alone cannot prevent:

• APP fraud refund right: Payment service users who are victims of authorised push payment fraud — where they were manipulated into authorising a payment — have a statutory right to a refund from their PSP unless the PSP can demonstrate the user acted with gross negligence or in bad faith. This partially mirrors the UK's mandatory reimbursement regime for APP fraud, which came into force in 2024.
• Fraud liability allocation between PSPs: Where an APP fraud involves the payer's PSP and the payee's PSP, the PSR introduces a framework for liability allocation between them — the payee's PSP bears some responsibility for failing to detect that the payee account is being used for fraud.
• Urgent payment recall: PSPs must have processes to recall or freeze a payment within four hours of the payer's PSP being notified of potential fraud — a tight operational requirement that demands automated processes and defined escalation paths.

For compliance teams, the APP fraud provisions create both a consumer-facing obligation (documenting the refund process) and an operational requirement (fraud detection capable of identifying APP fraud patterns, not just unauthorized transaction patterns).

5. Payment Institution Licensing and EMI Consolidation

PSD3 makes targeted changes to the licensing regime that matter for payment institutions and e-money institutions:

• EMI and PI regimes partially merged: PSD3 brings the e-money institution (EMI) and payment institution (PI) regimes closer together, reducing the regulatory distinction between the two where their activities overlap. Some activities currently requiring an EMI licence may be available under an upgraded PI licence.
• Passporting improvements: The passporting process for payment institutions — which was notoriously slow and inconsistent under PSD2 — is streamlined. Host member state notification periods are shortened, and the information requirements are standardised.
• Capital requirements updated: Initial capital requirements for payment institutions are adjusted, with new categories reflecting the risk profile of different payment service types.
• Non-bank PSP access to central bank infrastructure: PSD3 expands the right of non-bank PSPs to access payment systems and central bank settlement accounts — a longstanding demand from fintech companies who argue the current framework creates competitive disadvantage relative to banks.

PSD3/PSR vs PSD2: What Actually Changes

Area	PSD2	PSR / PSD3
Legal instrument	Directive — required national transposition, significant variation	PSR is a Regulation — directly applicable, no variation
SCA contactless limit	€50 per transaction	€150 per transaction (€500 cumulative)
Open banking API performance	No binding performance standards	Mandatory performance standards, proactive supervision
APP fraud liability	PSP liability only for unauthorized transactions	PSP liability extended to certain authorized fraud scenarios
IBAN-name verification	Not required (some member states implemented voluntarily)	Mandatory for credit transfers across the EU
EMI / PI distinction	Separate regimes with distinct licensing requirements	Partially merged — reduced distinction for overlapping activities
TPP permission dashboards	No requirement	Mandatory consent/permission dashboards for account holders

Who Is Most Affected?

Different types of payment businesses face different priority compliance challenges under PSD3/PSR:

Banks and Account-Holding PSPs

The open banking API performance requirements and mandatory IBAN-name verification are the heaviest new obligations. Both require technical investment, and the performance requirements introduce a new category of supervisory exposure. Banks also face the APP fraud liability framework, which requires enhanced fraud detection and processes for handling refund claims that may be contested.

Payment Institutions and E-Money Institutions

The licensing regime changes under PSD3 require a review of whether existing authorizations remain appropriate, and whether the EMI/PI consolidation creates any opportunities to simplify the regulatory footprint. The APP fraud liability provisions are particularly significant for payment institutions that hold customer funds — the refund obligations can be material.

Third-Party Payment Providers (AISPs and PISPs)

The open banking improvements are an operational benefit for TPPs — better APIs, clearer data access rights, and the SCA delegation framework all reduce friction in the TPP business model. The permission dashboard requirement creates a slight risk of users reviewing and revoking TPP access, which needs to be factored into product design.

Crypto and Fintech Platforms with Payment Licences

Companies that hold payment institution licences alongside crypto/MiCA licences face the intersection of two major regulatory frameworks updating simultaneously. Coordination between the MiCA compliance workstream and the PSD3/PSR workstream is essential — particularly where crypto payment services (stablecoin payments, crypto-to-fiat rails) sit at the intersection of both frameworks.

Building Your PSD3/PSR Compliance Program

A structured approach to PSD3/PSR readiness should work through five areas:

1. Authorisation Review

Map your current PSD2 authorisation(s) against the PSD3 regime. Determine whether any activities require reclassification, whether the EMI/PI consolidation creates simplification opportunities, and whether your passporting structure is still optimal under the revised framework. This is legal work, but it sets the scope for everything else.

2. Operational Gap Analysis

For each major PSR change (IBAN verification, updated SCA exemptions, open banking API standards, APP fraud response processes), assess your current state against the new requirement and identify gaps. Prioritise by implementation lead time — technical builds take longer than policy updates.

3. Fraud Program Enhancement

The APP fraud liability provisions require fraud detection capabilities that go beyond unauthorized transaction monitoring. You need to detect patterns consistent with social engineering-driven authorized fraud — different signals, different models, different response protocols. This is a substantive enhancement to most existing fraud programs, not a minor adjustment.

4. Consumer-Facing Updates

The PSR requires several consumer-facing changes: IBAN-name mismatch warnings, updated payment information disclosures, and refund claim processes. These require coordination between compliance, legal, product, and customer operations teams — and need to be tested with users, not just drafted and published.

5. Regulatory Monitoring

The PSD3/PSR regulatory landscape will generate significant guidance volume for the next three to four years: EBA regulatory technical standards, national competent authority Q&As, ESMA guidance where there is intersection with MiCA, and ECB technical standards for payment system access. A dedicated monitoring workstream for payment services regulation is essential for staying current.

The Interaction with FIDA and the Open Finance Framework

PSD3/PSR doesn't exist in isolation from the rest of the EU's digital finance agenda. The Financial Data Access Regulation (FIDA) — the Commission's proposal for a broader open finance framework covering insurance, investments, and pensions, not just payment accounts — is proceeding on a parallel track. FIDA will eventually extend open banking-style data access rights to a much broader range of financial products.

For payment businesses, the implication is that the open banking infrastructure investments required by PSR are also the foundation for FIDA compliance. Building robust, performant, standards-based open APIs for PSR is the right first step towards the broader open finance obligations FIDA will impose.

Compliance teams with visibility across both PSR and FIDA timelines can plan a single infrastructure program that addresses both, rather than two sequential projects. That requires the regulatory intelligence to track both frameworks simultaneously — a challenge given the volume of Commission, EBA, and Parliament materials being produced across multiple dossiers in parallel.

What Compliance Teams Should Do Right Now

The finalised PSR and PSD3 text provides enough certainty for meaningful compliance planning, even before formal national implementation guidance arrives. Three immediate priorities stand out:

Map the liability exposure from APP fraud provisions. The new refund rights create financial liability that may be material depending on your transaction volumes and customer base. Quantifying this exposure and presenting it to senior management — along with the investment required to reduce it through fraud detection improvements — is both a compliance imperative and a business case.

Assess your open banking API against the proposed performance standards. If you're an account-holding PSP, your API uptime, response times, and error rates are going to be regulatory metrics. Measure them now against the proposed benchmarks and understand where you stand. If there are gaps, the implementation timeline is tight given the technical work required.

Stand up a PSD3/PSR regulatory monitoring process. The EBA will publish dozens of regulatory technical standards, implementing technical standards, and guidelines under the PSR. The Commission will issue delegated acts. National competent authorities will publish transposition guidance, Q&As, and supervisory priorities. Tracking this manually across even a few jurisdictions is a significant undertaking. Automated monitoring of the relevant sources, with alerts routed to the right team members, is the efficient solution.

The EU's payment services framework is being rebuilt from the ground up, and the window between now and the PSR's application date is shorter than it looks. Payment businesses that start preparation work in 2026 will have a materially better compliance experience than those that begin when the application deadline is six months away.