Transaction Monitoring Rules for MTOs: The Core Set and How to Tune Them

Every money transfer operator is expected to monitor transactions. Far fewer can say why each rule exists, why its threshold sits where it does, and what the last three months of alerts actually found. That gap is what examiners probe, and it is usually the difference between a monitoring programme and a list of switches.

This guide is for MLROs, compliance heads and operations leads at money transfer businesses. It covers which monitoring rules a remittance business should run, how to set starting thresholds by corridor, how to tune them once real alerts arrive, and how alerts become decisions and, where needed, suspicious activity reports. How to build and change rules safely, including testing and rollback, is covered in our companion guide on building risk rules without breaking operations.

Remittance has its own shape. Most customers send modest amounts, regularly, to a small number of family members in one or two countries. That predictability is your biggest asset: money laundering, mule activity and fraud usually show up as a break from it.

The patterns that matter most in a remittance business fall into six groups:

• Velocity and volume: a customer suddenly sending much more, or much more often, than their history or stated purpose explains.
• Structuring: amounts kept deliberately below a limit or a document threshold, often split across days or people.
• Many-to-one and one-to-many: many senders paying the same recipient, or one sender paying many unrelated recipients.
• High-risk geography: transfers, sign-ins or documents linked to high-risk or FATF call-for-action countries.
• Payment-detail reuse: the same card or account used by several customers, a common sign of mules and account takeover.
• Profile and document mismatch: what the customer said about themselves no longer matches their documents, their location or their behaviour.

Sanctions screening sits alongside these rules, not inside them. It answers a different question (is this person listed?) and must run on every sender and recipient regardless of behaviour. For a fuller list of warning signs, see our 25 red flags in transaction monitoring.

Start with a small set that covers each pattern, then add rules only when your own alerts or a new typology show a gap. The thresholds below are illustrative starting points to show the method. They are not regulatory figures and not recommendations for your corridors; set yours from your own customer data and risk assessment.

Two design points carry across every row. First, compare a customer with their own history where you can, not only with a fixed number. A sender who has sent the same amount every month for two years and suddenly sends five times as much is more interesting than a new customer sending a moderate sum. Second, give new customers their own treatment: with no history, use corridor norms until a baseline exists.

A rule's time window decides what it can see. Most programmes get this wrong by using one window for everything.

• Every transaction: for checks that should apply each time, such as a maximum single transfer for a customer's verification level.
• 1 day: for bursts. Card testing, account takeover and rushed mule activity all happen fast.
• 1 month: for structuring and fan-in. People splitting amounts rarely do it within a single day.
• 90 days: for drift. A customer whose sending creeps up over a quarter will never trip a daily rule.
• 1 year: for cumulative exposure, and for deciding when a customer's total justifies source-of-funds evidence.

Document tiers belong in the same design. As a customer's total over a window grows, ask for more: proof of address at one level, source of funds at the next. Tiers do two jobs. They gather the evidence you need before risk grows, and they create a natural point where structuring becomes visible, because people trying to avoid the next tier cluster just below it.

One threshold for the whole business is almost always wrong for most of it. Typical amounts, frequencies and purposes differ widely between corridors. A family-support corridor with small, monthly transfers and a corridor dominated by tuition or property payments need different numbers.

A practical way to set starting points:

1. Profile each corridor. From the last six to twelve months, find the typical transfer size, the typical monthly total per customer and the typical number of recipients. Use the median, not the mean; a handful of large senders distort averages.
2. Set thresholds well above typical. Start somewhere the large majority of customers will never reach in normal use, then tune. A threshold that half your customers cross is not monitoring; it is a queue.
3. Weight by risk. Corridors your risk assessment rates higher get tighter thresholds and lower document tiers. Write down why.
4. Set the currency explicitly. A threshold set in one currency drifts in meaning as exchange rates move. Define limits per sending currency.
5. Allow exceptions deliberately. Where one corridor needs different treatment, record it as an exception with a reason, not as a quiet edit to the global rule.

For handling the customers who legitimately need more than a limit allows, see our guide on AML limit overrides and exceptions.

The numbers below are illustrative, chosen to show the method. They are not benchmarks.

An operator runs two corridors. In corridor A, family support, the median transfer is around 300 in the sending currency, and most customers send once or twice a month. Corridor B carries more tuition and business payments, with a median around 1,500. Both share a document tier: above 3,000 in a month, customers must provide source of funds.

The first month. The structuring rule (3 or more transfers within 10% below the tier in a month) raises 60 alerts. Reviewers release 52 with no action. Nearly all are corridor B customers paying a term's fees in instalments that happen to sit just under the tier.

