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.
Why This Matters for Security Teams
strong customer authentication is designed to verify that the person or device at the point of login is legitimate, but authorised fraud happens after that checkpoint. The customer authenticates normally, then is manipulated into approving a payment, adding a new payee, or sharing a one-time code. That means the weakness is not authentication strength alone, but the transaction controls surrounding consent, payee risk, and abnormal behaviour.
This is why payment security teams increasingly pair SCA with step-up checks, beneficiary verification, and transaction monitoring. Guidance in the NIST Cybersecurity Framework 2.0 treats identity assurance as only one layer of a broader risk decision process, which is the right mental model here. For a practical lens on control failures caused by behavioural gaps, the The State of Secrets in AppSec research shows how often organisations trust control maturity more than actual operating reality.
In practice, many security teams only discover authorised fraud after the transfer has already settled, rather than through intentional transaction-level prevention.
How It Works in Practice
Authorised fraud succeeds because the attacker does not need to defeat the login process. Instead, they exploit the customer’s trust, urgency, or confusion to get a valid approval. From a controls perspective, that means the decision point must move from “is this user authenticated?” to “does this payment look consistent with the user’s normal intent and the current context?”
Current best practice is to combine several signals at the point of payment. That often includes payee verification, device and session risk scoring, behavioural anomaly detection, transaction limits, and challenge flows for high-risk actions. If the payment is to a new beneficiary, the system may delay execution, require out-of-band confirmation, or trigger a hold for manual review. This aligns with the broader risk-based control approach described in the Ultimate Guide to NHIs — Standards, where identity proof alone is never treated as sufficient once action authority is in scope.
Operationally, teams should map the transaction journey into distinct control points:
- Login authentication, which answers who is present.
- Session risk assessment, which checks whether the context has changed.
- Payee and beneficiary validation, which tests whether the destination is expected.
- Transaction decisioning, which can block, delay, step up, or confirm.
- Post-transaction monitoring, which supports rapid intervention and recall.
Where this works best, the bank or payment provider has enough behavioural history to set meaningful thresholds and enough integration depth to intervene before settlement. These controls tend to break down in fast-payment rails with low latency and limited recall windows because there is little time to distinguish genuine urgency from social-engineered approval.
Common Variations and Edge Cases
Tighter transaction controls often increase customer friction, requiring organisations to balance fraud reduction against abandonment, complaints, and accessibility. That tradeoff is especially sharp in retail banking, peer-to-peer transfers, and card-not-present flows, where legitimate customers may also act under time pressure.
There is no universal standard for authorised fraud prevention yet. Current guidance suggests using layered decisioning rather than relying on a single control such as SCA, because the fraud pattern is behavioural and often adversarially adapted. Some environments can safely use stronger friction on first payments to new payees, while others need softer interventions such as contextual warnings, delayed settlement, or beneficiary confirmation to avoid breaking the user experience.
One important edge case is when the payment is technically authorised by the customer but initiated after account takeover or SIM swap. In those cases, the fraud looks similar at the transaction layer, but the root cause may involve compromised device trust or identity recovery weaknesses. Another edge case is business payments, where the approving user may be legitimate but the internal approval chain is manipulated. In both cases, behavioural and beneficiary controls matter more than authentication ceremony. The practical lesson is simple: SCA reduces unauthorised access, but it cannot by itself prove that a seemingly valid instruction was a safe one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Identity assurance alone is insufficient for fraud decisions. |
| NIST AI RMF | Risk-based decisioning and oversight fit authorised-fraud detection. | |
| NIST SP 800-63 | 4.2 | Assurance at authentication does not validate transaction intent. |
Treat authentication as one signal and add transaction-level confirmation for high-risk actions.
