PSD2 focused heavily on account takeover prevention through strong customer authentication, while the proposed PSD3 and PSR framework shifts attention toward authorised push payment fraud. That is a meaningful change in control strategy. The new proposal keeps SCA but adds stronger expectations for accessibility, liability allocation, fraud detection, information sharing, and practical intervention before a fraudulent transfer completes.
How PSD2 and PSD3 differ in what they are trying to stop
PSD2 was built around preventing unauthorised account access, so the operational centre of gravity was PCI DSS v4.0-style strong authentication and payment security controls: prove the payer is really the payer, then reduce the chance of account takeover. PSD3 keeps that foundation, but the fraud problem is broader. Its proposed focus reaches beyond unauthorised login into the transaction itself, especially cases where the customer is tricked into authorising a payment that should never have gone out.
That shift matters because the control objective changes. Under PSD2, the question is often “can an attacker get in?” Under PSD3, the harder question is “can the payment be intercepted, challenged, or stopped before a legitimate-looking transfer completes?” That moves attention toward payment flow monitoring, beneficiary risk, and faster intervention, not just authentication at sign-in.
One useful way to think about the difference is that PSD2 is primarily identity and access oriented at the account boundary, while PSD3 is more transaction and fraud oriented at the payment boundary. In practice, that means the newer approach is less satisfied with a control that only blocks unauthorised access and more interested in controls that detect manipulation, abnormal payment patterns, or social-engineering driven transfers in time to matter.
What PSD3 adds around detection, liability, and intervention
The proposed PSD3 and PSR package keeps strong customer authentication, but it also pushes firms toward broader fraud defences: better detection, more information sharing, clearer liability allocation, and more practical intervention paths before funds are irreversibly moved. That makes payment security less of a single-control problem and more of an end-to-end operating model.
For payment providers, the important change is not only technical. They may need to prove that fraud signals are actually monitored, that intervention rules are usable in live payment flows, and that customer accessibility does not weaken security outcomes. The proposal therefore raises the bar on operational readiness, not just on one-time authentication strength.
Where PSD2 often rewarded compliance with a well-implemented authentication step, PSD3 is trying to improve real-world fraud outcomes. That is why the proposed model gives more weight to early warning indicators, beneficiary verification, mule-account patterns, and account-to-account scam handling. If a payment looks authorised but is still fraudulent, the relevant control is no longer only access control, it is fraud prevention and containment.
Practitioner implications for banks, PSPs, and security teams
For practitioners, the main takeaway is to stop treating PSD3 as a simple PSD2 refresh. The control design problem is moving from “authenticate the payer” to “understand the payment journey well enough to disrupt a fraudulent transfer before completion.” That affects fraud operations, customer journeys, dispute handling, and the evidence you need for accountability.
What to verify: Check whether your current controls can distinguish a normal authorised payment from a socially engineered one quickly enough to intervene. If you only measure authentication success, you are probably missing the new failure mode.
What to prioritise: Focus on controls that combine authentication, behavioural detection, payment monitoring, and response orchestration. That is where the proposed regime is headed, and it is where most false confidence arises if teams assume strong authentication alone is sufficient.
Practitioner takeaway: PSD2 was mainly about preventing the wrong person from entering the account; PSD3 is increasingly about preventing the wrong payment from completing, even when the customer appears to have authorised it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 7 — Restrict Access by Business Need to Know | Payment fraud control depends on limiting access paths and reducing account abuse risk. |
| 8.6 — System and Application Accounts and Authentication | PSD2-era strong authentication is directly aligned to account access protection. | |
| Recommendation — Apply least-privilege access to payment and fraud systems. Harden authentication for accounts that can initiate or approve payments. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | The PSD2 side of the comparison is anchored in access control and authentication. |
| DE.CM — Continuous Monitoring | PSD3's fraud-detection emphasis depends on continuous monitoring for anomalous payment activity. | |
| RS.MI — Mitigation | PSD3 expects practical intervention to stop fraudulent transfers before completion. | |
| Recommendation — Enforce strong authentication and access controls at payment entry points. Monitor payment flows continuously for suspicious patterns and scam indicators. Build response playbooks that can interrupt suspect payments quickly. | ||
Related resources from NHI Mgmt Group
- What does the difference between payment verification and fraud prevention mean in practice?
- What is the difference between payment fraud attack rate and fraudulent chargeback rate?
- What is the difference between payment fraud and transaction fraud?
- What is the difference between chargeback fraud and account takeover in online payment fraud?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
