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 shift payments security toward stronger identity assurance, fraud prevention and API hardening.

Why it matters: It matters because IAM, fraud, and customer-journey teams will need to align authentication, consent, recovery, and delegated access into one governable model.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

👉 Read Ping Identity's analysis of PSD3 and identity assurance for payments compliance

Context

PSD3 is a payments governance problem as much as a compliance change. The regulation pushes authentication, fraud controls, API security, recovery, and delegated authority into a single identity-centric decision layer, which is why banks and PSPs should treat it as an IAM architecture issue rather than a policy update.

For financial institutions, the practical question is whether current identity stacks can enforce consistent assurance across onboarding, login, payment authorisation, beneficiary changes, device recovery, and third-party access. The article's core argument is that fragmented controls no longer match the regulatory surface.

That makes PSD3 especially relevant to IAM, fraud, and digital payments teams that have spent years separating authentication from authorisation and fraud from identity. Those boundaries now look increasingly artificial in regulated payment flows.

Key questions

Q: How should banks align IAM with PSD3 compliance?

A: Banks should treat IAM as part of the payment control plane, not as a separate access layer. The practical move is to connect authentication, recovery, delegated entitlements, and fraud signals to one policy decision path so every high-risk payment action has consistent assurance and evidence.

Q: Why do legacy MFA and recovery journeys fail under PSD3?

A: They fail because PSD3 is addressing a fraud environment where attackers can socially engineer users, spoof devices, and exploit weak recovery steps. Legacy MFA often proves phishable or easy to bypass, while weak recovery creates a second authentication path that is easier to abuse than the first.

Q: What breaks when open-banking access is not tightly governed?

A: When consent, authentication strength, and API security are managed separately, third-party access can drift beyond its intended scope. That creates inconsistent assurance between direct and delegated journeys, weak auditability, and a higher chance that legitimate-looking access masks an abusive transaction path.

Q: Who is accountable when fraud succeeds during an authorised transaction?

A: Accountability sits with the institution if it cannot demonstrate that adequate controls were operating at the moment of authorisation. Under PSD3, the question is not only whether a fraud occurred, but whether identity assurance, recovery safeguards, and risk controls were strong enough to support the decision.

Technical breakdown

How PSD3 changes the authentication model for payments

PSD3 raises the bar for strong customer authentication by pushing banks and PSPs toward phishing-resistant, risk-aware flows that are harder to replay or manipulate. In practice, that means moving beyond static factors and treating device binding, biometric assurance, and contextual risk as part of the same decision path. The important shift is not just stronger login, but stronger assurance at the moment a payment, recovery step, or entitlement change is authorised.

Practical implication: teams should map every high-risk payment journey to an assurance level and remove any path that still depends on phishable recovery or legacy MFA alone.

Real-time fraud monitoring as an identity control

The article treats fraud monitoring as inseparable from identity because PSD3 expects providers to detect manipulation at the point of authorisation. That means behavioural signals, device integrity, beneficiary changes, and transaction anomalies must feed the same policy engine that governs access. Fraud detection here is not a downstream analytics problem. It is an identity decision problem that must be able to interrupt or escalate a session before value leaves the institution.

Practical implication: connect identity telemetry to transaction policy so suspicious behavior can trigger step-up, warning, or blocking without requiring a separate fraud workflow.

Why open banking now depends on API and consent hardening

PSD3 and PSR1 extend compliance into the API layer by making open-banking access more tightly bound to consent, authentication strength, and response integrity. The article points to FAPI-aligned controls such as mTLS, PAR, signed requests, and OAuth/OIDC hardening because third-party access is only as trustworthy as the protocol boundary around it. This is where identity governance meets API governance: entitlements, tokens, and consent must be auditable and consistent across channels.

Practical implication: review every TPP integration for protocol hardening, consent enforcement, and auditability rather than assuming the current OAuth stack is enough.

NHI Mgmt Group analysis

PSD3 turns identity assurance into the decision layer for payments. The regulation does not merely ask for stronger authentication. It makes identity, fraud, consent, and recovery converge at the moment value is authorised, which means fragmented stacks become a governance problem rather than a tooling inconvenience. Institutions that still separate IAM from fraud operations will struggle to prove control coherence. The practitioner conclusion is that payments security now depends on whether identity policy can govern the full customer journey.

Legacy payment assurance failed because it trusted factors that were easy to manipulate. SMS OTP, weak recovery journeys, and unmonitored device changes were designed for a lower-fraud environment. That assumption fails when industrialised fraud can socially engineer the customer, spoof the device, and manipulate the recovery path before a transaction is ever completed. The implication is that PSD3 is exposing a broken premise in older authentication design, not just a missing control.

