Fraud & Compliance / Learning brief
Payment fraud typologies
Your notes
In simple terms / 01
What this means in plain language
Payment fraud typologies are recognised patterns of attack — authorized push payment fraud, account takeover, and money-mule networks. Knowing each pattern's signals helps a bank detect and prevent it and protect the customer, and stays firmly on the defensive side.
A fraud typology is a recognised pattern of how payment fraud is carried out. Naming the patterns helps defenders, because each one leaves different signals. Three are common. In authorized push payment (APP) fraud, the customer is deceived into authorising a payment themselves — for example after an impersonation or a redirected invoice — which is hard to stop precisely because the payment is genuinely authorised. In account takeover, a criminal gains control of a legitimate customer's access and pays out as if they were the customer. In money-mule networks, accounts are used to receive and pass on the proceeds of fraud, adding layers that make funds harder to trace. Defences map onto the signals: name-checking the payee, watching for unfamiliar devices or new beneficiaries, adding friction when risk is high, and monitoring for the rapid in-and-out flows typical of mule accounts. The aim is to detect early and protect the customer, without blocking the many legitimate payments that look similar on the surface.
Complete lesson / 02
Understand the full idea, step by step
Doctors name diseases before they treat them, because a name carries a set of symptoms and a course of action. Fraud defenders do the same. A typology is a named pattern of how a payment fraud is carried out — and each pattern leaves its own tell-tale signals for controls to watch.
Authorized push payment fraud (APP fraud) — the genuine customer is deceived into authorising the payment themselves
In authorized push payment fraud, the customer is tricked into pushing money to an account the fraudster controls. Because the customer initiates and authenticates it, the payment is genuine in every technical sense — the login, the approval, the credentials are all really theirs. Common forms are impersonation (someone posing as the bank, a supplier, or an authority) and invoice redirection (a real payment sent to an altered account).
Why the usual defences pass it through
The layers that catch most fraud — strong authentication, device checks, credential controls — all confirm that the right person is acting. In APP fraud the right person *is* acting; they have simply been deceived. So the defence has to move upstream of authentication, to the moment the payment is set up: was the payee checked, is this a first payment to a new account, is the amount far above normal, does the session look rushed or coached? These are the signals a control can act on before Riya confirms.
Account takeover (ATO) — a criminal gains a genuine customer's access and transacts as them
In account takeover the account is genuine but the person is not: the fraudster has obtained the customer's access through stolen credentials, an intercepted one-time code, or social engineering, and then pays out as if they were the customer. Here the useful signals are anomalies, not deception cues — an unfamiliar device or location, a change to registered contact details, a new high-value payee added moments before a payment, activity at an odd hour.
Three typologies and what controls watch for
- APP fraud
- Genuine, authenticated payment; red flags are new payee, out-of-pattern amount, rushed or coached session, payee-name mismatch
- Account takeover
- Genuine account, wrong person; red flags are new device or location, changed contact details, a beneficiary added just before payout
- Money-mule receiving
- The receiving end; red flags are funds from many unrelated senders leaving almost at once, dormant accounts turning active, tight loops between accounts
How a control builds a picture from weak signals
- VALIDATION
A payee-name check returns a mismatch between the name Riya typed and the name on the receiving account. On its own, common and often innocent.
- VALIDATION
The same payment is a first-ever transfer to this payee. Also common on its own.
- VALIDATION
The amount is far above Riya's usual size, and the session shows signs of being rushed. Each weak signal, alone, would not justify stopping a legitimate payment.
- NOTIFICATION
Combined, the signals cross a threshold. The control adds friction — a specific scam warning, a confirmation step, or a short hold — aimed at interrupting a deceived authorisation without blocking the ordinary payments that share the same surface.
Where does the money go once it has been pushed out?
Often into money-mule networks — the receiving end of many frauds. These are accounts, some opened for the purpose and some belonging to people recruited or deceived, that take in proceeds and pass them onward to add distance and layers. Their signature is behavioural: funds arriving from many unrelated senders and leaving almost immediately, a dormant account turning suddenly active, clusters moving money in tight loops. Because those same patterns interest anti-money-laundering (AML) monitoring, fraud and financial-crime teams share indicators, and a confirmed mule account is frozen for investigation and closed rather than left open.
COMMON CONFUSION
“The authentication passed, so the payment must be legitimate and there is nothing to detect.”
A passed authentication only proves the right credentials were used. In APP fraud the genuine customer was deceived; in account takeover the credentials were stolen. Detection therefore looks past the login — at payee checks, anomalies, and behaviour — because the strongest frauds are the ones where the technical checks all read green.
WHAT IF — A single red flag fires — say, a payee-name mismatch — with nothing else unusual
What happens: No decisive action on its own. Blocking every mismatch would stop countless legitimate payments, since names differ for innocent reasons all the time.
How it is handled: The control weighs it alongside other weak signals. A mismatch plus a brand-new payee plus an out-of-pattern amount is a different matter from a mismatch alone. Friction is spent where signals concentrate, and every warn, hold, or release is documented so the decision can be reviewed.
STRICTLY SPEAKING
Strictly speaking, recovery once funds have moved is uncertain by design — instant rails settle in seconds and leave no overnight window to catch a payment, so controls migrate earlier, into the approval flow. Where fraud ends and a payment dispute begins, and how institutions draw those lines, varies widely between banks; the examples here are fictional and kept at the pattern level.
FOR NOW, REMEMBER
- A typology is a named pattern of payment fraud, and naming it tells defenders which signals to watch for.
- APP fraud is genuinely authorised by a deceived customer, so defences move upstream of authentication to the payment setup.
- Account takeover uses a genuine account with the wrong person, so the tells are anomalies; money mules are the receiving end, spotted behaviourally.
- No single weak signal is decisive — controls combine them, and friction is spent where the signals concentrate.
TRY IT YOURSELF
Riya logged in correctly, approved the payment herself, and passed every authentication step — then reported she had been tricked into sending it. How should a fraud control have treated this before release?
One typology deserves its own lesson because it targets businesses so precisely: fraud that impersonates a supplier or an executive to redirect a legitimate payment. Next, how it looks from the bank's side and the controls that catch it.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
In authorized push payment (APP) fraud the customer authorises the payment under deception, so defences focus on checking the payee name and adding friction when risk is high.
- 02
Account takeover uses a genuine customer's access, so the signals are anomalies in device, location, and sudden beneficiary changes that trigger step-up verification.
- 03
Money-mule networks move proceeds through accounts, and rapid in-and-out flows across linked accounts are what monitoring looks for.
Practical use cases / 04
Where you would use this
Fraud-operations teams use payee name-match results and behavioural signals to add friction or hold a payment for review before it leaves.
Digital-security teams watch authentication and device signals to catch account takeover and step up verification when access looks anomalous.
Financial-crime teams share money-mule indicators with anti-money-laundering monitoring so mule accounts can be detected and closed.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional bank, Alder Bank, protects a customer, Priya Raman, who initiates a EUR 9,500.00 transfer to a new payee. Three defensive signals combine: a Verification of Payee check returns a name mismatch, the payee account was opened 4 days earlier, and the amount is far above Priya's usual EUR 200.00 transfers. The payment is not silently blocked; the app shows a specific warning and asks Priya to confirm she knows the payee, adding deliberate friction at the risky moment. She pauses, contacts the supplier through a known number, and learns the invoice email was fraudulent. The controls worked as designed: the signals concentrated, the friction landed where it was needed, and a genuine but deceived authorisation was interrupted before the money left.
Evidence & review / 07
Evidence & review
General payment fraud typologies; payee-verification framing reflects the SEPA Verification of Payee scheme, with equivalent name-check services in other markets. Recovery and dispute boundaries are institution- and jurisdiction-specific.
What this brief simplifies: Typologies described at pattern level with fictional examples; real detection models and thresholds are held confidentially and not reproduced here.
Sources for this brief3
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal · Riya scenario and illustrative signal-combination example
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
- Scheme-specific ruleversion 1.1 (EPC218-23)
Verification Of Payee scheme rulebook ↗ — European Payments Council · Verification of Payee as an upstream payee-name check
The first rulebook version entered into force on 5 October 2025; version 1.1 was published in March 2026 to address issues found after deployment, and the EPC has announced a version 2.0 for later in 2026.
- Official requirement
The FATF Recommendations: International Standards on Combating Money Laundering and the Financing of Terrorism & Proliferation ↗ — Financial Action Task Force · Money-mule / money-laundering layering indicators and reporting
Adopted in 2012 and updated regularly since; the June 2025 FATF plenary agreed revisions to Recommendation 16 on payment transparency. Consult the live consolidated text for the current wording.