What’s new in PSD3 compared to PSD2? 7 changes banks and PSPs should watch

PSD3 is not PSD2 renamed and updated

PSD3 is easy to misread. A strong temptation is to treat it as PSD2 with updates. That would miss the point. PSD3 is more than PSD2 with a new name.

It is true that the agreed PSD3/PSR package keeps the PSD2 foundations, especially around Strong Customer Authentication (SCA). But it pushes much harder on fraud prevention, liability, monitoring, wallet flows, and platform access.

For banks and PSPs, the change is operational as well as legal. The new package says more about what firms must do before a payment is executed, what they must monitor around a payment, and what happens when preventive controls fail.

Table

It also changes what compliance looks like in practice.

Under PSD2, many firms could treat mobile as one channel among several, with the focus falling on authentication rules, open banking access, and back-end controls.
Under PSD3/PSR, that is no longer enough. Institutions will need not only stronger controls, but stronger evidence that those controls worked in the moments that matter. That is especially important on mobile, where customers log in, complete SCA, add payees, enroll wallets, and approve payments, but where many firms still struggle to produce clear evidence of what happened on the device.

That is the real shift behind PSD3/PSR. The package raises the bar on protection. But it also raises the bar on proof.

From PSD2 to PSD3 + PSR

The shift is not only structural. PSD3/PSR brings fraud controls, monitoring, and proof closer to the center of the payment framework. Here is a table that summarizes some of these shifts.

Area	PSD2 emphasis	PSD3/PSR shift
Legal structure	Directive plus RTS	Directive plus directly applicable Regulation
Fraud	Security and authentication focus	Broader anti-fraud framework
Payee checks	Limited and fragmented	More central pre-transfer control
SCA	Core two-factor model	Refined rules and clearer wallet/open-banking treatment
Monitoring	Risk-based logic	More explicit use of session, behavioral, and malware signs
Open banking	Access rights and SCA friction	Smoother AISP access and clearer responsibility split
Mobile access	Indirect issue	More explicit access to mobile-device technical features

Note: this article reflects the agreed PSD3/PSR package as of early May 2026. The package still needs formal adoption by Parliament and Council before it enters into force.[1]

1. PSD2 becomes PSD3 + PSR

Under PSD2, most firms thought in terms of one directive plus a separate RTS layer. The RTS, or Regulatory Technical Standards, set out the detailed technical rules that sat beneath PSD2, especially around strong customer authentication and secure communication. The new package splits the framework into two. PSD3 covers authorization, supervision, and prudential rules for payment and e-money institutions. The PSR carries the conduct rules that shape how payment services work day to day.[2]

It is vital to appreciate that this is more than legal housekeeping. The agreed text says the Union rules on payment services should be “further harmonised.”[2] The point is to move conduct rules into a Regulation that applies directly across member states, while leaving authorization and supervision in the Directive. In practice, that should mean less room for uneven national interpretation than firms saw under PSD2.

That matters for mobile too. When conduct rules become more directly harmonized, it becomes harder to treat mobile controls as local implementation detail or back-office plumbing. The mobile channel sits inside the operating model that firms will need to document, monitor, and defend across markets.

In other words, the shift is not only toward more consistent rules. It is toward more consistent expectations about how those rules are evidenced.

2. Fraud moves closer to the center of the rulebook

PSD2 has already concentrated on security. But fraud sits much closer to the center of the new package. The Council says the agreed rules create a “comprehensive anti-fraud framework.”[3]

This shift shows up in several places. The package addresses spoofing fraud more directly. It strengthens payee checks. It creates a clearer basis for information sharing. And it tightens the consequences when preventive tools are not used properly. The Council’s summary is blunt: payment service providers can be held liable if they fail to meet their obligations when using those tools.[4]

That is a meaningful change from the PSD2 conversation. Under PSD2, many firms treated fraud prevention, reimbursement, and customer experience as linked but separate workstreams. PSD3/PSR ties them together more tightly.

It also makes the protection-and-evidence gap harder to ignore. If liability now turns more directly on whether preventive tools were in place and used properly, then institutions need more than policy language. They need a defensible record of what risks were detected, what warnings or controls were triggered, and what happened in the payment journey. Protection still matters. But proof of protection matters more than before.

3. Verification of payee becomes part of the mainstream payment flow

Verification of payee is one of the clearest examples of change in security focus.

The final compromise text builds on the instant-payments framework and aligns the check across the broader credit-transfer model. It refers to “verifying the match between the unique identifier and the name of the payee.”[5] It also says the payer should receive that notification before authorizing the transaction.[5]

