Authorised push payment fraud happens when a victim is manipulated into approving a payment to a criminal account. Because the payment is user-authorised in form, reimbursement and accountability rules often shift the burden onto banks, making identity assurance at the point of approval financially critical.
Expanded Definition
APP fraud, also called authorised push payment fraud, sits at the intersection of payment authorisation and identity assurance. The payment is technically approved by the victim, so the fraud is not primarily a card-present theft or a classic unauthorised transfer. Instead, the attacker manipulates trust, urgency, or authority so the payer willingly initiates the transfer. That is why identity controls matter at the point of approval, not only at login. In practice, APP fraud is often discussed alongside social engineering, impersonation, and business email compromise, but it is narrower than those terms because the defining feature is the authorised payment instruction. No single standard governs this yet, and usage in the industry is still evolving across banking, payments, and incident response teams. For control design, organisations often map APP fraud prevention to risk-based authentication, step-up verification, and payment confirmation workflows, as reflected in the NIST SP 800-53 Rev 5 Security and Privacy Controls. The most common misapplication is treating APP fraud as a pure reimbursement problem, which occurs when institutions focus on loss handling after settlement instead of strengthening approval-time identity checks.
Examples and Use Cases
Implementing APP fraud controls rigorously often introduces friction in the payment journey, requiring organisations to weigh customer convenience against the cost of stronger verification and slower approvals. Common scenarios include:
- A finance employee receives an urgent email that appears to come from the CFO and is persuaded to send a transfer to a new supplier account.
- A customer service agent calls a bank posing as a distressed customer and requests a payment to a “safe account” under false pretences.
- A treasury user approves a high-value transfer after an attacker compromises a messaging channel and reinforces the request with convincing context.
- A fraud operations team reviews anomalous beneficiary changes, confirming that the account details were altered immediately before authorisation.
These cases show why APP fraud is not just a malware problem. It is also a governance problem around who can approve what, under which conditions, and with what corroborating signals. Controls such as out-of-band confirmation, beneficiary verification, and payee risk scoring are often combined with identity workflows from the Ultimate Guide to NHIs, because automated fraud screening and case handling frequently depend on service accounts and API-driven decisioning. Payments teams also refer to NIST SP 800-53 Rev 5 Security and Privacy Controls when designing approval gates and separation of duties.
Why It Matters in NHI Security
APP fraud matters in NHI security because the detection and response stack that protects payments increasingly depends on NHIs. Risk engines, notification services, approval workflows, and case management platforms all use service accounts, API keys, and automation tokens to move data and trigger interventions. When those NHIs are overprivileged or poorly monitored, fraud controls can be bypassed or made blind at the exact moment they are needed. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts, which makes fraud tooling itself a potential weak point rather than a safeguard. That is why APP fraud should be read as an identity governance issue as much as a payments issue, especially when approval workflows depend on machine-to-machine trust. The broader NHI risk picture is also clear in the Ultimate Guide to NHIs, which highlights how frequently secrets and service accounts are mishandled. Organisationally, the issue often becomes visible only after a real transfer has cleared and recovery options are limited, at which point APP fraud becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | APP fraud prevention depends on strong control of service-account secrets and approval workflows. |
| NIST CSF 2.0 | PR.AC-4 | Access and approval controls map to limiting who can authorise payment actions. |
| NIST SP 800-63 | AAL2 | Step-up assurance is relevant when payment approval risk rises. |
| NIST Zero Trust (SP 800-207) | Zero Trust principles help verify every approval request and machine action. | |
| NIST AI RMF | Fraud scoring and alerting systems need governed AI risk management. |
Protect automated payment and fraud workflows with least privilege, secret hygiene, and monitored authentication.
