PSD3 compliance turns identity into a payments control plane

At a glance

What this is: This is Ping Identity’s analysis of how PSD3 and PSR1 expand payments compliance into identity assurance, fraud controls, API security, recovery, and delegated entitlements.

Why it matters: It matters because banks and PSPs will need identity, authentication, fraud, and authorisation decisions to work as one control plane rather than separate compliance functions.

Context

PSD3 and PSR1 shift payments compliance from a narrow authentication question to a broader governance problem: how institutions prove trust at the point of authorisation, recovery, delegation, and API interaction. In practice, that means identity security, fraud controls, and payment policy can no longer be designed as separate programmes.

For banks, PSPs, EMIs, AISPs, and PISPs, the change is operational as much as regulatory. Legacy MFA, fragmented onboarding, weak recovery journeys, and inconsistent open-banking controls all become compliance liabilities when authorisation must be defensible in real time.

Key questions

Q: How should financial institutions prepare for PSD3 changes to fraud controls and payment authentication?

A: Financial institutions should treat PSD3 as a governance and controls upgrade, not just a legal update. The practical response is to review payment fraud workflows, strengthen authentication requirements, verify payee details for credit transfers, and expand information sharing with trusted counterparties. Teams should also map customer impact, refund handling, and operational change windows so compliance work reduces fraud without disrupting payment flows.

Q: Why do weak recovery journeys create PSD3 compliance risk?

A: Weak recovery journeys create PSD3 compliance risk because attackers often exploit reset, device-change, or support flows after the initial login has been secured. If recovery can weaken identity assurance more easily than payment initiation can strengthen it, the institution loses control at the exact point regulators expect proof of customer intent.

Q: What breaks when delegated entitlements are not governed like payment controls?

A: When delegated entitlements are not governed like payment controls, organisations can allow a trusted customer session to expand into actions the original assurance level never justified. That breaks the link between identity confidence and authorisation, which means limits, payees, and third-party access can be abused without the policy layer catching the mismatch.

Q: What is the difference between SCA and identity assurance in PSD3?

A: SCA proves a transaction met a minimum authentication requirement, while identity assurance proves the institution can trust the person, device, and context behind the decision. PSD3 depends on both, but the article shows that assurance is the broader control plane because it governs recovery, delegation, fraud detection, and API access as well as sign-in.

Technical breakdown

Why PSD3 makes identity the transaction decision layer

PSD3 widens the compliance boundary around payments by treating identity assurance as part of the authorisation decision, not just the login step. That matters because fraud, delegated access, beneficiary changes, recovery, and device trust all influence whether a payment should proceed. The article’s core point is that identity signals now inform whether the transaction itself is legitimate, which pushes IAM into the control path used by payments and fraud teams alike.

Practical implication: Practitioners need a governance model where identity confidence is evaluated at authorisation time, not only at enrolment or sign-in.

How stronger SCA changes recovery, delegation, and payee controls

The article shows that PSD3’s stronger SCA expectations reach beyond primary authentication into recovery journeys, delegated entitlements, payee setup, and spending-limit changes. This matters because the weak point in many payment flows is not the initial login, but the actions surrounding account recovery and permission expansion. If those steps are easier to manipulate than the payment itself, the control boundary has already failed. PSD3 therefore makes entitlement governance part of the security perimeter.

Practical implication: Treat recovery, delegated permissions, and beneficiary management as privileged payment actions that require the same assurance level as a high-risk transfer.

Why API hardening becomes a compliance issue, not just a security issue

The article ties PSD3 and PSR1 to FAPI-aligned OAuth and OIDC hardening, signed requests, mTLS, and consistent assurance across direct and third-party journeys. That is a governance shift as much as a technical one: open-banking APIs are no longer merely integration points, they are regulated trust channels. When TPP and direct-bank paths produce different assurance levels, the institution cannot claim consistent control over access, consent, or authorisation.

Practical implication: Align API authentication, consent enforcement, and access policy so that third-party access inherits the same assurance expectations as bank-direct flows.

Threat narrative

Attacker objective: The objective is to authorise fraudulent payments or expand access through manipulated identity and entitlement controls while appearing compliant at the transaction boundary.

1. Entry begins when attackers abuse weak recovery, phishable SCA, or inconsistent third-party journeys to gain a trusted foothold in the payments flow.
2. Credential or entitlement abuse follows when the actor manipulates delegated access, device changes, or beneficiary settings to create a valid-looking authorisation path.
3. Impact occurs when the institution cannot distinguish legitimate customer intent from industrialised fraud at the point of payment or recovery.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PSD3 turns payments identity into a control plane, not a point control. The article shows that authentication, fraud detection, recovery, and entitlement enforcement now converge at the moment of authorisation. That changes the governance model because a payment decision can no longer be separated from identity confidence, device context, and delegated authority. Banks that still treat these as disconnected stacks will struggle to prove control consistency across the transaction lifecycle.