For banks and PSPs, the practical point is that payee verification is no longer a side control that matters only in a narrow set of payment types. It is becoming part of the normal pre-transfer flow. That has product, UX, and fraud implications all at once.

It also has implications for evidence. In a disputed payment, it will matter whether verification of payee was performed, what result was returned, and what the customer was shown before approval. That makes payee verification more than a security gate. It becomes part of the record institutions may need when they assess reimbursement, defend decisions, or answer supervisory questions.

4. SCA is refined, not replaced

One of the easiest mistakes in PSD3 coverage is to suggest that SCA is getting torn up. This is not the case.

The agreed text keeps the same basic model. Strong customer authentication still relies on knowledge, possession, and inherence factors. The text says: “At least two of the elements used need to come from different categories.”[6] That means the headline PSD2 rule survives.

But the edges around SCA do change. This is evident in at least three ways.

The agreed text creates a narrow exception for two inherence elements. It does not open the door to any two factors from the same category.[6]
It says SCA methods should not depend “on the possession of a smartphone or another smart device.”[7]
It clarifies that SCA should apply when a token is created or replaced in a digital wallet, and that recurring merchant-initiated payments do not need SCA again on every later charge once the initial mandate is set up.[8]

That is a more precise, more operational version of SCA than many teams lived with under PSD2. For mobile teams, wallet enrollment, fallback authentication paths, and token lifecycle controls move higher up the agenda.

But the deeper change concerns integrity and evidence. PSD3/PSR keeps SCA grounded in factor choice, but the surrounding fraud and monitoring rules make the session context harder to ignore. For mobile journeys, that means firms should be able to explain not only which factors were used, but whether the app session showed signs of compromise or manipulation.

It needs a credible answer to a harder question: Did SCA happen in a trusted mobile runtime, or only appear to? This is where application shielding becomes relevant, by protecting the app and its authentication logic against runtime manipulation during high-risk moments. And this is where the move from protection to proof becomes real.

Learn more: How Application Shielding supports PSD2 compliance

5. Transaction monitoring becomes more specific

This is an area where the new package gets much more concrete than before.

PSD2 already had a risk-based logic around SCA and exemptions. The agreed PSR goes further by spelling out what transaction monitoring can and should take into account. The final text allows PSPs to use information on the payer, including “environmental and behavioral characteristics” typical of normal use.[9] It also says monitoring must take into account, at a minimum, “signs of malware infection in any sessions of the authentication procedure.”[9]

That is a significant step on from the looser PSD2-era discussion. Device context, session integrity, and behavioral signals move closer to the core control stack.

It is not only about detecting risk. The agreed text also says a PSP may refuse to execute a payment transaction where there are objectively justified reasons to suspect that it “may be fraudulent.”[10] So the package is not asking firms only to collect better signals. It is pushing them toward better decisions based on those signals.

This is one of the clearest places where the mobile protection-and-evidence gap comes into view. Mobile apps are often where these risk signals first appear. But traditional app analytics and back-end logs rarely explain whether the device was compromised, whether runtime interference was present, or whether the session showed signs of manipulation. PSD3/PSR moves transaction monitoring beyond payment history alone. Device state, session integrity, malware indicators, and behavioral context become part of the risk picture.

In practice, this means institutions need both the ability to detect threats in the mobile runtime and the ability to turn those detections into evidence that fraud teams, investigators, and auditors can use.

Relationship of PSD3 to other transaction frameworks

PDS3 pushes mobile security toward a more zero-trust model, where device state, runtime integrity, and session behavior cannot be assumed safe just because the payment request looks valid.

There is also a wider resilience connection here. PSD3/PSR does not sit alone. DORA creates a parallel framework for ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing, while PSD3/PSR adds more explicit payment-layer monitoring and fraud-control duties. For mobile teams, that means the app is increasingly shaped by both payment security requirements and operational resilience expectations.

There is also a useful adjacent point here for card-payment environments. PCI DSS is not part of the PSD3/PSR package, but it reflects a similar reality. Mobile payment security depends on the integrity of the environment the app runs in, not just the validity of the final transaction request. For teams securing card-linked mobile journeys, that makes PCI DSS a relevant parallel control lens alongside PSD3/PSR.

6. Open banking changes again

PSD2 put open banking on the map. PSD3/PSR tries to make it work more smoothly.

The agreed text says the account-servicing PSP should “only apply strong customer authentication for the first access” to payment-account data by a given AISP.[11] After that, the AISP itself must apply SCA when the user accesses account information through it at least every 180 days.[11]

That is more than a friction fix. It changes the operational split of responsibility between the account-holding bank and the third-party provider. For product teams, consent design, re-authentication, and access journeys all need a fresh look.

