PSR and PSD3 change fraud controls, liability, and SCA

At a glance

What this is: PSR and PSD3 are set to overhaul EU payments security by expanding fraud controls, liability rules, and strong customer authentication requirements.

Why it matters: IAM, fraud, and identity teams need to treat payment authentication as a broader governance problem because controls now reach beyond login into device signals, behaviour, and transaction approval.

By the numbers:

• According to Revolut’s most recent Financial Crime and Consumer Security report, about 75% of authorized fraud originates on social media platforms, such as Facebook, Instagram, WhatsApp, or Telegram.

👉 Read OneSpan's analysis of PSR and PSD3 fraud controls, liability, and SCA

Context

PSR and PSD3 are best understood as a governance response to payment fraud that increasingly begins outside the banking app and ends inside it. The primary question for practitioners is no longer only whether a user can authenticate, but whether the full payment journey can resist manipulation, impersonation, and coerced approval.

For identity and access teams, the practical shift is that strong customer authentication is being pulled into a wider control stack that includes device intelligence, behavioural signals, verification of payee, and transaction-level blocking. That makes payment security a cross-functional identity problem rather than a narrow authentication problem.

The article’s starting point is typical for European financial institutions: existing PSD2-era controls reduced some risk, but they did not remove the assumptions that fraudsters exploit when users are persuaded to authorise the transaction themselves.

Key questions

Q: How should financial institutions implement verification of payee without creating warning fatigue?

A: Treat verification of payee as a targeted interruption control, not a universal warning banner. Tune it to produce clear, actionable mismatch messages, and monitor how often users override prompts. If alerts are too frequent or too vague, people will ignore them, which reduces the control’s value and weakens fraud outcomes.

Q: Why do strong customer authentication controls still fail against authorised fraud?

A: Because authorised fraud does not usually break authentication. The victim authenticates normally and then authorises the payment under manipulation, so the failure sits in transaction decision-making rather than login assurance. That is why payment controls need behavioural signals, payee checks, and blocking logic in addition to SCA.

Q: What do payment teams get wrong about behavioural intelligence in fraud detection?

A: They often treat behavioural intelligence as a detection add-on instead of a decision input. In practice, typing patterns, touch behaviour, and transaction speed only help when they are combined with device context and clear response rules. Otherwise they become interesting signals with no operational consequence.

Q: Who is accountable when an authorised fraud payment is not blocked?

A: Accountability depends on where the control failure occurred. Under the PSR model described in the article, a PSP can be liable if it failed to apply verification of payee, perform transaction monitoring, or block a suspicious transaction. That makes evidence quality and control execution part of accountability.

Technical breakdown

Verification of payee and the mismatch problem

Verification of payee, or VoP, checks whether the payee name matches the IBAN supplied by the payer. The security value is not simple validation but interruption of social engineering at the point of transfer. If the warning arrives too late, is too noisy, or is routinely bypassed by users, it becomes a compliance signal rather than a fraud control. The regulation extends VoP beyond euro instant transfers, which broadens coverage but does not change the core challenge: people can still be persuaded to override warnings when the fraud narrative is strong enough.

Practical implication: treat VoP as a transaction control that needs tuning, monitoring, and escalation logic, not as a one-time configuration.

Behavioural and device intelligence in transaction monitoring

The PSR’s transaction monitoring model adds device and behavioural intelligence to help identify authorised fraud. Device intelligence looks at whether the payer is using unusual devices, remote access tools, malware-infected endpoints, or a device that is already in a phone call. Behavioural intelligence looks for changes in typing rhythm, touch patterns, and transaction speed that suggest coercion or deception. This matters because authorised fraud often preserves valid credentials while corrupting the decision to pay. The control model therefore shifts from identity proofing alone to context-aware detection around the payment event.

Practical implication: align fraud telemetry with banking-session context so monitoring can distinguish normal activity from coerced authorisation.

Biometric SCA and the limits of element diversity

PSD3 is expected to narrow the practical use of strong customer authentication by allowing two inherence elements, such as physiological and behavioural biometrics, while constraining reliance on possession or knowledge elements in the same way. That matters because authentication is moving toward combinations of signals that are harder to share or steal outright. However, biometrics do not eliminate fraud when the user is socially engineered into approving a payment. In other words, stronger authentication can reduce unauthorized access, but it cannot by itself neutralize authorised fraud.

Practical implication: design SCA as one layer inside a broader fraud decision model, not as the final control boundary.

Threat narrative

Attacker objective: The attacker’s objective is to obtain an authorised transfer to a fraud-controlled account while avoiding detection long enough for the payment to settle.

