Designing APP Fraud Controls for Instant Payments
Authorized push payment fraud defeats every control that assumes the transaction is unauthorized, because it is authorized. Control design for irrevocable rails, what the UK experience shows, and why the beneficiary matters more than the transaction pattern.
Card fraud controls assume the transaction is unauthorized. The cardholder did not make this purchase, so the job is to detect that the person transacting is not the person who owns the account.
Authorized push payment fraud inverts that entirely. The customer really did initiate the payment. They authenticated correctly, from their usual device, on their usual network, to an amount within their normal range. They were deceived about who was receiving the money.
Any control whose logic starts from "the customer did not do this" is looking for the wrong thing. Some signals still survive the shift, because velocity, device behaviour and interaction patterns can carry traces of somebody being coached through a payment in real time. What does not survive is the assumption that authorisation itself is the anomaly. And on credit-push rails with no chargeback, getting it wrong is permanent.
The UK is the leading indicator
The UK has run instant payments at national scale since 2008, which makes it the best available preview of where the US is heading.
The UK also ran the experiment the US has not: mandatory reimbursement. Since 7 October 2024, UK banks have been required to reimburse APP fraud victims, subject to exceptions for gross negligence and first-party fraud and to a per-claim cap. That makes 2025 the first full calendar year in which institutions carried the losses, and the result is not what most people assume.
UK Finance reported APP fraud losses of £576.4 million in 2025, up 19%, across 248,070 cases, up 7%. Unauthorized fraud went the other way, down 5% to £703.4 million. Total losses reached £1.28 billion. Reimbursement ran at 61% of APP losses by value.
Read those two lines together, because they are the finding. Unauthorized fraud fell while authorized fraud rose sharply. As institutions hardened the controls that stop someone taking money from an account, criminals moved to persuading the account holder to send it. Making banks liable did not suppress the losses in year one; it redistributed who absorbs them while the underlying attack shifted.
Two things follow for a US institution. First, do not expect a reimbursement mandate to fix this, and do not wait for one to justify investment. Second, controls that assume a compromised account will keep working and will keep being routed around, because the growth is in social engineering rather than in credential theft.
Why the beneficiary matters more than the pattern
The single most important design shift is moving attention from the transaction to the recipient.
Transaction-pattern scoring asks whether this payment looks unusual for this customer. In APP fraud it frequently does not. Someone convinced they are paying a legitimate invoice, or moving money to a "safe account" at their bank's instruction, produces a transaction that looks deliberate because it is.
Beneficiary-focused controls ask different questions. Has this customer paid this account before? How old is the receiving account? How many other customers have recently sent first-time payments to it? Does the account name match what the customer believes they are paying?
That last one is the confirmation-of-payee pattern the UK adopted, and it works because the deception usually depends on the customer not seeing who actually receives the money.
The first-time-beneficiary flow is where the leverage is. Most APP losses go to an account the customer has never paid before. A deliberate friction point there, with a clear warning describing the specific scam pattern rather than a generic caution, stops a meaningful share of losses. It is also cheap to build relative to anything involving models.
The sub-second constraint
Instant means the decision window is under a second, and that rules out a great deal.
What does not fit: a batch lookup against a table refreshed overnight. A model scored in a queue. A human review step. An external call without a strict timeout and a defined fallback.
What does fit: in-memory lookups against pre-computed features, beneficiary risk data kept current asynchronously and read synchronously, deterministic rules evaluated locally, and a scoring service with a hard timeout and an explicit decision about what happens when it does not answer.
That last point causes more production incidents than the models themselves. When the scoring service degrades, does the payment proceed unscored or fail closed? Both are defensible. Having never decided is not, and the answer needs to be a deliberate policy rather than whatever the timeout handler happens to do.
The common mistake is assuming existing fraud logic ports over. Card scoring already runs in real time at most institutions, so the sub-second budget is rarely the new part. What does not port is everything the ACH and wire rulesets assume: a database round trip per signal, an overnight window to reconsider, and a human in the loop before release. Rewriting that is a project in its own right, and teams that discover it late lose quarters.
Layered controls that actually help
Velocity limits that account for the rail. Instant payments enable draining an account in minutes rather than days. Per-transaction limits are less useful than cumulative limits over short windows.
Progressive limits for new relationships. A newly opened account, or a newly added beneficiary, warrants lower ceilings that rise with history. This is standard practice and frequently omitted.
Step-up authentication tied to risk, not to amount. A $2,000 payment to a first-time beneficiary at an account opened last week deserves more friction than a $20,000 payment to an established counterparty.
Interdiction with a specific message. When a customer overrides a warning, the warning should describe the actual scam pattern the signals suggest. "This may be a scam" is ignored. "The account you are paying was opened recently and has received first-time payments from several other customers this week" is not.
Customer education as a real control. It is the cheapest intervention available and it is usually treated as a compliance artifact rather than as loss prevention.
When it fails
There is no chargeback. Recovery means contacting the receiving institution and asking, backed by a camt.056 return request on FedNow, answered with a camt.029 that either accepts or refuses. Refusal is a permitted response, not an exception, and the funds are usually gone before anyone reads the request.
That means your recovery rate depends on speed and on relationships. The operational requirements are unglamorous: a path for customers to report suspected fraud that does not involve waiting for business hours, an internal process that contacts the receiving institution within minutes rather than days, and someone with the authority to act at 2am.
Money moves 24/7. If your fraud response operates business hours, your effective recovery window is whatever fraction of the week you are awake for.
Where liability is heading
US institutions currently bear less prescribed liability for APP fraud than UK institutions do. That gap is unlikely to persist, and the direction of travel in every comparable market has been toward greater institutional responsibility.
Our position, stated plainly because it affects how much to invest now: build controls as though reimbursement liability is coming, because the engineering takes longer than the rulemaking will, and institutions that wait for the mandate will build under time pressure with worse outcomes. The UK numbers make the sharper point. A reimbursement mandate arrived and losses still rose 19% in its first full year, which means the mandate transfers the cost rather than removing it. Whoever ends up holding that cost would rather hold it alongside working controls.
For real-time payments engineering including fraud control design, see RTP and FedNow integration. For the rail comparison, FedNow vs RTP. Or book a call.