How to Build Risk Rules From Indicators Without Breaking Operations

A new risk rule is a change to production. Switch on a badly built one at 9am and by lunchtime your review queue has tripled, payouts are late, support is answering angry calls and the one transfer that mattered is buried under two hundred that did not. Build the same rule carefully and nobody outside compliance notices it went live.

This guide is for compliance heads, MLROs and operations leads at money transfer businesses who write and maintain the rules that decide which transfers flow and which wait for a person. It is about the craft of building rules: choosing indicators, combining them, picking an outcome, testing before go-live, and controlling change. Which monitoring patterns to run in the first place is covered in our companion guide to transaction monitoring rules for MTOs.

An indicator is a single, testable fact about a customer, a recipient, a payment or a session: is the sign-in IP from a high-risk country, does the card holder's name match the customer, has this card been used by another customer?

A rule is a decision built from indicators. Keeping the two apart is the most useful design habit you can form, for three reasons:

• Indicators are reusable. "Payment details reused across customers" is useful in a mule rule, a fraud rule and an onboarding rule. Define it once and every rule that uses it behaves consistently.
• Indicators are explainable. A reviewer sees which facts were true, not just "rule 14 fired".
• Indicators can be tested one at a time. Check how often each is true before you combine them. One that is true for most transfers is context, not a signal.

Sort your indicators into families before you write a single rule. A workable grouping for a remittance business:

• Identity: customer and holder name match, email and name match, possible duplicate customer, profile and document data mismatch, new document upload, single-word or non-alphabetic holder name.
• Lists: sanctions checks on customer, recipient and payment holder; watched names, emails and email domains; your internal watchlist.
• Geography: identity document, payment details or sign-in IP from a high-risk or FATF call-for-action country; IP and payment-instrument country match.
• Behaviour: transaction frequency and volume, frequent transfers to the same recipient, linked transaction patterns, new customer baseline.
• Payment instrument: payment details reuse, multiple payment methods, and card checks such as address match, CVC verification, chargeback history and repeated declines.
• History: internal SAR filed or reported, suspicious behaviour assignment.

Good rules usually combine indicators from different families. Two behaviour indicators together often describe one busy, legitimate customer; a behaviour indicator plus an identity mismatch is worth a person's time.

Most rule sets that break operations fail in one of two ways: single-indicator rules that fire constantly, or long chains of OR conditions that quietly match almost everything. The fix is deliberate use of AND, OR and NOT.

• AND narrows. "New customer baseline AND payment details reused across customers" is far rarer, and far more meaningful, than either alone. Use AND to pair a common indicator with a discriminating one.
• OR widens. Use it inside a group of equivalent signals, such as "sign-in IP OR identity document OR payment details from a high-risk country". Avoid OR between unrelated families; it turns one rule into several, and you lose track of why a transfer was stopped.
• NOT excludes known-good situations. "Frequent transfers to the same recipient AND NOT customer older than the baseline period" stops the rule hitting your loyal monthly senders.

Keep one rule to one story. Write the risk in a sentence before you build it ("a new customer is paying with card details another customer has already used") and name the rule after it. If you cannot write the sentence, the rule is doing too much.

The outcome is part of the rule, and it is where most operational damage happens. A rule that should have queued a transfer for review but instead holds every match will stall money you had no reason to stop.

A useful default: new rules start as pass-and-record or review, and earn the right to hold once their own results show the matches are worth stopping money for.

Also decide who hears when a rule fires. A hold nobody knows about leaves the customer waiting on an unread queue.

Every rule should have a short specification: the story, the indicators, the logic, the outcome and an owner who answers for it. The table below shows a starter set. The combinations are examples to adapt, not a recommended configuration.

Add three more fields to each specification: expected alert rate, go-live date and next review date.

The question a test answers is simple: if this rule had been live last month, what would it have done? You want three numbers before go-live:

1. Volume: how many transfers it would have stopped or queued, per day and at the busiest hour.
2. Overlap: how many of those were already caught by existing rules. A rule that mostly duplicates another adds work without adding coverage.
3. Quality: of a sample of matches, how many would a reviewer have escalated? Pull 30 to 50 and have someone other than the rule's author judge them.

Two practical ways to get them:

• Replay on an export. Apply the logic to a recent export of transfers in a spreadsheet or script. Crude, but it gives volume and a sample within an afternoon.
• Live, but passive. Switch the rule on with a pass-and-record outcome for two to four weeks. Nothing is stopped, and you see real results on real traffic, including patterns your export missed.

