PSD3, the Payment Services Regulation and FiDA: Europe's Payments Overhaul

Three files are rewriting European payments at the same time, and they are frequently discussed as one thing when they are not. PSD3 and the Payment Services Regulation replace PSD2. FiDA extends data access beyond payments into the rest of financial services. They have different scopes, different timetables and different levels of certainty.

If you build payment products, banking integrations, accounting software or anything that consumes open banking APIs, this is the file that will change your architecture most in the second half of the decade.

Where each one stands

PSD3 and the PSR. Council and Parliament reached provisional political agreement on 27 November 2025. This is the furthest advanced. Formal adoption follows, then a transposition and application period. Realistic application is towards the end of the decade.

FiDA. The most troubled file in European financial services legislation. Proposed alongside PSD3 in June 2023, nearly abandoned, then revived. Trilogue negotiations stalled in early 2026 and restarted. Realistic application is phased somewhere between 2027 and 2030 and the final scope is genuinely uncertain.

The split between a Directive and a Regulation matters. PSD3 is a Directive, so member states transpose it and there will be national variation in the licensing and supervision provisions. The PSR is a Regulation, so it applies directly and uniformly. Conduct rules, fraud provisions and open banking requirements sit mostly in the Regulation, which is good news for anyone who suffered through 27 national implementations of PSD2.

What PSD3 and the PSR change

Fraud liability moves

The headline change. PSD2 allocated liability for unauthorised transactions but left authorised push payment fraud, where the victim is tricked into making the payment themselves, largely with the victim.

The new framework extends liability in specific circumstances, notably impersonation fraud where a fraudster convincingly poses as the bank or another trusted party. Payment service providers become liable in defined cases.

What that means in engineering terms: fraud detection stops being a cost centre that protects your own losses and becomes a direct liability control. The economics of investing in detection change substantially when you carry the loss.

Strong customer authentication changes

SCA has been in force since 2019 and has generated a large volume of friction, exemptions and workarounds. The new framework adjusts the regime: clarified exemption handling, obligations around accessibility of authentication for users who cannot use a smartphone, and provisions aimed at the transaction risk analysis exemption.

What that means: if you built an SCA implementation in 2019 and have not revisited it, expect a rework. Accessibility of authentication in particular is a real requirement that intersects with the European Accessibility Act.

IBAN and name matching extends

The Verification of Payee obligation that arrived with the Instant Payments Regulation in October 2025 is extended and generalised in the new framework, covering more payment types rather than only euro credit transfers.

What that means: the four-result handling you built for instant payments becomes the general pattern rather than a special case.

Open banking API performance becomes enforceable

PSD2 required banks to provide access interfaces. It did not effectively require those interfaces to be good. The result was years of third party providers complaining about downtime, inconsistent data, aggressive re-authentication requirements and dedicated interfaces that performed worse than the customer-facing channel.

The PSR addresses this with performance requirements, a prohibition on obstacles, and a removal of the fallback interface obligation in exchange for genuine dedicated interface quality standards.

What that means: if you consume open banking APIs, the reliability floor rises. If you provide them, the compliance bar moves from existence to performance.

Payment institution and e-money institution regimes merge

Two licence categories become one. For most firms this simplifies things. For firms holding both, or firms whose business model sat carefully on one side of the line, there is transition work.

What FiDA would change

FiDA is the more architecturally significant file if it lands as proposed, because it extends the open banking model to the rest of financial services.

Currently, regulated data access covers payment accounts. FiDA would extend it to savings and investment accounts, pensions, mortgages, non-life insurance and more, creating a new regulated category of financial information service provider.

The mechanism differs from PSD2 in an important way. PSD2 mandated access. FiDA is built around financial data sharing schemes: market-driven arrangements between data holders and data users that set the technical standards and the compensation model. Data holders would be able to charge data users, unlike under PSD2 where access is free.

Why that matters: it addresses the main complaint from banks about PSD2, which is that they were required to build and maintain interfaces from which others profited without contributing. It also means the commercial terms are negotiated rather than legislated, which introduces its own uncertainty.

Why it has struggled: the scope is enormous, the compensation model is contested, the insurance sector pushed back hard on inclusion, and the value case is less obvious than payments. It was very nearly withdrawn.

What this means if you build financial software

If you consume open banking APIs

Life improves, slowly. Performance obligations, an obstacle prohibition and clearer re-authentication rules address the operational complaints that have made open banking aggregation painful. Expect the improvement to arrive unevenly by bank.

If FiDA lands, the addressable data set expands enormously, but you should expect to pay for access and to join a scheme rather than relying on a regulatory right.

If you provide payment services

The fraud liability change is the one to plan for. Model your exposure under the new allocation before it applies, because the answer determines how much detection investment is justified.

Authentication needs revisiting for both the exemption changes and accessibility. The name-matching extension needs the same four-state handling as instant payments.

If you build accounting, treasury or ERP integrations

You are downstream of all of this. The practical effect is that the data you can pull becomes broader and more reliable, and the authentication dance becomes more standardised. The main risk is building against current bank-specific quirks that the new performance rules will remove.

If you build e-commerce checkout

Less direct impact than you might expect. The changes that reach you are the authentication adjustments, and the general direction towards account-to-account payments that Wero and the digital euro also represent.

The architectural point worth making

All three files, plus the Instant Payments Regulation, plus Wero, plus the digital euro, plus the EU Digital Identity Wallet, point the same direction: payments and financial data in Europe are moving towards account-to-account rails, verified identity at infrastructure level, standardised interfaces, and regulated pricing.

The architectural implication is consistent across all of them. Systems that treat a payment method, a data source or an authentication mechanism as a plug-in absorb this cheaply. Systems where the specifics are woven through the codebase pay for each change separately.

If you take one thing from this: the abstraction work is the same abstraction work for every one of these files. Doing it once for Wero pays for it, and everything after that is close to free.

Timing, honestly

PSD3 and the PSR have political agreement, which means the substance is largely settled. Application is still years out, and the technical standards that determine what you actually build will follow adoption. Building now would be premature. Knowing the direction is not.

FiDA is genuinely uncertain. It could arrive with a broad scope, arrive narrowed substantially, or not arrive. Building against it would be unwise. Designing your data model so that adding a new financial data source is a configuration change rather than a project is wise regardless.

Where this fits

The full legislative queue is in our EU digital law pipeline. The payments rules that already apply are covered in our instant payments and Verification of Payee guide, and the wider compliance surface in our 2026 EU digital compliance guide.

Getting help

We build payment integrations, banking connectivity and financial systems for companies operating across Europe, including open banking aggregation, reconciliation and the state machine work that determines whether payment flows are reliable.

If your payment layer needs the abstraction work that all of this rewards, or you want a view on fraud liability exposure under the new allocation, write to office@c9group.dev. More about our European work on the EU market entry page.

We are engineers rather than regulatory advisers. Licensing questions and liability positions belong with your counsel.