The diagnosis. The rule is right for corridor A, where a run of transfers just under 3,000 is unusual. In corridor B it is measuring the tier, not the behaviour. The tier itself is set too low for that corridor's legitimate pattern.

The change. The team adds a corridor exception for B, raising its document tier to a level supported by its own profile, and leaves corridor A unchanged. They add a recipient condition to the structuring rule: alerts in B now need the transfers to go to more than one recipient, since tuition goes to one institution. One change at a time, with the reason recorded.

The next month. 14 alerts, of which 6 are escalated, including a cluster of new customers in corridor A splitting payments to one recipient, which also trips the many-to-one rule. Two of those become suspicious activity reports.

Tuning is not lowering thresholds until the queue is quiet. It is adjusting rules so that alerts are more likely to be worth a person's time, and being able to show the evidence for each change.

• Review every rule monthly at first, then quarterly. Look at alerts raised, the share released with no action, the share escalated and the share leading to a report.
• Tighten as well as loosen. If a rule has produced nothing in two review periods, either the risk is absent or the threshold is too high. Test a lower one on past data before deciding.
• Prefer adding a condition to moving a number. Pairing a velocity signal with "new recipient" or "location mismatch" usually removes more noise than raising the threshold, and loses less coverage.
• Keep below-threshold testing. Periodically sample transfers just under each threshold. If reviewers would have escalated some, the threshold is too high.
• Record why. For each change, keep the before-and-after numbers, the reason, the approver and the date. An examiner is less interested in where a threshold sits than in whether you can explain it.
• Know when a change bites. If a rule applies the moment it is saved, a lower document tier asks existing customers for documents on their next transfer. Count them, and brief support, before you save.
• Re-check after events. A new corridor, a new payment method, a change to the FATF lists or a new typology from your regulator is a reason to review, not just the calendar.

A good rule with poor alert handling is still a weak control. Each alert should end in a recorded decision that someone else could follow.

Two habits keep handling consistent. Write a short guide per rule describing what reviewers should check and what usually explains an innocent match. And sample a share of released alerts each month for a second opinion; it catches drift in reviewer judgement before an examiner does. For a deeper treatment of reviews and case files, see AML investigation and case management for MTOs.

Monitoring exists to find activity you must report. The obligations differ by country, but the principles are steady:

• The decision sits with the MLRO, not with the rule and not with the first-line reviewer.
• Report on suspicion, not proof. The bar is reasonable grounds to suspect, not certainty.
• Write for a reader who knows nothing. Who, what, when, how much, why it is suspicious, and the indicators involved.
• Feed the result back. A filed report should inform future monitoring of that customer and their recipients, and the rules that found it.
• Do not tip off. Staff must not tell the customer that a report has been made or is being considered.

For drafting guidance, see our guide to the suspicious activity report.

RemitSo's admin panel provides the signals, limits and reporting a monitoring programme needs. See the admin features.

• AML rules per currency, paying country and payout country, with corridor exceptions: thresholds fit each corridor instead of one number for the whole business.
• Policy windows for every transaction, 1 day, 1 month, 90 days and 1 year: bursts, structuring and slow drift are each measured over the right period. Period limits, per-transfer caps and calendar windows are enforced exactly as set.
• A new rule applies at once: a tightened threshold protects you from the moment it is saved, so plan for the customers it newly asks for documents.
• Document tiers that name what to ask for as a customer's total grows: evidence is gathered before risk rises, without manual chasing.
• Every rule change reviewed before saving and kept as history, with who last changed each AML rule: you can show an examiner when and by whom each threshold was set.
• A rule set moves between installations as a file: tune on staging against test traffic, then import the same set to production, so the rules you tested are the rules that run.
• Risk indicators for the core patterns, including transaction frequency and volume, frequent transfers to the same recipient, linked transaction patterns, payment details reuse across customers, IP and payment-instrument country match, and high-risk and call-for-action country checks: the signals in this guide are ready to combine into rules.
• Risky transfers wait for a person; everything else flows on its own: reviewers see the alerts, and good customers are not held up.
• Suspicious activity reports generated, managed and submitted from the console: the decision and the report sit next to the transfer data.
• A Compliance Dashboard bringing the programme into one view, with each part granted by role: managers see workload and screening figures in one place.

Your team still sets the thresholds, reviews every alert, tunes the rules and makes each reporting decision.

Read the release notes, or book a demo to walk through AML rules and risk indicators with your own corridors in mind.