> ## Documentation Index
> Fetch the complete documentation index at: https://docs.insightsecure.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Mule Account Graph Detection

> How network-graph analysis surfaces mule-account rings

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?**

<CardGroup cols={2}>
  <Card title="Fan-in" icon="arrows-to-dot">
    Many source accounts converging into one — consistent with a collection point aggregating funds from multiple victims or lower-tier mules.
  </Card>

  <Card title="Fan-out" icon="arrows-from-dot">
    One account rapidly distributing to many destination accounts — consistent with a layering stage, breaking a large sum into smaller, less conspicuous transfers.
  </Card>

  <Card title="Pass-through velocity" icon="gauge-high">
    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.
  </Card>

  <Card title="Shared infrastructure" icon="network-wired">
    Accounts in the same suspected ring sharing devices, IPs, or registration patterns — this is where the [Device Intelligence graph](/device-intelligence/beyond-rasp#device-to-user-graph-mapping) feeds directly into an AML case.
  </Card>
</CardGroup>

## 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

<Steps>
  <Step title="Graph model flags a cluster">
    Network topology + transaction velocity crosses a threshold, generating a candidate case — not an automatic account action.
  </Step>

  <Step title="Analyst reviews">
    Works the case in the investigation console — graph, timeline, device correlation, and transaction evidence together.
  </Step>

  <Step title="Disposition recorded">
    Confirmed mule ring, false positive, or needs-more-monitoring — every disposition is the training signal for the [self-learning feedback loop](/aml/self-learning-feedback-loop).
  </Step>

  <Step title="Evidence export">
    Confirmed cases export as a structured evidence package for regulatory filing.
  </Step>
</Steps>