Identity-first fraud prevention is becoming a regulatory requirement, not a security preference. PSD3's emphasis on real-time monitoring, beneficiary controls, and transaction-level enforcement reflects a broader shift in financial governance. Fraud teams can no longer operate as a separate alerting layer while IAM handles logins in isolation. The practitioner conclusion is that identity telemetry must now support authorisation decisions in real time.

Open-banking security now depends on entitlement discipline as much as protocol hardening. FAPI, OAuth/OIDC hardening, and signed requests are necessary, but they do not solve over-broad consent or stale delegated access on their own. PSD3 widens the surface where consent becomes an enforcement issue, not just a recordkeeping issue. The practitioner conclusion is that access governance for third-party payment journeys must be auditable end to end.

Converged IAM becomes the control model that PSD3 actually demands. The article is right that onboarding, authentication, risk scoring, entitlement enforcement, and recovery cannot remain in separate operational silos. That is not because convergence is fashionable, but because the regulation assumes continuous trust across the lifecycle. The practitioner conclusion is that architectural consolidation is now part of compliance readiness, not a later optimisation.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
• That gap is why teams should also review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle controls that carry into payments, fraud, and delegated access.

What this signals

Identity convergence is now a payments governance requirement. PSD3 pushes authentication, fraud response, consent enforcement, and recovery into one operating model, which means teams that still split those duties across separate platforms will need to redesign ownership and evidence collection. The practical signal is that programme maturity will be measured by cross-functional coordination, not just by control counts.

Access to payment functions must be treated as lifecycle-governed entitlement, not a static permission. Beneficiary changes, device recovery, and delegated authorities all behave like identity lifecycle events, which means IAM teams need to track them with the same discipline they use for joiner-mover-leaver processes. For a deeper grounding, compare this with the Ultimate Guide to NHIs and the governance patterns that keep entitlements auditable.

If your institution is modernising for PSD3, the forward-looking question is whether identity telemetry can explain every high-risk decision to a supervisor after the fact. That requirement will force better logging, cleaner policy boundaries, and tighter integration between fraud, IAM, and API teams.

For practitioners

• Map PSD3 controls to the full payment journey Inventory every place identity affects payment risk, including onboarding, login, beneficiary changes, device recovery, delegated authority, and payment authorisation. Assign control owners across IAM, fraud, API security, and customer operations so the same journey is governed consistently.
• Retire phishable recovery paths Remove SMS OTP and weak knowledge-based recovery from high-risk payment journeys where stronger assurance is required. Replace them with phishing-resistant, device-bound, and risk-aware recovery patterns that can stand up to account takeover and social engineering.
• Bind fraud signals to authorisation policy Feed behavioural anomalies, device integrity, beneficiary edits, and session context into the same policy engine that approves or blocks payment actions. That allows step-up, warning, or hold decisions before the authorisation is complete.
• Harden third-party payment access Review OAuth/OIDC configurations, consent scopes, request signing, and API security for every TPP integration. Treat delegated access as a governed entitlement with audit evidence, not as a one-time onboarding approval.
• Build a single evidence trail for supervisors Make sure authentication, fraud intervention, recovery, and delegated entitlements all produce logs that can explain why a transaction was permitted or stopped. Regulators will care less about isolated controls than about whether the full decision path is defensible.

Key takeaways

• PSD3 makes identity assurance central to payment authorisation, which pushes IAM out of the background and into regulatory accountability.
• The compliance burden expands beyond login to include fraud monitoring, recovery, delegated access, and API hardening across the full customer journey.
• Institutions that consolidate identity, fraud, and consent controls into one governable model will be better placed to evidence PSD3 readiness.

Key terms

• Strong Customer Authentication: A payment authentication model that requires more than one factor and evaluates risk at the point of access or authorisation. In PSD3 contexts, it increasingly means phishing-resistant, device-bound, and context-aware controls that can stand up to fraud manipulation during high-risk journeys.
• Authorised Push Payment Fraud: Fraud in which the victim is manipulated into approving a payment that appears legitimate at the moment of authorisation. The security challenge is not transaction integrity alone, but whether identity, recovery, and behavioural controls can detect coercion before funds are released.
• 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.
• Recovery Assurance: The set of controls that govern how an identity is re-established after device loss, credential failure, or account challenge. In payment environments, recovery assurance matters because attackers often target the recovery path when primary authentication is too strong to break directly.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Ping Identity: The Road to PSD3/PSR1 Compliance and the Role of Identity. Read the original.