Skip to main content
Mule accounts move illicit funds through a chain of seemingly unrelated accounts to obscure their origin. Individually, each transaction in the chain can look ordinary — a transfer of a plausible amount, to a plausible-looking account. The pattern only becomes visible when you look at the network, not the transaction.

​
Why graph analysis, not transaction rules

A rules engine checking “is this transaction amount/frequency suspicious” misses mule rings by design — the whole point of a mule chain is that no single hop looks unusual. Graph analysis instead asks: does this account’s position in the transaction network match a known mule topology?

Fan-in

Many source accounts converging into one — consistent with a collection point aggregating funds from multiple victims or lower-tier mules.

Fan-out

One account rapidly distributing to many destination accounts — consistent with a layering stage, breaking a large sum into smaller, less conspicuous transfers.

Pass-through velocity

Funds arriving and leaving an account within an unusually short window, with little or no balance retained — a hallmark of an account that exists only to move money, not hold it.

Shared infrastructure

Accounts in the same suspected ring sharing devices, IPs, or registration patterns — this is where the Device Intelligence graph feeds directly into an AML case.

​
What a case looks like

When the graph model flags a cluster, the investigation console surfaces:
  1. The network graph itself — nodes are accounts, edges are transactions, sized/colored by amount and recency, so a fan-in/fan-out pattern is visually obvious rather than something an analyst has to reconstruct from a transaction list.
  2. Per-account risk contribution — which accounts in the cluster are driving the flag, and why (transaction pattern vs. shared device vs. both).
  3. Timeline view — the same network over time, since mule rings often activate and go dormant in bursts rather than operating continuously.
  4. Cross-reference to Device Intelligence — any device/session-level signals (VPN use, new device, automation indicators) already captured for accounts in the cluster.

​
From flag to case

1

Graph model flags a cluster

Network topology + transaction velocity crosses a threshold, generating a candidate case — not an automatic account action.
2

Analyst reviews

Works the case in the investigation console — graph, timeline, device correlation, and transaction evidence together.
3

Disposition recorded

Confirmed mule ring, false positive, or needs-more-monitoring — every disposition is the training signal for the self-learning feedback loop.
4

Evidence export

Confirmed cases export as a structured evidence package for regulatory filing.