1. Entry occurs when a fraudster reaches the victim through a trusted-looking channel such as social media, messaging, email, or phone impersonation and induces a payment request.
2. Credential or approval access happens when the victim authorises the payment themselves, giving the fraudster a legitimate transaction path rather than stolen-login access.
3. Impact follows when the transfer is completed and the payer absorbs the loss unless the PSP failed in verification of payee, monitoring, or transaction blocking.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PSR and PSD3 formalise a transaction-governance model, not just a stronger login model. The article makes clear that the control surface now includes payee validation, behavioural signals, device context, and blocking decisions. That is a broader identity boundary than traditional SCA, and it forces fraud teams and IAM teams to share ownership of the same risk.

Authorized fraud exposes the limits of identity assurance when the user is the attacker’s conduit. A user can be fully authenticated and still be manipulated into approving the transfer, which means the identity system has done its job while the payment control plane has failed. Practitioners should read this as a shift from identity verification to decision integrity.

Fraud controls are becoming accountable for false negatives and false positives in equal measure. The article’s liability discussion shows why PSPs will be pushed to block suspicious transactions, but also why they will need better data to avoid unnecessary friction. The field is moving toward controls that must be defensible both operationally and legally.

Behavioural signals are becoming a governance input, not just an analytics feature. Once device state, typing rhythm, and session speed are part of the control decision, identity programmes need clearer rules for data quality, retention, and explainability. The implication is that fraud monitoring now sits at the intersection of identity, privacy, and payment accountability.

Verification of payee is a named concept in the payments stack because it tackles beneficiary trust, not user trust. That distinction matters. The control is designed to catch destination mismatches, but it still depends on user responsiveness and careful tuning, which makes it a governance layer rather than a complete fraud solution.

From our research:

• According to our The 2024 ESG Report: Managing Non-Human Identities, 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• For teams extending payment controls into identity governance, the next step is to study Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the lifecycle side of entitlement control.

What this signals

Verification-of-payee governance: the market is moving toward controls that challenge destination trust as much as user trust, which means payment teams need clearer operating rules for warnings, escalation, and exception handling. That same logic will start to shape how identity teams think about approval integrity in other high-risk workflows.

The article’s risk model points to a broader convergence between fraud operations and identity governance. As device and behavioural telemetry become part of control decisions, practitioners will need better data lineage, shorter feedback loops, and stronger evidence for why a transaction was allowed or blocked.

With 72% of organisations already reporting or suspecting a non-human identity breach in our 2024 ESG Report: Managing Non-Human Identities, the strategic lesson is that control design must account for both human manipulation and machine-assisted access paths. Payment fraud and NHI governance are increasingly the same operational conversation, just at different points in the attack chain.

For practitioners

• Rebuild payment controls around transaction integrity Map where your current controls stop at authentication and where they should extend into payee validation, device signals, behavioural monitoring, and blocking decisions. The goal is to reduce reliance on user vigilance alone.
• Tune verification of payee warnings for actionability Review warning thresholds, wording, and escalation paths so the control interrupts fraud without generating so many false prompts that users stop trusting the signal.
• Join fraud telemetry with identity telemetry Correlate session context, device risk, and authentication outcomes so analysts can see when a transaction is legitimate in form but suspicious in intent.
• Define liability-ready evidence trails Document how your PSP detects suspicious activity, blocks transfers, and records exceptions so you can defend operational decisions if a fraud case is challenged.

Key takeaways

• PSR and PSD3 push payments security beyond login assurance into transaction governance, where payee checks, telemetry, and blocking logic matter.
• Authorized fraud remains effective because the victim can authenticate correctly and still be manipulated into approving the transfer.
• Practitioners should prepare for a control model that combines identity, behavioural, and liability evidence rather than relying on customer vigilance alone.

Key terms

• 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.
• Authorised Fraud: Authorised fraud happens when a victim is manipulated into approving a payment themselves. The transaction is legitimate from an authentication standpoint, which is why detection depends on context, behaviour, and payment validation rather than login controls alone.
• Behavioural Intelligence: Behavioural intelligence uses patterns such as typing rhythm, touch behaviour, and transaction timing to identify when a session is being influenced or coerced. In payments, it adds decision context that traditional authentication cannot provide, especially when credentials are not stolen.
• Strong Customer Authentication: Strong customer authentication is a method for proving a payer’s identity using multiple authentication elements. In payments, it protects against unauthorized access, but it does not by itself stop a user from approving a fraudulent transaction under pressure or deception.

Deepen your knowledge

PSR, PSD3, and the expansion of payment fraud controls are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for identity-driven transaction risk, this is a relevant place to start.

This post draws on content published by OneSpan: PSD3: Habemus Pactum Compliance Frederik Mennes. Read the original.