It also brings clearer accountability into the access flow. If SCA and consent become more explicitly distributed across parties, firms need a cleaner record of who authenticated whom, when that happened, and under what conditions access was granted or refreshed.

In other words, open banking under PSD3/PSR is not only about smoother journeys. It is also about clearer control points and better evidence around those control points.

7. Mobile-device access becomes explicit

This is one of the most interesting shifts for digital payment teams.

The agreed PSR does not only regulate PSP behavior. It also says payment providers must have access to the technical features they need on mobile devices “on fair, reasonable and non-discriminatory terms.”[12]

That matters because it pulls device-level access into the payments rulebook more directly than PSD2 did. In practice, it points to a more open environment for wallets and other payment experiences that rely on secure use of hardware and software features on the phone.

Where PSD3 PSR raises control and evidence requirements

PSD3/PSR raises the bar at each stage of the journey, not only for prevention, but for showing what happened and how risk was handled.

This is easy to read as a platform-access story only. But it is broader than that. As more payment functionality sits closer to the device, the device itself becomes more central to the control framework.

Mobile architecture is no longer a product question only. It becomes part of how firms protect payment journeys and, when needed, explain how those journeys were protected. That is why the evidence point matters here, too. More mobile access creates more room for innovation, but it also creates more pressure to show that those experiences are secure in practice.

PSD3 is broader than PSD2. That is the real change.

The biggest mistake to make is to read PSD3 as an extended PSD2 checklist. But the agreed package is broader than that. It keeps SCA, but wraps it in a more explicit fraud, monitoring, liability, and interoperability model.

Under PSD2, the conversation was often centered on authentication and open banking. Under PSD3/PSR, the standard moves closer to the whole payment journey: who the payee is, what the device is doing, how fraud is monitored, when a transaction should be stopped, and what access payment providers should have to mobile infrastructure.

That is why this change matters for mobile. The app is harder to treat as a thin front end. It is becoming a more visible part of the control framework.

PSD2 was often discussed as an authentication and checkout-friction story. PSD3/PSR does not make mobile the whole story. But the agreed PSD3/PSR package is certainly broader. It is a fraud-control, monitoring, liability, and interoperability story too.

Protection plus proof is the new compliance standard

The most important shift, though, is not any one rule in isolation. It is that compliance moves closer to demonstrable outcomes. Firms will need to show not only that they designed the right controls, but that those controls worked in the moments that mattered. On mobile, that is a big change. The channel is central to authentication and payment initiation, yet often still weakly documented when fraud, disputes, and audits hit.

That is why the protection-plus-proof model matters. Under PSD3/PSR, protecting the mobile journey is necessary. But it is no longer sufficient. Institutions will also need evidence: evidence of device state, evidence of runtime integrity, evidence of what risks were detected, and evidence of how those signals supported decisions.

In practical terms, that is the difference between having mobile security controls and being able to show how they performed. Banks and PSPs should start by mapping their mobile payment journeys against three questions:

What risks can we detect on-device?
What decisions do those signals support?
What evidence can we produce after the event?

Close your mobile app protection-and-evidence gap

Talk to us about assessing where your app is protected, where it's still blind, and how to produce evidence your controls work in practice.

Book a meeting

References

[1] European Parliament Legislative Train Schedule, status note as of 20 April 2026: “The deal needs to be formally adopted by Parliament and Council before it can enter into force.”

[2] Council final compromise text for the PSR, recital on the structural split between conduct rules and authorization/supervision: “further harmonised.”

[3] Council press release on the provisional political agreement, 27 November 2025: “comprehensive anti-fraud framework.”

[4] Council press release on the provisional political agreement, on preventive tools and PSP liability.

[5] Council final compromise text for the PSR, recitals on payee verification and timing before authorization.

[6] Council final compromise text for the PSR, on SCA categories and the limited two-inherence exception: “At least two of the elements used need to come from different categories.”

[7] Council final compromise text for the PSR, accessibility and fallback requirements for SCA methods: “on the possession of a smartphone or another smart device.”

[8] Council final compromise text for the PSR, on token creation/replacement in wallets and merchant-initiated transactions.

[9] Council final compromise text for the PSR, on transaction monitoring inputs and malware indicators.

[10] Council final compromise text for the PSR, on refusing execution where there are objectively justified reasons to suspect fraud.

[11] Council final compromise text for the PSR, on first-access SCA for AISPs and the 180-day rule.

[12] Council final compromise text for the PSR, Article 88a, on access to mobile-device features “on fair, reasonable and non-discriminatory terms.”