PSD2 is being replaced by a two-part package: PSD3, a directive covering authorisation and supervision, and the Payment Services Regulation, a directly applicable regulation carrying the conduct rules. The final compromise texts were published in April 2026. Neither is adopted or in force yet, and most obligations land around 2028.
If you sell software to customers in the EU, the framework you are building against is on its way out. Knowing what replaces it, and when, tells you which of today's design decisions are likely to still hold in three years.
Most of the package lands on banks and other payment service providers rather than on SaaS companies directly. That does not make it irrelevant. It shapes what your payment provider will be able to do, what it will be obliged to do, and where the compliance surface sits when it changes.
Where the package currently stands
The European Commission proposed PSD3 and the Payment Services Regulation on 28 June 2023. The package is no longer a proposal in any meaningful sense. Parliament and the Council reached provisional political agreement on 27 November 2025, and the Council published the final compromise texts on 23 April 2026.
Formal adoption by both institutions, signature and publication in the Official Journal still remain before the package enters into force. Entry into force follows twenty days after publication.
The final compromise texts put the main application clock at 21 months from entry into force, which places real obligations around 2028 rather than 2027. Analyses written before those texts were published read the clock as 18 months, so check the date on any figure you encounter. Until adoption completes, PSD2 and its technical standards remain the operative framework, and nothing in the new package creates a present obligation.
Why the architecture changed
PSD2 was a single directive bundling conduct rules with licensing rules. Member states transposed it into national law with considerable latitude, which produced divergence in how the same rules were applied across the single market.
The new package splits the two. The PSR is a directly applicable regulation carrying the Strong Customer Authentication, open banking and fraud rules, so those apply identically across member states without transposition. PSD3 is a directive covering authorisation and supervision, where national implementation still makes sense.
For a SaaS company the practical effect is that the conduct rules governing how your payments are authenticated should become more consistent across countries.
A sector-specific route for special category payment data
PSR Article 80 authorises payment service providers to process special categories of personal data under GDPR Article 9 where necessary to meet obligations under that article. Where it applies, providers must put technical and organisational safeguards in place, including limits on data re-use, pseudonymisation or encryption, restricted internal access, and access logging.
This closes a real gap. Payment data can incidentally reveal special category information through aggregation, and until now providers had to lean on an impractical explicit consent mechanism for processing that was structurally unavoidable. The provision is in the agreed text rather than a maybe.
This is the piece of the package to track if you sell through an MoR or a payment processor, because it changes how the layer beneath you can handle incidental special category data, and that flows down to you.
Open banking interface performance
The PSR requires account-servicing payment service providers, usually banks, to provide a data access interface for third-party providers that performs at least as well as their own app or website, measured against harmonised KPIs to be set by EBA technical standards.
The existing fallback-interface obligation goes away. A narrower exemption from the dedicated-interface requirement remains: a national competent authority can, on request, allow an account provider not to maintain a dedicated interface where the applicable conditions are met. Depending on the case, access can instead be provided through the customer interface where that interface supports the required machine-to-machine access, or the provider may be exempted from providing an open-banking interface. The detailed criteria will be set through EBA technical standards.
The consequence for anyone building on open banking is more reliable access rather than reliance on a standing fallback mechanism. That raises rather than lowers the importance of GDPR data minimisation obligations. If you are designing account access features now, build Article 5 minimisation in from the start rather than retrofitting it when the volume arrives.
Fraud and verification of payee
The package puts substantial weight on fraud prevention, including strengthened transaction monitoring and verification of payee requirements that match the payee name against the account identifier. Verification of payee is split between two regimes.
Euro credit transfers are already covered by the Instant Payments Regulation, which introduced verification of payee into the SEPA framework. Euro-area providers have been subject to the relevant verification requirement since October 2025, with providers in non-euro member states following on the later timetable set by that regulation.
The PSR does not duplicate those rules. Its verification service applies to credit transfers that are not already covered by the Instant Payments Regulation and aligns the remaining payment flows with the same basic approach. The PSR provisions run on a 27-month clock from entry into force.
For a SaaS company accepting euro SEPA transfers, the relevant verification framework is therefore already the Instant Payments Regulation rather than a future PSR requirement. The PSR matters primarily for credit transfers outside the scope of that regime.
FIDA, and why it is not a companion file
The Financial Data Access Regulation, proposed alongside PSD3, would extend open banking logic to investments, insurance, pensions and credit data under a new licensed financial information service provider category.
It has not kept pace. Trilogue negotiations stalled after June 2025, a Commission non-paper circulated by the Council presidency in April 2026 set out options for restarting them, and the file remains open with gatekeeper access to customer data and the data holder compensation mechanism contested.
Treat its timeline as uncertain rather than as something that lands with PSD3. Adoption timelines circulating for FIDA range from 2027 through 2030 depending on when negotiations conclude, and a narrowing of scope remains on the table.
What to do about it now
One structural point deserves naming first. The obligations in this package land on different parts of the regulated payments stack.
PSD3 re-authorisation affects existing payment institutions and electronic money institutions. Open-banking interface performance obligations fall on account-servicing payment service providers such as banks. Article 80 safeguards, fraud monitoring and authentication requirements apply to the relevant payment service providers involved in each payment flow.
If you hold your own payment relationships, changes at those providers can surface in your integration whenever they adjust authentication, fraud or payment flows to comply with the new rules. If you sell through a Merchant of Record, the regulated payment providers sit further below your application layer and much of that churn never reaches your codebase. Paddle, Lemon Squeezy, Polar, Dodo Payments and tiun all work this way.
Insulation from regulatory churn in the payment layer is the part of the MoR argument that survives contact with a package like this one. It also says nothing about tax, licensing, or exactly which payment service provider carries a particular SCA obligation, which are separate questions to ask separately.
Beyond that, very little here creates work for a SaaS company today, and treating it as a roadmap commitment would be a mistake. Three things are worth doing.
Keep building against PSD2. It is the operative framework and will remain so until the new package applies. Many of the core SCA concepts, including authentication factors and dynamic linking, carry forward, but the final Level 1 text already introduces some concrete requirements that implementations will need to account for.
In particular, the PSR confirms that adding a payment instrument such as a card to a digital wallet requires Strong Customer Authentication, and it requires authentication methods that do not depend on the customer owning a smartphone or another smart device. The detailed technical implementation will depend on the Level 2 standards that follow.
Design open banking features for minimisation from the start, because the direction of travel is toward more data moving more reliably, and retrofitting minimisation onto a system built without it is expensive.
Ask your payment provider how it is preparing, particularly on Article 80, fraud monitoring and the forthcoming SCA technical standards. Those obligations sit primarily within the regulated payment layer rather than on an ordinary SaaS merchant, but changes there can still affect your checkout and payment flows.
Frequently asked questions
Do we need to change our SCA implementation before PSD3 applies?
Not solely because PSD3 and the PSR are coming. PSD2 and Commission Delegated Regulation (EU) 2018/389 remain the operative framework until the new package applies, which the final compromise texts put at roughly 21 months after entry into force.
The PSR carries Strong Customer Authentication forward as directly applicable law, and some Level 1 requirements are already clear. For example, adding a payment instrument such as a card to a digital wallet requires SCA, and payment service providers must support authentication approaches that do not depend on the payer having a smartphone or another smart device.
What remains unsettled is much of the Level 2 technical detail. The EBA standards will determine how a number of requirements are implemented in practice. For now, build against the current PSD2 framework and keep the implementation adaptable enough to accommodate the final technical standards when they land.
Will PSD3 make our Merchant of Record a licensed payment institution?
No. PSD3 reorganises who needs a licence and what that licence covers, but it does not confer one on anybody. One significant structural change is that electronic money institutions move into the payment-institution framework, replacing the current separate E-Money Directive authorisation regime.
Existing payment institutions and electronic money institutions can continue operating for up to 27 months after PSD3 enters into force, provided they give their competent authority the information needed to assess whether they comply with the new requirements. Institutions that demonstrate compliance are deemed authorised under PSD3. Those that have not demonstrated compliance by the end of the transition can have their authorisation suspended until they do.
That transition therefore runs about six months beyond the main 21-month application date. If your MoR does not itself hold a payment licence today, it will not automatically receive one because of PSD3. Authentication, fraud and other regulated payment obligations sit with the relevant payment service providers behind the MoR, including the issuer and acquirer where applicable.
Ask which entities in the payment chain hold the relevant licences and responsibilities, and get the answer in writing.
Does PSR Article 80 let us process special category payment data?
Only if you are a payment service provider. Article 80 authorises PSPs to process special categories of personal data under GDPR Article 9 where necessary to meet obligations under that article, subject to safeguards including limits on data re-use, pseudonymisation or encryption, restricted internal access, and access logging. A SaaS company selling through a payment provider is not a PSP and gains no route through this provision.
Your own position under Article 9 is unchanged. Where aggregated payment history can reasonably infer special category information, the Article 9 conditions still apply, and explicit consent under Article 9(2)(a) remains the realistic basis for anything you build yourself. What changes is what the regulated payment layer beneath you can lawfully do, which is worth knowing and is not a permission you inherit.
When does verification of payee actually start affecting us?
For most SaaS companies taking card payments, it does not. Verification of payee matches the payee name against the account identifier on credit transfers, so it affects bank transfer flows rather than card checkout.
Two instruments cover different parts of the market. For euro credit transfers, including SEPA euro transfers, verification of payee is already governed by the Instant Payments Regulation. Euro-area providers have been subject to the relevant requirement since October 2025, while providers in non-euro member states follow the later timetable set by that regulation.
The PSR applies its verification service to credit transfers that are not already covered by the Instant Payments Regulation. Its relevant provisions apply 27 months after entry into force.
So if you offer SEPA euro transfers, this is not something you need to wait for PSD3 or the PSR to introduce. The more relevant question for the new PSR regime is how your provider will handle credit transfers outside the euro-transfer framework already covered by the Instant Payments Regulation.
Where tiun fits
tiun is a Merchant of Record with the backend attached: authentication, payments, billing and customer records in one system, hosted in Europe. As legal seller it carries the sales tax registration and remittance.
tiun is not itself a payment institution, so regulated payment obligations under PSD2 today, and the corresponding PSD3 and PSR obligations once the new framework applies, sit with the relevant payment service providers in the payment chain. tiun's payment processor is currently Stripe.
The data protection addendum is at legal.tiun.io. The SDK and server-side entitlement checks are documented at docs.tiun.io, and you can be live in a day.