Amir Shachar Fraud & Cyber Scientist

Fraud data science

Fraud rings and mule networks: what a graph adds, and what it cannot decide

Ring payments look normal one at a time, so the signal is in shared devices, beneficiaries and timing, and a graph score is a lead to confirm.

By
Amir Shachar · Fraud & Cyber Scientist
Published
(ET)
Reading
7 min

A payout that looks fine on its own

As an illustration with invented numbers, take a wallet product and one payout: USD 310 from a four-month-old account to a bank account the customer added last week. The amount is ordinary for that account, the device is the one it always uses, and the login came from its usual city. A model that scores this row by its own features has little to object to.

Now put the row next to its neighbours. In the same 48 hours, 22 other accounts sent between USD 150 and USD 400 to the same bank account, and 17 of the 23 senders have at some point logged in from one of two devices. No single payment in that group is unusual, and the group as a whole plainly is.

In rings and mule networks the evidence often sits in what accounts share and when they act. This post covers how to build that view cheaply, and why I treat a graph score as a lead that a person or a rule confirms before anyone's money is held.

What a mule is, and how large the surrounding losses are

Stolen money has to land somewhere. FinCEN, the US Treasury's Financial Crimes Enforcement Network, defines a money mule as "a person who transfers illegally acquired money on behalf of or at the direction of another." The same advisory, from July 2020, refers to "unwitting, witting, or complicit money mules". I come back to the unwitting ones under limits.

Three public figures for 2024 give a sense of scale, each with a caveat about scope:

  • The FBI's Internet Crime Complaint Center reports 859,532 complaints with losses of USD 16.6 billion, a 33 percent increase from 2023. That covers every kind of internet crime complaint, and it is self-reported.
  • The FTC says consumers reported losing more than USD 12.5 billion to fraud, a 25% increase over the prior year. This is also self-reported.
  • UK Finance reports that criminals stole GBP 1.17 billion through unauthorised and authorised fraud, broadly unchanged from 2023, and that authorised push payment (APP) fraud losses fell two per cent to GBP 450.7 million.

None of these counts mule accounts, and they use different definitions, so I cite them for scale only.

From rows to a graph

A graph is the same data rearranged. Nodes are the things that persist across payments: accounts, devices, beneficiary bank accounts, phone numbers. An edge records that two nodes were seen together, for example that an account logged in from a device or paid a beneficiary.

I build an edge only when a fraudster finds the link expensive to avoid and honest customers rarely share it. A beneficiary account does well on both counts, since a ring has to cash out somewhere and each receiving account must be opened or recruited. A device is good too. An IP address is usually poor, and a little arithmetic shows why. If kk accounts share one attribute value, linking them pairwise creates

(k2)=k(k−1)2\binom{k}{2} = \frac{k(k-1)}{2}

edges. As an illustration, one mobile carrier address seen on 5,000 accounts yields 12,497,500 edges, nearly all of them between strangers.

I would keep the graph bipartite (account to device, account to beneficiary) and leave out shared nodes that have had many accounts for a long time, such as a utility or a large merchant that everyone pays. A beneficiary that went from no senders to 23 in two days is a different object, which the time window below separates.

Cheap graph signals before deep ones

Before training a graph neural network (GNN), I would compute four things, all of which fit in SQL.

The first is degree: how many distinct accounts a device or a beneficiary touches. The second is a shared-attribute count per account: how many other accounts use its device or pay its beneficiary. The third is connected components: join accounts through the shared nodes you kept, then record the size of the group each account falls in, along with the group's age and its total payout volume. The fourth is fan-in over a time window. For a beneficiary bb, a time tt and a window ww,

faninw(b,t)=∣{ a:a paid b at some time s, t−w<s≤t }∣\mathrm{fanin}_w(b, t) = \left|\{\, a : a \text{ paid } b \text{ at some time } s,\ t - w < s \le t \,\}\right|

is the number of distinct senders in the window. I would pair it with the share of those senders who are paying bb for the first time. Where the receiving account is one you can see, I would add how much of what arrived left again inside the window, since the regulator's definition is about transferring money on.

In the opening illustration, 48-hour fan-in is 23, and the component built from the beneficiary and the two devices holds 23 accounts. An investigator can verify both numbers by reading a list, and they enter an existing tabular model as ordinary columns, with no graph labels needed.

A component is also reviewed as one case. In the first post of this series I argued for judging a fraud model by the alerts a team has time to open, and one case listing 23 accounts takes one slot in that queue where 23 separate alerts take 23.

A GNN can pick up structure that hand-built counts miss, such as patterns two or three hops away. I would ask it to beat the four features above at the alert volume the team can review before accepting the extra work of serving and explaining it.

What the public research shows

Weber and co-authors released in 2019 "the Elliptic Data Set, a time series graph of over 200K Bitcoin transactions (nodes), 234K directed payment flows (edges), and 166 node features, including ones based on non-public data". The domain is anti-money-laundering in Bitcoin, which is neither card fraud nor payouts, and its nodes are transactions where a payout graph would use accounts and devices. I read it as evidence that a labelled financial graph can be studied in the open.

A second line of work looks for dense subgraphs: sets of nodes with far more edges among them than the rest of the graph would suggest. FRAUDAR, by Hooi and co-authors at KDD 2016, belongs to this line. It works on bipartite graphs of users and the products they review, or of followers and followees, on the reasoning that fraudsters who add many edges create unusually large and dense regions.

Camouflage

Hooi and co-authors describe the problem this way:

Fraudsters can evade these methods using camouflage, by adding reviews or follows with honest targets so that they look "normal".

FRAUDAR is built to resist that move. The payments version is easy to imagine: ring accounts that also pay a real phone bill and receive small transfers from honest accounts. Every honest edge makes the ring's block look less dense and each member look more like a customer.

Learned models have the same exposure. Dou and co-authors wrote in 2020 that "few prior works have noticed the camouflage behavior of fraudsters, which could hamper the performance of GNN-based fraud detectors during the aggregation process." My reading, which is opinion and not the paper's wording: the mechanism is that a GNN describes a node by combining the features of its neighbours, so a fraud node that surrounds itself with honest neighbours inherits an honest-looking summary.

Camouflage is why I choose edges by what they cost to avoid: honest-looking edges are cheap to add, while the cash-out beneficiary is hard to remove. It is also a reason to keep a graph score from acting alone, since the other side can move the score by adding edges.

Limits

Graph signals fail in ways that land on people. FinCEN's wording includes unwitting mules, so some flagged accounts belong to someone who was deceived. Honest customers share things too, such as a family on one tablet or a bookkeeper paying suppliers for several clients. Components amplify the error, because one wrong edge pulls a whole household into a ring.

So I use the graph score to open a case, or to arm a rule that needs independent evidence, such as a beneficiary added in the last week together with fan-in above a threshold. A person or that rule confirms before a payout is held, and the customer has a way to contest the hold.

The graph itself is sensitive. It records who shares a home or a device and who pays whom, and an investigator's view of a component shows people who are not suspects. I would limit the case view to the linking attributes and log who opens it.

The advice to start with simple features is my judgement about cost and explainability. The public evidence cited here comes from Bitcoin and from review graphs, and I have not cited a public measurement of these four features on payout fraud. Shared-attribute features also find only rings that share something, so a network that gives each mule a clean device and a separate beneficiary leaves no edge to find, and catching it falls back on the row-level model and on reports from victims.

Sources