In authorised push-payment (APP) fraud the customer sends the money themselves. They log in from their usual device, clear every authentication step, and confirm a transfer they believe is legitimate. The account is not compromised, the person is. Detection has to score whether the genuine account holder is being deceived, and that decides both what you measure and how you respond.
Standard payment-fraud models are trained against a different adversary. They learn the fingerprints of an attacker who has taken over an account: a new device, an unfamiliar network, a session that behaves nothing like the customer’s history. In an APP scam every one of those signals is clean because the real customer is doing the work. Point an account-takeover model at scam traffic and it will wave the payment through, because by its own definition nothing is wrong. Scam detection needs a separate scoring path, built on different features and a different label, with its own view of what a bad outcome even is.
The stakes are not abstract. In the UK, the Payment Systems Regulator’s mandatory reimbursement rules took effect on 7 October 2024, and the sending and receiving banks now split the cost of repaying most APP scam victims over Faster Payments. Getting detection right moved from a goodwill exercise to a direct line on the loss account.
The label problem comes first
Before any modelling, get the target right, because APP labels are quietly poisoned in ways that flatter your offline numbers.
The label you want is “this payment was a scam,” and the only reliable source is the confirmed outcome: the customer reported it, the case was worked, the beneficiary bank confirmed a mule account. That confirmation arrives days or weeks after the payment. Everything you learn in that window is contaminated for training purposes. The beneficiary account’s later reputation, the fact that fifteen other victims paid the same sort code, the customer’s own recall of the phone call, none of it existed when the payment was authorised.
So enforce point-in-time correctness ruthlessly. Freeze every feature at the authorisation timestamp and reconcile it against the payment event’s lineage.
- Beneficiary features must reflect only what was knowable before the debit, not the mule flag that got attached afterwards.
- Behavioural features must be computed from the session up to the confirm click, not the full session including the customer hanging up on a scammer.
- Never join the case-management outcome table into the feature set. It is the label’s source; if it touches the features you have built a leak.
When a scam model looks dramatically better in backtest than the account-takeover model it sits beside, assume lookahead until you have proven otherwise. Most of the apparent lift turns out to be a feature that quietly encodes the answer.
Signals that actually separate scams
A coerced payment leaves traces, but they live in the payment’s context and the customer’s behaviour rather than in their identity. These are the families worth engineering.
- Beneficiary novelty and velocity. A first-ever payment to a brand-new payee, created minutes before the transfer, to an account that has itself only existed for days. Entity resolution across the beneficiary population lets you see when one account suddenly starts receiving from many unrelated senders.
- Session friction and hesitation. Long dwell on the payment screen, repeated edits to the reference field, the payee name typed and retyped, a session that pauses as if the customer is reading a script back to someone. Weak alone, useful in combination.
- Payment purpose against profile. A “safe account” transfer, an investment payee, a conveyancing amount that matches no known property transaction, or a customer who never sends four-figure faster payments suddenly moving their whole balance.
- Concurrent phone activity where you can observe it. On mobile, a call in progress during the payment is one of the stronger coercion tells, because impersonation, investment, and romance scams nearly all run over a live call.
- Shared intelligence on the beneficiary. Sort-code-and-account matches against industry scam-reporting feeds, applied point-in-time so you only credit what was published before the payment.
No single signal is decisive. The model’s job is to fuse them into an intent-and-coercion score that a policy layer can act on, and to return it fast enough for straight-through processing on the clean majority.
Intervene without blocking the good transfers
The score chooses a level of friction, not an approve-or-decline verdict, and getting that graduation right is where a false-positive budget earns its keep. Every APP transfer is a payment the customer wants to make. Block too many and you are declining rent, deposits, and payroll; worse, the customer routes around you to a channel you cannot score at all.
Match the intervention to the score band and the scam pattern.
- Low score: straight-through, no friction. This is the overwhelming majority and it must stay invisible.
- Medium score: a targeted, payee-specific warning. Generic “are you sure” banners get dismissed on reflex. A warning that names the scam type the features are pointing at is the kind a customer actually reads.
- High score: a hard stop for a human. A cooling-off hold on the payment, a scripted outbound call, or a requirement to confirm through a second channel before the money leaves.
Every intervention writes to the audit trail: the score, the contributing features, and the action taken. A reviewer can then reconstruct why a customer was held, and you can measure whether the friction prevented a loss or merely annoyed someone. Track intervention effectiveness as its own metric. A warning that no one ever abandons a payment after is a warning that does nothing, and it is spending your friction budget for no return.
Watch drift closely, because scam scripts turn over faster than card-fraud tactics. When impersonation shifts from “your account is compromised” to “your parcel needs a release fee,” the language and the payment shapes move with it, and features tuned to last quarter’s playbook decay. Re-cut the eval set from recent confirmed cases on a regular cadence, and keep the feature store’s beneficiary intelligence fresh, or the model slides quietly back toward passing everything through.
FAQ
Why can't a standard fraud model catch APP fraud?
Most transaction models are trained to spot an attacker operating the account. In APP fraud the genuine customer is at the keyboard, on their own device, from their usual location, so the account-integrity signals that normally fire all look clean. You have to score the payment's context and the customer's state, not just their identity.
What is a good intervention that does not block the payment?
A friction step that forces the customer to slow down and confront the scam: a payee-specific warning, a cooling-off hold on first payments to a new account, or a scripted call for high-value transfers to accounts flagged in shared intelligence. The point is to break the coercion, not to decline the transaction.
How do you keep coercion signals from leaking into training?
Build the label from the confirmed-scam outcome and freeze every feature at the moment the payment was authorised. Anything learned after the customer reported the scam, including the beneficiary's later reputation, is lookahead and must be excluded, or the offline model will look far better than it performs live.