PSD3 and PSR turn payment authentication into a trust stack

At a glance

What this is: This is an analysis of how PSD3 and PSR change payment authentication, fraud liability, and identity infrastructure across European financial services.

Why it matters: It matters because payment teams, IAM architects, and trust service providers will need to align authentication, delegated access, and digital identity controls before enforcement begins.

Context

PSD3 and the Payment Services Regulation are not simply updates to PSD2. They tighten the rules around strong customer authentication, fraud liability, open banking, and identity-backed payment authorisation, which means payment security can no longer be treated as a separate control layer from identity governance.

The deeper shift is that the regulatory model is converging around one trust infrastructure for payments, digital identity, and regulated signing. That makes authentication design, delegated authority, and evidence retention part of the same governance problem rather than separate programme tracks.

Key questions

Q: What breaks when banks rely on SMS OTP as the only transaction authentication method?

A: Banks expose themselves to account takeover and transaction fraud because a stolen or relayed OTP proves only that a code was received, not that the session, device, or transaction is trustworthy. Once the attacker controls the channel or the user is socially engineered, the code becomes a weak hurdle rather than a real assurance step.

Q: Why does delegated authority create more risk than simple authentication?

A: Authentication proves a subject presented a valid credential. Delegated authority proves that the subject was allowed to act for someone else, in a specific context, at a specific moment. That extra layer is where policy can fail, especially when software intermediaries or AI agents act on behalf of humans without clear authority tracing.

Q: How should payment teams prepare for EUDI Wallet acceptance under PSD3 and PSR?

A: They should treat wallet acceptance as an identity architecture change, not a feature toggle. The goal is to align wallet credentials, assurance levels, and transaction flows so the same trust layer can support authentication, KYC, and signing without duplicated controls or inconsistent assurance decisions.

Q: What control evidence do auditors and regulators need when SCA fails?

A: They need proof that the right authentication method was applied, that it was bound to the transaction, and that the evidence was retained in a tamper-resistant form. Transaction logs alone are not enough if they cannot show who authenticated, how they authenticated, and what was signed or authorised.

Technical breakdown

Why SMS-based SCA no longer holds up

Strong Customer Authentication under PSD3 and PSR still uses the two-factor model of knowledge, possession, and inherence, but it raises the quality bar for each factor. SMS one-time passwords failed because the possession factor was easy to intercept through SIM swap, social engineering, and malware. In practice, that means the issue is not whether a second factor exists, but whether the factor is resistant to modern fraud paths and can stand up to transaction-level risk. Practical implication: treat OTP delivery as a legacy control pattern, not a compliant end state. See the Passwordless and Passkeys Guide.

Practical implication: Retire SMS as a primary SCA method for higher-risk journeys and move toward phishing-resistant authentication.

How delegated authentication changes the liability chain

PSD3 and PSR allow delegated authentication, but they do not transfer accountability away from the payment service provider. Delegation is treated as outsourcing, which brings outsourcing governance and ICT risk expectations into scope while keeping the originating PSP liable for SCA failures. That matters because payment authentication is no longer just about who performs the check, but who owns the outcome when the check fails. Practical implication: map every delegated authentication path to an accountable control owner and evidence chain. See the IAM and Identity Provider Buyer's Guide.

Practical implication: Document delegated SCA as an outsourced control with clear liability, oversight, and audit evidence.

Why the EUDI Wallet becomes part of payment authentication architecture

The EUDI Wallet is becoming a first-class SCA instrument because the regulatory model is aligning identity proofing, authentication, and attribute disclosure in one credential flow. Wallet-based credentials can satisfy possession and inherence requirements while reducing unnecessary data exposure through selective disclosure. For PSPs, that means the payment layer starts to depend on wallet infrastructure, trust service providers, and interoperability with identity assurance standards. Practical implication: design payment authentication so wallet credentials can be accepted without creating a parallel identity stack. See the Digital Identity, eID and Identity Wallets Guide.

Practical implication: Build wallet acceptance into payment journeys now so identity verification and SCA can converge later.

Threat narrative

Attacker objective: The attacker aims to push fraudulent payments through weak or delegated authentication paths while avoiding liability and detection long enough for funds to move.

