Authorize Push Payment Fraud

Authorize push payment fraud occurs when a victim is manipulated into sending money to an attacker-controlled account. Unlike card fraud, the payment is authorised by the customer, which makes prevention dependent on stronger context, verification, and behavioural controls.

Expanded Definition

Authorize push payment fraud, often shortened to APP fraud, sits at the intersection of social engineering, payment operations, and identity assurance. The attacker does not steal card data or force an unauthorised transfer. Instead, the victim is persuaded to approve the payment themselves, usually by making the transfer appear urgent, legitimate, or tied to a trusted relationship. That distinction matters because the control problem is not only transaction security, but also whether the payer can reliably verify the counterparty and the request context.

Definitions vary across jurisdictions and banking schemes, but the core pattern is consistent: a genuine payment instruction is induced by deception. Industry guidance is still evolving on where liability should sit, so strong customer authentication alone does not solve the issue. Effective handling often combines step-up verification, out-of-band confirmation, anomaly detection, and call-back checks aligned with NIST SP 800-53 Rev 5 Security and Privacy Controls. The most common misapplication is treating APP fraud as a pure fraud-monitoring problem, which occurs when organisations ignore the human deception step and focus only on payment rails.

Examples and Use Cases

Implementing controls for APP fraud rigorously often introduces friction at the exact moment a customer wants speed, requiring organisations to weigh payment convenience against verification depth.

• A finance employee receives an email that appears to come from a supplier and authorises a bank transfer to a changed account number after a convincing follow-up message.
• A consumer is pressured by a spoofed bank caller to move funds into a “safe account” after being told their account is under immediate threat.
• A business owner approves an invoice payment after an attacker compromises a mailbox and inserts themselves into an existing vendor conversation.
• A user sends a first-time transfer through a banking app because the recipient profile, display name, and profile image look legitimate, even though the account is controlled by the attacker.
• A payment operations team uses callback verification and beneficiary checks to confirm instruction legitimacy before releasing high-value transfers, consistent with broader identity assurance practices described in the NIST Digital Identity Guidelines.

In practice, APP fraud cases often hinge on whether the organisation can detect a mismatch between the requestor, the channel, and the transaction pattern. As with CISA guidance on social engineering, the deception usually succeeds because the request is plausible enough to bypass normal trust checks.

Why It Matters for Security Teams

For security teams, APP fraud is a governance issue as much as an operational one. If the organisation cannot distinguish authorised intent from manipulated intent, then detection logic, customer support, and incident response will all be forced to work after funds have already moved. That creates pressure on fraud, IAM, and payment teams to share signals about identity risk, device trust, session anomalies, and behavioural deviation. Where NHI or agentic AI systems initiate payments on behalf of a person or business, the control challenge becomes sharper because the initiating entity may have valid access but limited contextual judgment. In those environments, authorisation should be bounded by policy, not assumed from login success alone, and transaction approval should reflect role, purpose, and expected behaviour.

Security leaders should also treat APP fraud as a resilience concern. Weak recipient verification, poor step-up authentication, and slow recall procedures all increase loss severity. Controls mapped to social engineering resistance and strong access governance help, but they must be paired with rapid beneficiary review and customer education. Organisations typically encounter the operational reality of APP fraud only after a high-value transfer has cleared and recovery becomes uncertain, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How can financial institutions reduce losses from authorized push payment fraud?
• Authorised Push Payment Fraud
• What breaks when payment fraud controls assume a human is always the actor?
• Who is accountable when fraud starts on social media or SMS and ends in a payment?