Recovery assurance is the underappreciated compliance boundary. PSD3’s emphasis on fraud prevention makes recovery flows as sensitive as primary authentication, because attackers often move through reset and device-change journeys rather than the login screen itself. This exposes a governance gap in programmes that secure SCA while leaving account recovery loosely controlled. The practical conclusion is that recovery has become part of the payment trust model, not a support function.

Identity assurance has become the proof mechanism for authorisation. The regulation’s expanded focus on delegated entitlements, payee controls, and real-time fraud monitoring means institutions must justify not only who authenticated, but whether the identity context at that moment supported the transaction. That is a deeper requirement than classic MFA. The implication for practitioners is that assurance evidence, policy enforcement, and payment authorisation need one operating model.

Converged IAM is now a regulatory architecture choice, not a platform preference. The article’s thesis is that fragmented onboarding, fraud, API, and authentication stacks cannot sustain continuous and explainable trust at scale. PSD3 rewards organisations that can apply one identity model across login, recovery, consent, and payment policy. Practitioners should re-evaluate whether their current identity programme can actually produce regulator-grade assurance across the whole customer journey.

PSD3 is forcing payment security to look more like identity governance. As rules extend into limits, payees, delegated authorities, and cross-channel assurance, the control set becomes closer to lifecycle and entitlement governance than to traditional checkout security. That makes IAM, fraud, and compliance owners jointly accountable for the same decision path. Teams should stop treating payments as a separate domain and govern it as a high-risk identity workflow.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• Read next: Identity Provider and SSO Security Guide

What this signals

Identity assurance is becoming the regulatory boundary around payments. PSD3 pushes banks to prove that authentication, recovery, delegated access, and fraud response all support the same authorisation decision. The programme implication is straightforward: if those controls live in separate governance tracks, the institution will struggle to explain why a transaction was allowed.

Recovery and entitlement governance now sit inside the payment trust model. That shifts priority away from isolated MFA tuning and toward end-to-end control of reset flows, device trust, and delegated permissions. Practitioners should expect auditors and regulators to test whether these paths preserve the same assurance standard as primary sign-in.

Frictionless payments will depend on policy convergence, not weaker controls. Institutions that unify fraud signals with identity policy can step up only where the risk justifies it, rather than forcing blanket friction across every journey. That creates a better operating model for both compliance and customer experience.

For practitioners

• Map the full payment trust path Trace where identity confidence is created, consumed, and lost across login, recovery, payee management, delegated access, and payment authorisation. Replace siloed reviews with one control map that shows which step proves customer intent and which step merely inherits it.
• Harden recovery and device-change journeys Treat reset, device enrolment, and account recovery as high-risk actions requiring stronger evidence than ordinary sign-in. Review where legacy support flows still allow impersonation, social engineering, or silent trust resets to bypass the intended SCA posture.
• Unify fraud and IAM policy decisions Ensure fraud signals, identity proofing, delegated permissions, and step-up rules are evaluated by the same policy layer so that transaction decisions do not diverge across channels. The goal is consistent enforcement, not separate approvals from separate tools.
• Reassess third-party access assumptions Audit how TPP access, consent, and OAuth/OIDC hardening are governed so that external journeys do not operate with a lower assurance bar than bank-direct flows. A compliant API posture has to include authentication strength, consent scope, and revocation discipline.
• Prepare for the 2026 to 2027 architecture window Use the next planning cycle to decide whether current identity architecture can support stronger SCA, real-time fraud monitoring, delegated controls, and auditability at scale. If not, the remediation programme needs to be prioritised before regulatory deadlines compress delivery time.

Key takeaways

• PSD3 and PSR1 broaden payments compliance into identity, fraud, recovery, and delegated access decisions, so banks can no longer treat authentication as a standalone control.
• The article frames 2026 to 2027 as the critical architecture window, which means institutions need to decide now whether their current IAM and fraud stack can support regulator-grade assurance.
• The biggest implementation risk is fragmented governance, because weak recovery flows, inconsistent API controls, and disconnected entitlement policy all weaken the same payment trust chain.

Key terms

• Identity Assurance: The confidence an organisation has that a person or system is truly who it claims to be before access or action is granted. In modern IAM, assurance depends on evidence quality, channel trust, and the strength of verification around high-risk decisions.
• Delegated Entitlement: A permission that allows a third party, user, or service to act within a defined payment scope on behalf of the primary account holder. These entitlements must be lifecycle-governed, auditable, and tightly bounded so they do not become durable access paths for abuse.
• Strong Customer Authentication: A regulated authentication requirement that demands more than a single password or code. Under PSD2, it requires at least two factor types and must support the payment context, so the approval is tied to the specific transaction rather than a reusable login event.
• Wallet Trust Chain: The set of linked controls that make a digital wallet usable and trusted, including authentication, credential decryption, presentation signing, verifier validation, and recovery. If any link is weak, the wallet can fail even when the passkey is technically sound.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.