If you work in fraud operations at a payment service provider, you almost certainly have colleagues who still conflate APP fraud with card fraud or account takeover. It's a reasonable confusion — all three end in financial loss for a customer. But the mechanisms are so different that tooling built to detect one will consistently miss the other. This guide is about explaining those differences clearly, because the gap between "we understand APP" and "we have the tools for APP" is still very wide at many PSPs we've spoken with.
The Definitional Distinction That Changes Everything
APP fraud — Authorised Push Payment fraud — is defined by a single distinguishing characteristic: the victim knowingly and intentionally initiates the payment. Compare that to the two main categories it gets confused with:
Card fraud (unauthorised): A fraudster uses stolen card credentials to make a purchase the cardholder didn't initiate and didn't know about. The cardholder's authentication was bypassed or replicated without their knowledge. The chargeback mechanism under Section 75 of the Consumer Credit Act exists precisely because the consumer was not the one pressing "confirm."
Account takeover: A fraudster gains access to the customer's account — typically via credential phishing or SIM swap — and initiates transactions while impersonating the customer. Again, the customer didn't initiate the payment. The authentication was fraudulent.
APP fraud: The customer, using their own authenticated session, on their own device, initiates a payment to a bank account they believe belongs to someone legitimate. The authentication is real. The authorisation is real. The customer's intent to pay is real. They are simply paying the wrong person — a scammer's mule account — because they have been deceived about who that person is.
This is why APP fraud defeats the detection architecture built for the other two categories. Transaction monitoring looks for anomalous patterns in authenticated sessions. If the session is genuinely the customer's, and the payment behaviour is not wildly outside their normal range, the anomaly score may be low even as the customer is actively being defrauded.
The Scam Taxonomy: Six Types PSPs Need to Know
UK Finance and the PSR categorise APP fraud into six types, each with distinct mechanics and different average loss values:
Purchase scams: The lowest average value, highest volume. A consumer pays for goods or services advertised online that don't exist — a puppy, a concert ticket, a used car. The scammer sets up a listing, collects payment, disappears. Average UK loss per incident is in the hundreds of pounds.
Impersonation — bank or police: A scammer calls or messages the consumer pretending to be their bank's fraud department, or a police officer investigating an account compromise. The consumer is persuaded to move funds to a "safe account" which is the scammer's controlled account. Average values higher, often £5,000–40,000.
Romance scams: Long-form social engineering over weeks or months. The scammer develops a fake relationship with the victim before eventually requesting money for a crisis. Average losses among the highest per victim, with significant emotional harm.
Investment scams: The scammer presents a false investment opportunity — crypto, forex, property. The victim transfers funds believing they're making an investment. Now the highest-value category by total losses in UK data, having grown substantially since 2020.
Advance fee fraud: The consumer pays an upfront fee to receive a larger sum that never materialises. Classic confidence fraud mechanics.
CEO / invoice fraud: Business-to-business variant. An employee is deceived into redirecting a legitimate invoice payment to a fraudster-controlled account, often via email compromise or impersonation of a senior executive.
Each type has a different average conversation duration before the transfer is made, a different attack channel, and different psychographic characteristics of the likely victim pool. Investment scam conversations may run for weeks; purchase scam transactions happen within minutes of a fake listing going live. A PSP's detection capability needs to account for those differences.
The APP Fraud Kill Chain
Understanding the stages helps identify where intervention is actually possible. The generic APP kill chain looks like this:
Stage 1 — Target identification: The scammer identifies a potential victim via a data breach list, social media scraping, a compromised contact list, or a mass-spam campaign. They know something about the victim — sometimes an account number, a name, a recent transaction — that makes initial contact seem credible.
Stage 2 — Initial contact and pretext establishment: The scammer reaches out via phone, messaging app, email, or social platform. They establish a plausible pretext: a fraud alert from the bank, a romantic interest, an investment opportunity, a too-good purchase listing.
Stage 3 — Trust building and objection pre-handling: The most critical stage and often the longest. The scammer anticipates every objection the victim might raise — "my bank told me not to move money to a safe account," "I should check with someone first" — and has scripted responses. They may instruct the victim not to tell the bank what the payment is really for.
Stage 4 — Payment instruction: The victim is given specific payment details — sort code, account number, payment reference — and asked to initiate the transfer. The scammer may stay on the phone during the banking app session to guide the victim through any friction the PSP introduces.
Stage 5 — Mule account receipt and laundering: The funds arrive in a mule account, often held by an unwitting participant who responded to a fake job ad or money transfer offer. Funds are typically moved within minutes — onward transfer, crypto purchase, cash withdrawal.
Detection controls that operate only at Stage 4 — the payment confirmation step — are arriving late. Stage 3 is where the deception is complete and the victim is committed. Stage 2 is where there may still be genuine uncertainty. Stage 3 interception requires visibility into the conversation channel, which is the gap AVIEL's honeybot architecture is designed to address.
Why Confirmation of Payee Wasn't Enough
Confirmation of Payee (CoP) was a significant infrastructure investment that went live progressively from 2020. It checks whether the account name provided by the payer matches the account name held by the receiving PSP. If the consumer types "HMRC Savings" and the sort code belongs to John Smith, CoP returns a warning.
CoP helps with some purchase scam scenarios where the scammer made up an account. But APP impersonation scams largely adapted. Scammers now use mule accounts whose holders have names that can be plausibly presented: "HMRC Refund Processing" is a registered account name. Investment scam recipients are often presented with legitimate-sounding corporate account names that match CoP checks because the mule account was opened with a company name that CoP can't flag as fraudulent. CoP tells the consumer whether the name matches. It doesn't tell them whether the person is a scammer.
We're not saying CoP was a wasted investment — it genuinely reduced some simple account misdirection fraud. But the APP scam ecosystem adapted to it within 18 months of widespread rollout, and the intervention point it addresses (name-to-account match) was never where the core deception in APP fraud actually lives. The deception lives in the conversation.
The Transaction Monitoring Gap
ML-based transaction scoring models trained on card fraud or account takeover data will flag on anomalies like: new payee, high velocity, unusual hour, amount outside historical range. These are good signals for unauthorised fraud. But for an APP scam targeting an investor, the payment may go to a payee the customer did look up independently (investment firm spoofed name), at a normal hour, in an amount not wildly outside their banking history, with a reference that sounds legitimate ("investment account transfer").
The model scores the transaction as low-to-medium risk. The consumer is not shown an enhanced warning. The funds move. The scammer's mule account is emptied within the hour. The PSP faces a mandatory reimbursement claim 3 days later when the consumer realises they've been defrauded.
This pattern repeats thousands of times per week across UK PSPs. The answer is not better transaction models — at least not as the sole intervention. It's visibility into the conversation layer that precedes the transaction. That's what makes APP fraud technically distinct from every fraud type that the existing stack was designed for.
What PSP Fraud Teams Should Actually Measure
Most fraud ops teams measure APP exposure by claim volume and claim value, segmented by scam type. That's necessary but not sufficient for operational improvement. The more useful measurement framework includes: average time from scam initiation to transfer (by scam type), conversion rate of warnings shown to payment abandonments (your friction actually working), and — where data permits — the originating contact channel.
The originating channel data is the hardest to get but the most valuable. If 70% of your investment scam claims originated from WhatsApp-based initial contact, that tells you where a pre-transfer interception capability needs to operate. If impersonation scam calls are coming predominantly via spoofed mobile numbers, that's a different interception architecture. The claim form is often the only data point PSPs collect at claim time — and it's frequently incomplete because the consumer is distressed, embarrassed, or coached by the scammer not to disclose the channel.
Building that originating channel data into the claims workflow is one of the cheapest improvements a PSP fraud ops team can make right now, because it directly informs which pre-transfer intervention approach will produce the highest value-per-claim reduction.