Mule Account Detection
A money mule account receives criminal proceeds and forwards them quickly — its holder is either recruited or complicit. You cannot detect one from a single transaction; you have to look at the shape of the fund flow.
Lunixi supports this two independent ways:
- Pattern detection inside a flow — catch fan-out, funnelling and rapid pass-through with counting nodes.
- Account risk screening — score an account from known mule labels and prior reports.
There is no separate muleDetection object in the response. Detection results merge into the standard decision response: decision, score, reasonCodes, flowPath. See Decision API.
1. Pattern detection inside a flow
Mule accounts have three signatures, and all three ship as ready-made templates:
| Pattern | Template | How it is measured |
|---|---|---|
| Fan-out — one sender, many distinct beneficiaries in a day | jmlsg_mt_fanout_beneficiaries_daily | distinct-count-check — unique beneficiary count |
| Funnelling — many distinct senders, one receiving account | jmlsg_mt_funnel_senders_daily | distinct-count-check — unique sender count |
| Pass-through — incoming funds leaving within minutes | jmlsg_mt_inter_arrival | inter-arrival-check — credit-to-debit gap |
Two further signals are worth adding:
- Dormancy break — an account inactive for a long period suddenly becoming active. Express it with
history-aggregate-checkas a deviation from the prior period's average. - Cumulative exposure —
jmlsg_mt_cumulative_exposure_90d; flow that never crosses a per-transaction threshold but crosses it over 90 days.
The templates carry the JMLSG reason-code prefix. When one fires, the response's reasonCodes shows exactly which typology matched — which shortens the analyst's work once a case is opened.
Example composition
distinct-count-check → 5+ distinct beneficiaries in 1 day (fan-out)
+ inter-arrival-check → credit-to-debit gap < 10 minutes (pass-through)
+ history-aggregate → account dormant for the last 30 days (dormancy break)
⇒ block + case-openThe case-open node opens the case inside the same flow — no separate call needed.
2. Account risk screening
From a flow, the sanction-account-screen node screens an account (IBAN or account number) directly. The account risk score is built from:
| Component | Contribution |
|---|---|
| Fraud report count | +25 each, capped at +80 |
| Chargeback count | +10 each, capped at +30 |
mule_account label | +40 |
fraud_payout label | +30 |
masak_reported label | +50 |
| Sanctioned account | score set to 100 |
| Blacklisted account | score at least 85 |
The score is capped at 100 and banded:
| Band | Score |
|---|---|
sanctioned | sanctions match |
blacklisted | blacklist match |
critical | ≥ 80 |
high | ≥ 50 |
medium | ≥ 25 |
low | < 25 |
What we do not do
There is no network propagation over a live transaction graph on the fraud side — no mechanism that automatically raises the risk of every account that received funds from a confirmed mule. Link analysis exists on the sanctions side, over an identity/entity graph, as an indirect-exposure calculation (the sanction-indirect-exposure node).
If you want propagation, the route available today is: when a mule is confirmed, tag the account with the mule_account label; later screenings see it as +40, and blacklist-lookup catches it too.
Related
- Transaction Monitoring — the counting nodes and all 53 templates
- Flows and Resolution — the scope you publish the flow under
- Sanctions Screening — indirect exposure and graph analysis