1. Entry begins when attackers exploit weak SCA, especially SMS-based authentication that can be intercepted through SIM swap, malware, or social engineering.
2. Escalation occurs when delegated authentication or inconsistent open banking implementations create uneven trust boundaries and unclear liability for fraudulent transactions.
3. Impact follows through fraudulent credit transfers, impersonation of PSPs, and disputes where the institution cannot prove that robust SCA was applied.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

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 and PSR expose an authentication quality gap, not just a compliance gap. The old model assumed that a second factor was enough if it was present. That assumption fails when the factor is trivially phishable, replayable, or interceptable, which is why the regulatory response is shifting from factor counting to assurance quality. For practitioners, the implication is that payment authentication must be judged by resistance to modern fraud paths, not by checkbox compliance.

The payment identity stack is converging, and governance has to follow it. PSD3 and PSR, eIDAS 2.0, and AMLR are increasingly pointing at the same trust infrastructure for verification, authentication, and authorisation. That convergence means the identity team, payments team, and trust services team can no longer optimise in isolation. Practitioners should treat this as a governance alignment problem, not a channel-specific control upgrade.

Delegated authentication creates a liability mirage if ownership is not explicit. The article is right to frame delegation as innovation with retained accountability, because outsourcing SCA does not outsource the risk. The control boundary moves, but the legal and operational burden stays with the PSP. That should push teams to re-evaluate third-party authentication dependencies through the lens of accountable control ownership, not convenience.

Named concept: converged trust infrastructure. PSD3 and PSR are part of a broader pattern where payment authentication, digital identity, and regulated signing are becoming one operational layer. That matters because the compliance advantage will belong to organisations that design identity assurance once and reuse it across payment, KYC, and signing workflows. Practitioners should stop treating payment security as a standalone stack and start treating it as shared identity infrastructure.

Audit evidence is becoming part of the control itself. When liability expands, the ability to prove correct authentication execution becomes a governance requirement, not a back-office afterthought. Evidence preservation, retention integrity, and transaction-level traceability are now part of the SCA control surface. Practitioners need to view archive design as an active compliance control, not passive record-keeping.

Read next: IAM and Identity Provider Buyer's Guide

What this signals

Converged trust infrastructure: payment authentication is becoming a shared identity layer rather than a standalone banking control. As PSD3, PSR, eIDAS 2.0, and AMLR move toward common assurance expectations, programme boundaries will matter less than whether the organisation can reuse one governed identity model across verification, signing, and authorisation.

For practitioners, the next planning question is not whether to improve SCA, but where to place governance ownership for delegated authentication, wallet acceptance, and evidence retention. Teams that keep these controls in separate silos will struggle to prove consistency when enforcement starts.

The practical signal is that payment security architecture now has to be designed for regulatory reuse. That means authentication, identity proofing, and transaction evidence should be engineered as one lifecycle, not as disconnected compliance tasks.

For practitioners

• Harden SCA against phishing and interception Replace SMS one-time passwords for high-risk actions with phishing-resistant authentication methods that cannot be captured or replayed through basic fraud techniques.
• Map delegated authentication ownership Record every delegated SCA path, the third party performing it, the accountable PSP owner, and the evidence needed to prove correct execution.
• Plan for wallet-based identity acceptance Design payment journeys so EUDI Wallet credentials can be accepted as part of the authentication stack without creating a parallel verification process.
• Preserve authentication evidence for disputes Keep transaction logs, signing certificates, and identity verification records in a tamper-resistant archive that supports fraud investigations and supervisory review.

Key takeaways

• PSD3 and PSR move payment authentication away from weak factor checking and toward assurance quality, liability clarity, and identity-backed trust.
• The regulatory change matters because delegated authentication, wallet acceptance, and audit evidence now sit on the same governance path.
• Teams that align SCA, digital identity, and evidence retention early will be better positioned for the 2026 to 2027 enforcement window.

Related NHI Mgmt Group resources: IAM and Identity Provider Buyer's Guide · Passwordless and Passkeys Guide · Digital Identity, eID and Identity Wallets Guide · Financial Services Identity Security Guide

Key terms

• 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.
• Delegated Authentication: Delegated authentication is the practice of outsourcing sign-in, session creation, and related credential handling to an external identity service. The application still enforces access, but the trusted identity workflow lives outside the codebase, which changes where security reviews, logging, and revocation need to focus.
• Verification Of Payee: Verification of payee is a control that checks whether the recipient name and account number supplied in a payment instruction match. It is designed to interrupt authorised fraud by exposing destination mismatches before money leaves the payer’s account, but it still depends on alert quality and user response.
• Qualified Electronic Signature: A higher-assurance signature backed by certificate-based identity and trust service provider controls. It is used where legal recognition and stronger evidentiary value are required, especially in cross-border or regulated workflows where the identity chain must remain defensible.

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.