Money mule detection in transaction monitoring means writing scenarios that recognise how mule accounts behave as a group over time. The signs are many unrelated senders, fast onward movement, new or dormant accounts, and activity that does not fit the customer. This library sets out eight scenarios, each with its logic, tuning cautions and case evidence.
The scenarios identify accounts for investigation. They carry no universal thresholds, because the right values come from your own data and should be tested above and below the line before go-live. Whether a customer is a money mule within the meaning of the law is a question for prosecutors and courts, not for a monitoring rule.
The library is written for heads of AML and fraud leads who need to turn a typology into something a monitoring engine can run.
What is a money mule, and why do single-transaction rules miss it?
A money mule moves proceeds of crime through an account, and the pattern is invisible when each transaction is viewed alone.
Republic Act 12010, the Anti-Financial Account Scamming Act, defines a money mule in Section 4(a). The person must perform a listed act, such as using, lending, buying, renting or selling an account, or opening one under a false identity. The purpose must be obtaining, receiving, depositing, transferring or withdrawing proceeds known to come from crimes, offenses or social engineering schemes. The knowledge qualifier is part of the definition.
The FATF, Egmont Group and INTERPOL report on cyber-enabled fraud was published in November 2023. It notes that the laundering network of accounts typically involves money mules, and that mules are often recruited online. Mule accounts are used because funds can be received and sent quickly by electronic payment. The report also observes that fraudulent funds are rapidly layered through pass-through transactions. Splitting amounts between several accounts lets criminals get around restrictions such as withdrawal limits or monitoring thresholds.
Each of those behaviours looks ordinary in a single transaction. A modest transfer from one person to another is routine. That is why a per-transaction threshold rarely catches a mule account, and why the scenarios below depend on windows, counts and account history. Our transaction monitoring guide explains why aggregation is the capability that matters here.
How should the scenarios be built and tuned?
Define each scenario as a variable, a window and a condition, then test it on historical data before it goes live.
BSP's Memorandum M-2023-013, the guidance paper on an effective AML/CTPF transaction monitoring system, covers red flags and scenarios, system design and pre-implementation testing, and independent testing. A mule library should follow the same order. Write the logic, run it against 30 to 90 days of history to see the alert volume, adjust, then validate on live transactions before activating it. Our guide to threshold tuning covers the above-the-line and below-the-line tests that apply to every scenario here.
For each scenario below, the four fields are the pattern, the logic to build, the legitimate activity to tune against and what the case file should record.
What scenarios belong in a money-mule library?
Eight scenarios cover the behaviours that the FATF report describes and that monitoring teams commonly build.
1. Fan-in, then fast fan-out
Pattern. Many unrelated senders pay one account, and most of the value leaves within hours or days.
Logic. Count distinct senders over a window, compare outbound value with inbound value over a shorter window, and alert when both cross their parameters.
Tune against. Merchants, fundraisers, landlords, tutors and small sellers who legitimately collect from many payers. Segment by customer type so each is compared with its own peers.
Case file. The sender accounts, the onward beneficiaries, and the time between receipt and exit.
2. New account with immediate pass-through
Pattern. An account opened recently receives funds and forwards them with little or no balance retained.
Logic. Combine account age with the ratio of outbound to inbound value and the number of transactions in the first days of activity.
Tune against. Salary and savings accounts that see a legitimate burst of activity at opening.
Case file. The onboarding details, the channel used to open the account, and the first transactions in order.
3. Dormant account that wakes up
Pattern. An account with little or no activity suddenly receives and moves substantial value.
Logic. Compare current activity with a long look-back average, and alert when a dormant account exceeds a multiple of its own baseline.
Tune against. Seasonal accounts, rarely used savings accounts and accounts reactivated after a life event.
Case file. The dormancy period, any recent contact or profile changes, and the origin of the incoming funds.
4. Activity that does not fit the customer's profile
Pattern. Inflows and outflows are far larger than the declared occupation, income or purpose would suggest.
Logic. Compare monthly volume and value with the profile and the customer's risk rating, and rank by how far the account departs from its peer group.
Tune against. Customers with undeclared but legitimate income, and profiles that were never refreshed.
Case file. The profile at onboarding, the date of the last review, and the customer's explanation if one was sought.
5. Small test transactions before a larger transfer
Pattern. A series of low-value transfers precedes a much larger one, probing whether the account is being watched.
Logic. Detect a sequence of small credits or debits followed by a transfer well above the account's norm within a defined window.
Tune against. Customers who verify a new payee with a small payment, which is a normal and encouraged habit.
Case file. The sequence, the counterparties and the amount of the follow-on transfer.
6. Splitting across accounts or below limits
Pattern. Value is divided into several transfers, or across several accounts, to stay under withdrawal limits or alert thresholds.
Logic. Aggregate transfers by beneficiary, device or customer group over a window, and compare the total with the limit the individual transfers avoid.
Tune against. Regular instalment payments, payroll runs and families who share a single beneficiary.
Case file. The aggregate figure, the limit being avoided and the accounts that share the pattern.
7. Shared identifiers across unrelated accounts
Pattern. Different customers share a phone number, device, address or login environment, or one person opens accounts at several institutions in quick succession.
Logic. Link accounts on shared attributes and alert when a cluster also shows pass-through behaviour. The FATF report cites a financial intelligence unit profile of individuals who opened accounts at three or more institutions within 20 days.
Tune against. Households, shared workplaces and family devices.
Case file. The shared attributes, every linked account and the strength of each link.
8. Exposure to accounts already flagged
Pattern. An account receives from, or sends to, accounts previously reported or dispositioned as mule accounts.
Logic. Maintain an internal list of confirmed or reported accounts, and alert on first and repeat contact with them.
Tune against. Victims who sent money to a flagged account and then keep a normal relationship with their own bank.
Case file. The flagged counterparties, the basis for their listing and the direction of the flow.
What should a mule case record before it closes?
It should record the linked accounts, the timeline of value moving through them and the reason for the decision.
A mule case is usually a network, so the case should link every related account and alert into one investigation instead of opening a ticket per account. Record the first and last funds-in and funds-out times, the beneficiaries, any hold placed and the determination date if suspicion is established. The STR is due by the next working day from that determination, as set out in our guide to the STR filing window.
AFASA also lets BSP-supervised institutions temporarily hold the funds subject of a disputed transaction. The period is set by the BSP and runs up to 30 calendar days unless a court extends it. A hold and an STR are separate obligations, so the case record should be able to answer both questions. The identity side of the same problem, including synthetic and deepfake-assisted account opening, feeds scenarios 2 and 7.
How do you know the library is working?
Track the share of alerts that lead to an escalated case, per scenario, and retire or retune the ones that do not.
Review each scenario quarterly against closed cases. A scenario whose alerts are always closed as legitimate needs a tighter condition or a better peer group. A scenario that never fires may be set too tight, which is what below-the-line testing is for. Record each change, its approver and its test results, so the calibration can be shown to an examiner. For the wider supervisory picture, see our BSP Circular 950 compliance guide.
How does Fyscal ARCX support money-mule scenarios?
In Fyscal ARCX Transaction Monitoring, a compliance team defines its own variables, such as the sum, count or average of a transaction attribute over a chosen window. It then uses them in rules without an engineering ticket. Rules can be tested against historical data in a dry run before activation, and a suppression window prevents repeat alerts on a customer already under investigation. In Case Management, related alerts consolidate into one case, and cases can be merged when two customers are transacting with each other, so a mule network is investigated as one.
If you want to see how aggregation variables and merged cases work on a mule scenario, book a walkthrough of Fyscal ARCX and bring a typology you want to test.