The receiving side: why the account being paid is the underused signal in payment fraud

Most transaction monitoring is built from the sender’s point of view. It asks whether this customer, on this device, at this hour, for this amount, is behaving like themselves. That question is worth asking, and for account takeover it is often the right one. But three of the most expensive fraud patterns on modern payment rails share a property that sender-centric monitoring cannot see: the sender is behaving normally, and the recipient is not.

Three patterns, one shape

Authorised scams. The customer is real, authenticated, and pressing send themselves. Every identity check passes because the identity is genuine. What is unusual is the destination: an account opened recently that has been collecting from a dozen first-time senders in the last hour, and forwarding what it receives within minutes. The UK regulator’s reimbursement requirement for authorised push-payment scams, in force since 7 October 2024, splits the cost between the sending and the receiving payment firm precisely because the receiving side is where the money lands and where it can be stopped [1].

Mule networks. Money mules are accounts, recruited or opened for the purpose, that receive proceeds and move them on. Europol’s annual coordinated action against money mules has for years reported thousands of mules and mule recruiters identified across participating countries [3]. Each victim’s payment into a mule looks, from the sender’s side, like an ordinary transfer. The pattern exists only in the aggregate behaviour of the receiving account: many unrelated senders, almost nothing retained, a dormant history followed by a burst, and often a device shared with other accounts doing the same thing.

Rapid dispersal and cash-out. Once proceeds land, they are fragmented and moved, often through several hops, to the point where they leave the system: a cash-out agent, a card, a cross-border corridor. On mobile-money rails, where agents are the cash interface for hundreds of millions of accounts [5], the agent is part of the pattern. The signal is timing and structure, not any single amount.

Why the receiving side is underused

Three reasons, in our experience of building for it.

Data organisation. Institutions store payments as things their customers did. The recipient is a field on the sender’s record, not a subject with its own history. Answering “how many first-time senders has this account collected from in the last hour” requires a feature store keyed on the recipient, maintained continuously, and that is a different piece of infrastructure from a rules engine that looks at one row.

Score design. Systems that produce one number per transaction are pulled towards allow by strong identity assurance. A verified customer with multi-factor authentication drags the total down exactly when the destination should drag it up. The alternative is to keep identity assurance and behavioural risk as separate dimensions and let a recommendation be driven by the strongest of them. In our engine the identity dimension is deliberately naive: it reports what the institution asserts about who is acting, and nothing else, so it can never mask what is happening or to whom.

Popularity confusion. Naive graph approaches make everything near a busy node suspicious. A large merchant or a busy agent is connected to thousands of accounts; walking through it would taint them all. The receiving-side signals that matter are the opposite of popularity: newness, unrelatedness among senders, and speed of onward movement. Hubs must be excluded from proximity, not celebrated by it.

What a recipient-first view looks like

A recipient-first view treats every receiving account as a subject with its own baseline and returns its risk on the sender’s decision, with reasons. The reasons are concrete: recipient collected from many senders in the last hour; those senders had never paid this recipient before; most of the inflow was forwarded or cashed out within the hour; the recipient shares a device with other accounts that look the same; the recipient is within two hops of a case the institution confirmed. An analyst can read that list and know what to check. A single score cannot tell them.

It also changes what a graph is for. Instead of a visualisation after the fact, the graph answers operational questions: from this victim, where did the money go, in how many hops, and did it reach cash-out? Which recent recipients sit within two hops of confirmed cases? Which accounts share infrastructure with the ones just flagged? Those answers are candidate investigation clusters, not verdicts, and they should be presented as such.

What we can and cannot claim

We built the Sentinel Engine around this view: recipient risk, mule risk and network proximity are separate dimensions, identity trust is kept apart from them, and hubs are never walked through. On a clearly labelled synthetic demonstration the engine flags a fully verified customer’s payment to a collector account for manual review while reporting identity trust at its maximum, and traces a victim’s payment three hops to cash-out in half an hour. That shows the mechanics work as designed.

It does not show that they work on real data. No institution has run its history through the engine yet. The next step is a historical replay of a partner’s own tokenised events, with labels applied only at the time the partner learned them, and a report that says how much of the receiving-side signal was there to be found. We will publish what such replays show, with the partner’s consent, whether the result is flattering or not.

Practical questions to ask of any monitoring system

• Can it return risk for the recipient of a payment, with reasons, on the sender’s decision?
• Does strong identity assurance on the sender lower the overall score, and if so, what stops that from masking a scam?
• How is a recipient’s history maintained, and how quickly does a burst of inflow become visible?
• Does proximity to confirmed fraud exclude hubs, and what counts as a hub?
• Can it trace a payment forward to where the money left the system?
• Can every one of these answers be evaluated on your own history before anything goes live?

Sources

1. Payment Systems Regulator (UK): APP fraud reimbursement requirement, in force 7 October 2024
2. UK Finance: Annual Fraud Report
3. Europol: European Money Mule Action (EMMA)
4. FATF: Money laundering and terrorist financing risks, publications
5. GSMA: State of the Industry Report on Mobile Money

External links open the publisher’s site. Cenvoriq has no affiliation with any organisation cited.

← All research