An Authorised Push Payment scam tricks a person or business into sending money to a fraudster under the appearance of a legitimate transfer. The victim authorises the payment, so the transaction often appears valid. In identity and fraud controls, it exploits trust, impersonation, weak verification, and poor out-of-band confirmation.
What an Authorised Push Payment scam exploits
An authorised push payment scam works because the transfer is initiated by the victim, so the payment can look legitimate to banks and controls at the point of execution. The fraud succeeds by manipulating trust, urgency, authority and verification gaps rather than by forcing a technical compromise.
In practice, the scam often mimics a real supplier, executive, lawyer, landlord or bank interaction. The attacker relies on impersonation and social engineering to make the payment seem routine, time-sensitive or beneficial, which is why strong confirmation habits matter as much as payment technology.
How APP scams bypass ordinary payment controls
APP fraud is especially effective when organisations treat “authorised” as “safe”. A valid-looking payment instruction can still be fraudulent if the payer was deceived, and that distinction is what makes the scam so difficult to stop with only traditional transaction validation.
Controls such as confirmation of payee, payee verification, call-back procedures and internal approval workflows reduce the chance that a spoofed beneficiary or redirection request succeeds. When those controls are weak, the attacker only needs one convincing message or call to redirect funds.
For teams building payment-defence playbooks, NHIMG’s Authorised Push Payment (APP) Fraud Guide covers common scam variants, confirmation of payee, mule detection and reimbursement rules.
Why APP scams are hard to reverse
Once funds leave the victim’s account, recovery can be difficult because APP fraud uses an authorised transfer path and money can be moved quickly through mule accounts, cash-out networks or layered transfers. The apparent legitimacy of the payment can also delay escalation, which gives the fraudster more time to disperse the proceeds.
This is why the impact is not limited to the immediate loss amount. Organisations may face customer harm, reimbursement disputes, operational investigation work, reputational damage and follow-on fraud if the same deception path is reused against other employees or counterparties.
What strong prevention looks like
Effective prevention depends on friction at the right moment, not on blocking all payments. High-risk transfers should trigger step-up verification, independent callback checks, beneficiary validation and clear escalation paths when a request is unusual, urgent or outside normal payment behaviour.
Training helps only when it is paired with process. Staff need to know that a familiar name, email thread or phone number is not enough on its own, and finance or treasury teams should treat any change in account details, payment destination or urgency as a verification event.
Risk and Threat Considerations
APP scams create a direct financial exposure because they exploit authorised payment rails, impersonation and urgency to get the victim to approve the transfer. They are especially dangerous in businesses with high-value payments, fragmented approval paths or weak out-of-band verification.
Failure mechanism: The attacker convinces the payer to authorise a transfer to a fraudulent beneficiary, often by hijacking trust in a supplier, executive, or known counterpart and suppressing normal checks.
Impact: Funds can be lost quickly, recovery may be limited, and the same social-engineering pattern can be reused for invoice redirection, executive impersonation or supplier payment diversion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | APP scams abuse payment approval and account verification weaknesses. |
| Recommendation — Restrict payment authority and verify beneficiary changes before approving transfers. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The scam exploits weak verification and trusted communication channels. |
| AU-6 — Audit Record Review, Analysis, and Reporting | APP fraud detection depends on reviewing anomalous payment and approval activity. | |
| Recommendation — Require out-of-band verification for high-risk payment instructions and beneficiary changes. Review anomalous payment approvals and investigate unusual beneficiary or timing patterns. | ||
| OWASP API Security Top 10 | API6 — Unrestricted Access to Sensitive Business Flows | APP scams abuse a sensitive business flow by steering an approved payment to the wrong recipient. |
| Recommendation — Protect payment workflows with step-up checks for beneficiary changes and unusual transfer requests. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control Are Managed | APP fraud prevention relies on governing who can authorise transfers and how verification occurs. |
| Recommendation — Tighten payment approval authority and require stronger verification for high-value transfers. | ||
Practitioner Guidance
Why practitioners should care: APP fraud is as much a process-control problem as a cyber problem, because the payment itself is usually valid from the system’s perspective. The key judgement is deciding where extra verification belongs without making normal payments unusable.
Common misunderstanding: Many teams assume that bank-side authentication or a user-approved transfer is enough protection. In reality, the control gap is often in the instruction itself, especially where the victim has been manipulated into authorising the wrong recipient.
Practitioner takeaway: Treat any change to beneficiary details, payment urgency or approval route as a fraud signal, and make independent confirmation mandatory before money leaves the organisation.
Related resources from NHI Mgmt Group
- Who should be accountable when authorised push payment scams succeed?
- Why does authorised push payment fraud create a different control problem than account takeover fraud?
- How should banks reduce authorised push payment fraud without creating excessive friction for legitimate customers?
- Why do authorised push payment scams remain so difficult to stop once the payment is authorised?