Authorized push payment fraud, or APP fraud, is the scam where the victim is tricked into sending the money themselves. There is no stolen card and no hacked account: a real person, using their own credentials, authorizes a genuine payment to an account the fraudster controls. That single fact is what makes APP fraud the hardest payment crime to stop, because the transaction looks completely legitimate at the moment it happens. It passes the fraud checks, because from the bank’s side nothing is wrong: the right customer approved it. UK Finance reported £450.7 million lost to APP fraud across 185,733 cases in 2024, and the problem has pushed regulators to make banks reimburse victims. This guide explains how APP fraud works, why instant payment rails make it worse, what it costs and who now pays, and why the real defense is verifying the intent behind a payment before it settles rather than scoring it for risk after. One honest note up front: no tool can eliminate a fraud where the customer is genuinely deceived into approving the payment, because the deception happens in the victim’s mind, outside any payment system. What verification can do is reduce exposure, hold anomalous payments before they settle, and produce evidence of exactly who approved what.
What is authorized push payment (APP) fraud?
Authorized push payment fraud is when a fraudster deceives a victim into authorizing a payment from their own account to an account the fraudster controls. The word that matters is authorized: unlike card fraud or account takeover, where a criminal uses stolen details, in APP fraud the legitimate account holder personally approves the transfer, believing it is going somewhere else. A "push" payment is one the payer initiates and sends, as opposed to a "pull" payment like a card charge that the merchant requests. Because the payer pushes the money themselves, the payment carries every legitimate signal a bank looks for: the right device, the right login, the right customer, a plausible amount.
That is precisely why APP fraud defeats traditional fraud prevention. A stolen-card transaction throws off anomalies a fraud engine can catch. An authorized push payment does not, because at the moment of the transfer nothing about it is anomalous to the bank; the fraud lives in the story the victim was told, not in the transaction data. UK Finance found that 70% of APP fraud cases in 2024 started online, on social media, marketplaces, and fake websites, with the payment itself being the last, legitimate-looking step of a longer deception. The battleground is therefore not detecting a bad transaction; it is proving that a good-looking one was actually intended.
Why is APP fraud so hard to stop on modern payment rails?
Because the money is gone before anyone can react. Instant payment rails are designed to be irreversible and fast, which is exactly what fraudsters exploit. The Clearing House is explicit about this for the RTP network: it is "strictly credit push," and sending institutions cannot revoke or recall a payment once submitted, with settlement "final and irrevocable". Once a victim authorizes an instant transfer, the traditional window to claw it back closes in seconds, and the fraudster moves it onward through mule accounts immediately.
The scale of instant payments is what turns this into a systemic problem. RTP alone processed $246 billion across 343 million transactions in 2024, up 94% in value, now exceeding one million payments a day. The Federal Reserve’s FedNow service, launched in July 2023, settles individual payments within seconds as well. Instant rails are the future of payments and their finality is a feature, not a bug: it is what makes them useful. But that same finality means fraud has to be stopped before the payment settles, not investigated after, because after settlement there is nothing to reverse. Verification that happens post-settlement is verification that arrives too late.
How does APP fraud actually happen?
APP fraud is a family of scams, not a single technique, and each one manipulates a victim into authorizing a transfer for a reason that feels legitimate at the time. The common scam types, drawn from the 2024 UK Finance data, show where the losses concentrate:
- Purchase scams: the victim pays for goods or services that never arrive, the most common APP type by volume, accounting for £87.1 million in 2024.
- Investment scams: fake high-return opportunities, the most costly category and still climbing, at £144.4 million in 2024, up 34% even as case numbers fell.
- Impersonation scams: a fraudster posing as a bank, a government agency, or a trusted company convinces the victim to move money to a "safe account."
- Romance scams: a fabricated relationship built over weeks or months before the requests for money begin.
- Business email compromise (BEC) and CEO fraud: the corporate form of APP fraud, where a spoofed or hijacked executive or supplier email directs finance staff to wire funds. See our guide on CEO fraud and wire fraud.
How are AI and deepfakes changing APP fraud?
AI is making the deception far more convincing, which strikes directly at the human authorization step APP fraud depends on. The clearest example is the case in which engineering firm Arup lost US$25.6 million after an employee joined a video call where the "chief financial officer" and other colleagues were all AI deepfakes, then made 15 transfers as instructed. The employee authorized every payment, believing they were following a real executive’s orders. That is APP fraud at its most advanced: the authorization was genuine, the person was real, and the entire context around them was synthetic.
Business email compromise remains the highest-value corporate channel even without deepfakes. The FBI’s Internet Crime Complaint Center reported $2.77 billion in BEC losses across 21,442 complaints in 2024, part of $16.6 billion in total reported cybercrime losses. As deepfake voice and video get cheaper, the traditional advice, "call the executive to confirm," weakens, because the confirmation channel itself can be faked. That is why the defensible control is shifting from "trust a human confirmation" to "verify the payment intent cryptographically," a check a deepfake cannot satisfy. See our page on deepfake payment fraud protection.
What does APP fraud cost, and who actually pays for it?
The direct losses are large and the liability is shifting onto banks. In the UK, of the £450.7 million lost to APP fraud in 2024, £267.1 million, around 59%, was returned to victims. In the US, the Federal Trade Commission reported more than $12.5 billion in fraud losses in 2024, up 25%, with bank transfers and payments accounting for the single largest share at $2.09 billion, ahead of cryptocurrency. Push-payment channels are where the money actually leaves.
The bigger change is regulatory. Since 7 October 2024, the UK’s Payment Systems Regulator requires banks to reimburse APP scam victims up to £85,000 per claim, with the cost split 50/50 between the sending and receiving bank. In the first three months, the PSR reported that 86% of in-scope APP fraud money was reimbursed to victims. That reframes the economics: APP fraud is no longer only the victim’s loss, it is a direct cost on the banks that send and receive the payment. For a receiving bank, an account used to launder scam proceeds now carries half the bill. That gives every institution on an instant rail a hard financial reason to verify payments before they settle, not just to reimburse after.
Why does stopping APP fraud require verifying intent, not scoring risk?
Because the transaction itself is not suspicious; only the intent behind it is wrong. Traditional fraud prevention scores a transaction on signals such as device, location, velocity, and history. In APP fraud all of those signals are clean, because the real customer really is making the payment from their usual device. A risk score built to catch stolen credentials has nothing to flag. The thing that is actually wrong, that the customer was deceived about where the money is really going, is not visible in the transaction data at all.
That is why the effective control is verifying intent and authority before settlement. Instead of asking "does this transaction look risky," intent verification asks "can we prove who approved this exact payment, to this exact payee, for this exact purpose, and that they were authorized to." It reduces each payment to a canonical intent, payer, payee, amount, and purpose, and checks that a legitimate identity approved that specific instruction before the money is released. This will not stop a victim who has been fully deceived into approving a payment they believe is genuine, and it would be dishonest to claim otherwise. What it does is catch the cases where the approval does not match the claimed intent, hold anomalous payments such as a first-time payee or an out-of-policy amount for review before an irreversible rail settles, and, critically, produce a verifiable record of exactly what was approved. In a world of mandatory reimbursement, that evidence is what determines who bears the loss.
How does RankShield Financial help stop APP fraud?
RankShield Financial sits in the authorization path and verifies the intent of a payment before it settles, rather than scoring it for fraud afterward. It reduces each payment to a canonical intent, the payer, payee, amount, and purpose, signs that intent, checks that a human or an authorized AI agent approved it, and returns a released, held, or denied verdict before the money moves on an irreversible rail. A first-time payee, an amount outside policy, a failed signature, or an AI agent acting beyond its granted authority produces a held or denied verdict instead of a settled payment. Each decision is sealed to a tamper-evident record, so who approved what, and why the verdict was reached, can be independently checked later. For instant rails specifically, see RTP fraud prevention and the broader pre-settlement payment verification approach; for machine-initiated payments, agentic payment security.
The honest boundary matters here, because APP fraud is exactly the case where overpromising is easy. No tool, RankShield included, can guarantee it stops APP fraud or eliminates loss, because a determined fraudster can deceive a genuine customer into authorizing a payment that looks entirely legitimate, and the final decision to send belongs to that customer. RankShield does not make an institution compliant, and it does not take custody of funds. What it realistically delivers is reduced exposure through intent and authority checks, containment through held verdicts on anomalous payments before settlement, and verifiable evidence of the authorization that supports compliance and, under reimbursement rules, helps establish who is liable. The signing layer is quantum-safe by construction rather than quantum-proof, built to current NIST standards. The goal is fewer scam payments released and defensible evidence for the ones disputed, not a promise of zero fraud.