InackGuardWho this guide is for
This guide is for compliance and operations leads at payment firms, money-service businesses and fintechs that move money for customers. It explains what transaction rules are for, the common rule types, how to choose and test thresholds, how to govern changes and how to tell whether rules work. It is practical rather than legal: your regulator and your written policies decide what you must monitor and report. Use it to plan a first rule set or to review one that has grown noisy over time.
What transaction rules do
Transaction rules look for patterns that may indicate money laundering or fraud: many payments just under a reporting threshold, money that arrives and leaves almost immediately, a dormant account that suddenly wakes up, or activity far above what a customer said to expect.
Rules are simple to describe and surprisingly hard to tune. Set a threshold too low and analysts drown in alerts. Set it too high and real activity slips through.
Common rule types
Why backtest first
Before switching a rule on, run it over the last few months of real activity and look at what it would have flagged. How many customers? How many alerts a week? Do the flagged cases look like the risk you are trying to catch?
A backtest turns threshold-setting from a guess into a decision with evidence. It also shows your team the workload before it arrives.
Governance: who can change a rule
Every rule change should record who made it, why, what the backtest showed and who approved it. Regulators look for this: a rule set that changes without a trail suggests tuning to reduce workload rather than to manage risk.
Review rules on a schedule. Look at how many alerts were closed as false positives, and whether any real cases were missed. Adjust with a reason, and backtest again.
Getting started
Begin with a small set of rules that match your actual risks, not every rule available. Backtest each, agree thresholds, switch them on, and review after the first month. Add more only when the first set is working.
A worked example
A remittance firm wants to catch pass-through activity: money arriving and leaving within 48 hours. The first threshold, any amount over $1,000, flags 140 customers in a 90-day backtest, far more than the two analysts can review. Raising it to $5,000 and requiring three such cycles in 30 days flags 12 customers and 47 transactions. The team reviews the 12: four look worth a closer look, which is a workload they can manage. They record the backtest, the reason and the approver, and switch the rule on.
Common mistakes
Checklist
A deeper look: choosing thresholds
Start from your own data, not from defaults. Look at the distribution of transaction values and frequencies for your customers, and set first thresholds where unusual behaviour begins for your business. A threshold that suits a remittance firm will be wrong for a payroll platform.
Combine conditions to cut noise. A large first payment from a new customer in a higher-risk country is more interesting than any one of those facts alone. Combinations reduce alerts without lowering vigilance.
A deeper look: segmentation
Customers behave differently by segment: individuals and businesses, small and large, domestic and cross-border. A single threshold for everyone will be too sensitive for some and too lax for others. Use customer risk ratings and segments to set different thresholds, and backtest each segment.
Questions people ask
How long should a backtest window be? Ninety days is a sensible minimum; longer windows catch seasonal patterns.
What if a backtest shows almost no alerts? Either the risk is genuinely rare in your book, or the threshold is too high. Look at the near misses before deciding.
Who should own rules? Compliance owns the logic and thresholds; engineering owns the plumbing. Changes need both a reason and an approver.
Measuring whether rules work
Track alerts per rule, the share closed as false positives, the share escalated, time to close, and any cases found by other means that a rule should have caught. Review these numbers quarterly and record what you changed and why.
A starter set for a small payment firm
If you are starting from nothing, a small set of rules covers most common risks:
Backtest each over at least 90 days, set thresholds you can review within your team's capacity, and write down the reasoning. Add velocity and activity-above-expectation rules once you hold reliable customer profiles, because those rules depend on knowing what normal looks like.
After the first month, look at every alert each rule produced. If a rule only produced noise, tighten it with a reason. If it produced cases you would not otherwise have found, keep it and consider whether a related rule would help.
Key terms
Summary
Transaction rules are simple to describe and hard to tune. Choose rules that match your real risks, set thresholds from your own data rather than defaults, and combine conditions to reduce noise. Backtest every rule over at least ninety days before switching it on, so you see both the workload and the cases it would catch. Segment customers where behaviour differs, and record every change to a rule with its reason, the backtest result and the approver. Measure rules after go-live: alerts per rule, false-positive share, escalations, time to close and anything missed. Review quarterly and adjust with evidence. Rules that are tested, governed and measured are rules you can explain to an examiner, and that is the standard to aim for from the start.