Detecting money-mule accounts

A money mule is an account that receives someone else’s stolen funds and passes them on within hours for a cut. The account usually belongs to a real person who passed KYC cleanly, so static onboarding checks miss it. You catch mules by watching what an account does once money it did not earn lands in it, and where it sends that money.

The tells are behavioural and relational. The hard part is timing. A recruited mule looks identical to an ordinary customer right up until the fraudulent credit arrives, and from that point you have minutes, sometimes seconds, before the outbound payment leaves. An overnight batch score is useless here. What earns its keep is a model that scores a specific inflow-then-attempted-outflow at authorisation time, using only the information that existed at that instant.

What the account does, not what it is

Start with the behaviour of a single account across its short life. The features that carry weight are almost all point-in-time: they describe the state of the account at the moment money is about to leave, using nothing from after that moment. Get the lookback windows wrong and you leak the outcome into the features, which produces a model that looks excellent in backtest and collapses in production.

The behaviours worth encoding:

• Dormant then live. An account that sits near-zero for weeks, then receives a credit and immediately attempts to forward most of it. Pass-through ratio and dwell time between credit and debit are two of the strongest single features we see.
• Balance floor. Mules tend to sweep the account close to empty on each cycle. The residual balance after outflow, as a fraction of the inflow, is informative because a genuine recipient rarely zeroes the account by design.
• Device and session mismatch at the moment of payout. The device that logs in to move the money often is not the enrolled device. This is where mule signals and account-takeover signals blur, and you should share features across both rather than build them twice.
• Onboarding-to-first-mule-flow latency. Freshly recruited accounts move stolen money soon after opening. A tight gap between account age and first large pass-through raises the score.
• Round-number and threshold-aware amounts. Outflows sized just under internal review thresholds, or split into near-equal parts, indicate someone who knows where the tripwires are.

None of these are decisive alone. A payroll account that forwards rent every month hits several of them. The model earns its keep by combining them and by conditioning on the inflow: the same outbound pattern is benign after a salary credit and suspicious after a credit from a counterparty that itself looks compromised.

The network is where the confidence is

A single account is ambiguous. The relationships between accounts are not. Mules rarely operate alone; they are the visible layer of a herding operation that fans stolen funds across many receiving accounts and collects them at a smaller number of cash-out points. That structure shows up in the transaction graph.

Build entity resolution first, because the graph is only as good as the nodes. Shared devices, shared beneficiary details, reused phone numbers, and common funding counterparties let you collapse accounts that are the same actor or the same ring. Then the relational features become available:

• Shared outbound beneficiaries. Many otherwise-unrelated receiving accounts paying into the same downstream account is one of the clearest ring signatures. The downstream account is usually closer to the cash-out.
• Fan-in and fan-out ratios at short time lags. A node that receives from many and pays to few, all within a tight window, behaves like a collector. The reverse pattern flags a distributor.
• Velocity of new edges. A cluster of accounts that suddenly starts transacting with each other, where no edges existed a week ago, is a ring spinning up.
• Distance to a known mule. Once you confirm one account, its immediate neighbours inherit elevated risk. Propagating a score two or three hops out, with decay, surfaces the rest of the ring before each one trips its own behavioural threshold.

Keep the graph point-in-time as well. It is easy to build a snapshot that includes edges formed after the transaction you are scoring, which is the relational version of lookahead and just as damaging. The lineage of every feature back to the timestamp it was valid needs to hold up when a recovery team or a regulator asks how a specific hold was decided.

Scoring, holding, and the cost of being wrong

Detection is only useful if it changes what happens to the payout. That forces two engineering decisions.

First, latency. If the score has to gate an outbound faster payment, it runs inline with authorisation and has a hard millisecond budget, so the feature store has to serve account state and the relevant slice of the graph in that budget. Features that need a full graph traversal at request time do not survive; you precompute and cache the neighbourhood risk and refresh it on a schedule and on new-edge events.

Second, the false-positive budget. Holding a legitimate payment is expensive in a way that a declined card is not, because the customer was trying to move their own money and now cannot. So the operating point sits where the review queue can actually clear it, and marginal alerts route to a step-up or a short hold rather than a hard block. A confirmed-mule label is worth a manual review; a weak behavioural flag on an established account usually is not.

Measure recall on the confirmed set and hold that eval separate from the weakly-labelled recall and chargeback data you train on, or you will convince yourself the model is better than it is. Watch drift closely, because mule tradecraft adapts fast; the amount-structuring and dwell-time patterns from two quarters ago decay, and the accounts that once sat dormant for weeks now sit dormant for days. Every hold and every release should write an audit trail with the features and the graph slice that produced it, because that record is what lets you defend a decision and what lets you retrain on your own outcomes.