A payment scam in which the victim is persuaded to authorise the transfer themselves. The transfer is technically authorised, but the decision is corrupted by deception, which makes liability, evidence, and prevention harder to separate from standard transaction controls.
Expanded Definition
Authorised Push Payment Fraud is not a broken-payment problem in the narrow technical sense. The payment rail may work exactly as designed: the payer initiates and approves the transfer, but the approval is induced by deception, impersonation, or social engineering. That makes it distinct from card fraud or unauthorised account takeover, because the key control failure is the corruption of human judgment before the transaction is executed.
In NHI and IAM discussions, the term matters whenever an attacker uses a legitimate channel, trusted identity, or believable operational context to convince a person to approve a payment, change beneficiary details, or authorise a one-time transfer. Definitions vary across vendors and jurisdictions, but the common pattern is the same: the user is manipulated into becoming the authorising actor. The closest control analogues are strong verification, out-of-band confirmation, and payment change validation, not transaction reversal after the fact. For broader identity governance context, the Ultimate Guide to NHIs is useful for understanding how trusted digital entities and access paths can be abused when governance is weak, while the NIST Cybersecurity Framework 2.0 frames the broader detection and protection duties around identity-driven loss events.
The most common misapplication is treating APP fraud as a pure payment dispute, which occurs when teams focus only on reimbursement workflows and miss the pre-transaction deception path.
Examples and Use Cases
Implementing defences against authorised push payment fraud rigorously often introduces friction in payment approval and vendor-change workflows, requiring organisations to weigh faster execution against stronger confirmation.
- A finance user receives a convincing message from a spoofed executive account and authorises an urgent transfer to a new beneficiary.
- A supplier email thread is hijacked, and the attacker substitutes bank details before the next scheduled invoice payment.
- A help desk call uses voice spoofing or business impersonation to pressure staff into approving a one-off settlement outside normal controls.
- A treasury team receives a legitimate-looking request through a trusted collaboration channel, but the request is fabricated to trigger a same-day payment.
These scenarios align with the identity trust failures documented in the Ultimate Guide to NHIs, where trusted actors, access paths, and secrets become attack surfaces when governance is incomplete. For payment-risk framing, the NIST Cybersecurity Framework 2.0 reinforces the need for preventative verification and continuous detection before funds leave the organisation.
Why It Matters in NHI Security
APP fraud matters to NHI security because many payment approvals are increasingly mediated by software identities, workflow automations, and service accounts that create a false sense of legitimacy. When those identities are misused, an attacker can make a fraudulent request appear operationally routine. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, and that blind spot makes it easier for deception to blend into trusted business processes. The Ultimate Guide to NHIs also reports that 97% of NHIs carry excessive privileges, which increases the chance that a compromised workflow can support a convincing payment manipulation chain.
Practitioners should understand APP fraud as a governance and identity assurance issue, not only a finance issue. Stronger approval thresholds, callback procedures, beneficiary verification, and privileged workflow separation reduce the chance that a trusted channel becomes a fraud vector. The relevant lesson from NIST Cybersecurity Framework 2.0 is that identity trust must be validated continuously, especially when human approval is the final control before value transfer. Organisations typically encounter the operational cost of this term only after a fraudulent transfer has cleared, at which point APP fraud becomes unavoidable to investigate, contain, and recover.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | APP fraud exploits weak identity verification and trust in request channels. |
| NIST CSF 2.0 | DE.CM-1 | Suspicious payment requests require monitoring and anomaly detection across workflows. |
| OWASP Non-Human Identity Top 10 | NHI-07 | Trusted automations and service accounts can be abused to support deceptive payment flows. |
Monitor payment and approval paths for unusual beneficiary or urgency patterns.
Related resources from NHI Mgmt Group
- How should security teams govern device-bound payment credentials in open finance?
- Should teams prefer passwordless authentication for regulated payment flows?
- What is the difference between push-based MFA and phishing-resistant authentication?
- What is the difference between account takeover and new account fraud?