Plan for the busiest day, such as the run-up to a major holiday in the receive country, not the average.

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

A mid-sized operator notices three chargebacks in a month on new accounts, all paid by cards that later turned out to belong to someone else. The MLRO writes the story: "A new customer pays with a card whose holder's name doesn't match theirs."

Version 1. Indicators: new customer baseline AND customer and holder name mismatch. Outcome: hold. Replayed on last month's export of roughly 6,000 transfers, it would have held 410. A sample of 40 shows most are spouses and adult children paying with a family card, a common, legitimate pattern. At that rate the two-person review team would lose most of a day each week.

Version 2. Add a discriminating indicator from another family: AND (AVS address mismatch OR payment details reuse across customers). Replayed, it would have held 22. The sample now contains all three known chargebacks and four other cases the reviewer would have escalated. Holds are down by about 95% and the cases that matter are still caught.

Version 3, for go-live. The team keeps version 2 but starts it as manual review rather than hold for two weeks, to confirm the live rate matches the replay. It does, roughly one a day. The MLRO approves switching the outcome to hold, records the reason and sets a review date in three months. Version 1 is kept, as a pass-and-record rule, because the family-card pattern is useful context for reviewers.

A risk rule decides whether money moves. Changing one deserves the same discipline as changing an exchange rate or approving a payout.

• Limit who can change rules. Analysts can view them; a few named compliance staff change them. Watched names, emails, domains and high-risk countries feed rules directly, so treat list changes as rule changes.
• Separate author and approver. One person builds or edits a rule; another approves it. Where the team is too small, have a second person review the change after the fact and record it.
• Keep a change log: what changed, why, who made and approved it, the test result and the go-live date.
• Change one thing at a time, and tell operations and support before a new hold rule goes live.

Every rule change needs a written answer to "how do we undo this, and who decides?" before it goes live.

1. Know the last good version. Record the previous logic and outcome, so reverting is a copy, not a reconstruction from memory.
2. Set a trip wire. Agree in advance what triggers a rollback, such as the rule's queue exceeding a day's reviewer capacity.
3. Prefer softening to deleting. Moving a hold to review, or review to pass-and-record, stops the damage and keeps the evaluations.
4. Clear the backlog deliberately. Rolling back does not release what the rule already stopped; someone still decides on each.

A false positive is a transfer a rule stopped that a reviewer then released with no further action. Measure it per rule, not across the whole programme, or one noisy rule will hide behind several quiet ones.

Reviewers decide faster, and more consistently, when each trigger explains itself: which check fired, on which records, and with what evidence. A reviewer who has to reconstruct why a rule matched will release more on instinct. Do not chase a false positive rate of zero; a rule that never touches innocent customers is probably too narrow to catch anything new. For deeper review practice once a transfer is queued, see our guide to AML investigation and case management.

RemitSo's admin panel gives you the parts to build rules from and the controls around them. See the admin features.

• 46 ready-made risk indicators, from watched names and sanctions checks to profile and document mismatch, payment details reuse across customers and card checks: you build from tested parts instead of writing each signal yourself.
• Risk rules that combine indicators with logical conditions: you can write narrow, explainable rules like the ones in this guide.
• Risk triggers that read as a case file: each check that fired on a customer explains itself in plain language, links to the records that tripped it and keeps the evidence, so a reviewer can rule on a match without rebuilding it and an examiner can follow the decision later.
• Risk Radar, showing evaluated indicators and outcomes, with the same explanations: reviewers see which facts were true, and you can see how each rule is behaving.
• Risky transfers wait for a person; everything else flows on its own: holds and reviews land with your team, and good customers are not slowed down.
• Alerts with subscribers, such as "High customer risk score detected", "Transaction placed on hold" and "Transaction under manual review": the right people hear when a rule stops money.
• Separate rights to see, add, change, remove, import and export watched names, emails, email domains and high-risk countries: only the people you choose can change what feeds your rules.
• Risk rule pages behind permissions, from 89 plain-language permissions grouped into roles: you decide who can change rules and who can only view them.
• Releases tested on your staging first: platform changes reach a staging environment before production.

Your team still decides which rules to run, tests them, approves changes, keeps the change log and makes every decision on a held or queued transfer.

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