How does PSD3 work?

What PSD3 changes in payments practice

PSD3 is not a clean-slate replacement for payments security. It extends the existing European payments regime by tightening expectations around how payment service providers authenticate users, detect fraud, handle open banking access and assign liability when something goes wrong. The practical effect is that security controls, customer journeys and dispute handling need to align more closely than they did under earlier rules.

For practitioners, the important shift is that PSD3 is best treated as a governance and control uplift across the payment lifecycle, not as a single compliance checkbox. That means reviewing the point where a payment is initiated, the identity or account signals used to approve it, the fraud checks applied in real time and the evidence retained when transactions are challenged.

Because PSD3 builds on an already regulated environment, many organisations will not need to redesign every control from scratch. They will, however, need to prove that existing controls are proportionate to the risk profile of the payment channel, especially where mobile banking, open banking APIs, delegated access or higher-value consumer journeys are involved.

Where PSD3 most affects authentication, fraud control and open banking

PSD3 matters most where a payment journey depends on trust decisions rather than simple transaction processing. Stronger authentication expectations mean teams should examine whether step-up checks, device binding, transaction signing and customer challenge flows are actually reducing account takeover and authorised push payment fraud, rather than just satisfying a policy requirement.

Open banking access is another pressure point. The framework raises the importance of how third parties are admitted, how consent is validated, how access is limited to the intended scope and how failures are investigated. That makes API security, consent governance and access monitoring part of the payments control story, not just a platform concern. For a broader control baseline, many teams map those requirements to NIST SP 800-53 Rev 5 Security and Privacy Controls and to OWASP API Security Top 10 for API authorisation and exposure risk.

Fraud detection under PSD3 is also operational, not theoretical. Organisations need a control model that can spot suspicious payment patterns early, distinguish normal user behaviour from abuse and preserve enough evidence to support liability decisions. That is where payment security increasingly overlaps with identity assurance, transaction telemetry and incident response rather than sitting only inside the fraud team.

How to map PSD3 to your payment journeys

A useful way to implement PSD3 is to trace one payment journey end to end and ask what trust assumption exists at each step. Who is the payer, how was the session established, what signs prove intent, what fraud indicators are available before execution and what happens if the payment is later disputed?

That mapping exercise should also include the surrounding trust relationships. If a journey uses third-party payment initiation, delegated access or open banking aggregation, the question is not just whether the transaction completed, but whether the access path was scoped, monitored and revocable. In practice, this is where teams often discover that policy language is stronger than control evidence. Payment authentication guidance is often aligned with NIST SP 800-63 Digital Identity Guidelines, because assurance level, phishing resistance and authenticators directly affect the payment journey outcome.

When fraud or compromise is suspected, the framework also pushes organisations to think beyond denial of the payment itself. They may need to freeze access, review linked accounts, examine recent authentication events, and determine whether the same trust path can be abused again. That makes evidence retention and customer support processes part of the control design, not a downstream administrative task.

Practitioner Guidance

What to verify: Test whether your strongest authentication and fraud controls are applied at the exact point where payment authority is granted, not only at login. A control that protects access but not transaction approval will usually leave a gap.

What to prioritise: Start with journeys that combine customer authentication, third-party access and high fraud exposure. Those are the places where PSD3 requirements are most likely to change operational behaviour, dispute handling and liability outcomes.

Decision rule: If a payment flow can be initiated through an API, mobile app or delegated access path, treat consent scope, API authorisation and real-time fraud telemetry as one control problem, not three separate ones.

Practitioner takeaway: PSD3 is best implemented as a payment-trust programme, not a legal interpretation exercise. The organisations that struggle are usually the ones that separate authentication, fraud detection and liability evidence into different teams instead of tying them to one payment journey.

Related resources from NHI Mgmt Group

• What is an SVID and how does it work?
• How does OAuth 2.0 work for NHIs and what are its limitations?
• What is identity spoofing in Agentic AI and how does it work?
• When should teams prioritise NHI governance over other IAM work?