APP fraud happens when the victim is tricked into authorising a payment to a fraudster, so the payment is technically authorised. Unauthorised fraud is when a payment is made without the account holder’s permission. Teams should treat them differently in controls, customer journeys, payment checks and case handling, because liability, detection signals and recovery paths are not the same.
Why APP fraud and unauthorised fraud are not the same event
app fraud and unauthorised fraud differ at the point of payment approval. With APP fraud, the customer is deceived into approving the transfer, so the payment rail sees consent. With unauthorised fraud, the payment occurs without permission, so the control problem is account compromise rather than customer deception. That distinction drives different operational handling, evidence collection and reimbursement logic.
The practical test is not just whether money left the account, but whether the customer actively authorised the transaction. In APP cases, the bank may need to look for scam indicators, customer journey friction and confirmation signals. In unauthorised cases, teams usually focus first on compromised credentials, stolen sessions, device risk and whether the account or card was abused by an attacker.
APP fraud often sits at the boundary between fraud prevention and payment execution because the customer appears to have approved the payment. Unauthorised fraud sits closer to authentication, access control and compromise response because the payment itself is invalid. That means the evidence you preserve, the questions you ask the customer and the way you triage the case should be different from the start.
How the control model changes in practice
The main control difference is where the system is expected to stop the loss. For APP fraud, controls need to interrupt social engineering, suspicious payment patterns and beneficiary-risk signals before the customer completes the transfer. For unauthorised fraud, controls need to detect account takeover, abnormal login behaviour, unsafe device activity and unauthorised payment initiation.
That distinction also affects customer journeys. APP controls often introduce warnings, step-up friction, payee verification and call-back style interventions when the payment context looks suspicious. Unauthorised fraud controls focus more on login assurance, session protection, anomaly detection and rapid account containment after suspicious access. Treating both as the same problem usually weakens one side or the other.
Case handling should follow the same split. APP investigations usually need scam narrative detail, payee information, conversation context and timing evidence. Unauthorised investigations usually need authentication logs, session history, device telemetry and payment initiation traces. If teams collapse those workflows into one generic fraud queue, they miss the signals that matter for recovery and repeat-prevention.
For teams aligning fraud and cyber work, the best operational pattern is shared signal intake with separate decision paths. NHIMG’s Fraud and Cyber Convergence Guide is useful here because APP fraud needs scam intelligence and payment controls, while unauthorised fraud needs compromise signals and access-response discipline. The two case types overlap in impact, but not in root cause.
Why liability, recovery and evidence need separate playbooks
Liability and recovery are different because the customer’s role is different. In APP fraud, the dispute often turns on whether the customer was manipulated and whether the bank applied the expected scam controls. In unauthorised fraud, the dispute usually turns on whether the transaction was truly unauthorised and whether the institution can show the compromise path. Those are not interchangeable questions.
Recovery paths also differ. APP losses may depend on speed, beneficiary tracing and reimbursement rules tied to scam scenarios. Unauthorised losses may depend more on immediate credential resets, card or account suspension, session revocation and containment of further misuse. The evidence you collect should therefore support the right decision path rather than a generic “fraud happened” conclusion.
That is why internal policy, customer messaging and investigator scripts should name the distinction explicitly. Teams should not assume that every fraudulent payment was “unauthorised”, and they should not treat every scam payment as if the account had been directly compromised. Precise classification improves customer treatment, regulatory handling and the chances of stopping the next loss.
For an overview of the APP side of the problem, Authorised Push Payment Fraud Guide provides the control and reimbursement context that sits behind customer deception cases. For the unauthorised side, the relevant operational lens is whether the payment can be tied to compromise, stolen authentication or abusive access rather than a persuaded customer decision.
Risk and Threat Considerations
APP fraud is attractive to attackers because it bypasses traditional unauthorised-transaction controls by making the victim part of the authorisation step. Unauthorised fraud is attractive because a successful compromise can produce direct transaction authority, often with less customer awareness than a scam. In both cases, weak classification creates exposure because the wrong team may look for the wrong indicators.
Failure mechanism: The organisation applies one case model to two different loss types, so scam-driven payment authorisations are handled like account compromise, or account compromise is handled like customer deception. That can delay intervention, distort fraud analytics and weaken recovery decisions.
Impact: Misclassification can lead to missed warning signals, slower containment, incorrect reimbursement handling and poorer evidence preservation. At scale, it also hides pattern differences between social-engineering losses and credential or session abuse, which weakens prevention.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Fraud cases differ when stolen credentials or sessions enabled the payment. |
| Recommendation — Rotate and revoke exposed authenticators, tokens and sessions after unauthorised payment abuse. | ||
| CIS Controls v8 | CIS-5 — Account Management | The question turns on whether account access was abused or a customer was tricked. |
| Recommendation — Review account and session access paths to separate compromise from authorised payment deception. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Unauthorised fraud depends on whether access was legitimately granted or abused. |
| Recommendation — Validate identity and access signals before treating a payment event as authorised. | ||
Practitioner Guidance
What to verify: Build the first triage question around authorisation status, not just loss amount. If the customer knowingly approved the payment, route the case as APP unless the facts show the approval itself was invalidated by compromise or coercion.
Decision rule: If the case hinges on customer deception, prioritise scam indicators, beneficiary checks and payment-warning effectiveness. If it hinges on unauthorised access, prioritise credential, session and device evidence, plus immediate containment actions.
Practitioner takeaway: The useful distinction is operational, not academic: APP fraud is a deception problem, unauthorised fraud is an access problem, and the right control, evidence and recovery path depend on that split.
Related resources from NHI Mgmt Group
- What is the difference between a service account and an OAuth-connected app?
- What is the difference between a disabled app and a deleted app in Microsoft 365?
- What is the difference between app visibility and identity visibility in SaaS security?
- What is the difference between MCP access and ordinary app integration?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org