Transaction monitoring rules that find risk instead of noise

A transaction monitoring rule earns its place when it does three things: it maps to a risk you actually carry, it fires on data you actually send, and it produces alerts an analyst can close with a clear reason. A rule that fails any of those tests adds work without adding detection.

Tuning follows from the same test. Judge a rule by what happened to its alerts (confirmed, cleared, inconclusive), not by how many it created. A rule that raises 40 alerts a week and confirms 6 may be worth more than one that raises 5 and confirms none.

Why do most monitoring programmes drown in alerts?

Alert volume usually grows for predictable reasons, and most of them are configuration choices rather than criminal activity.

• Rules copied from a template, not from a risk assessment. A rule for cash-intensive activity makes little sense for a wallet that never touches cash.

• One amount threshold for every customer. A limit set for salaried retail users will fire all day on merchants and never on a student account being used as a mule.

• Rules that read fields nobody sends. These either never fire, which creates false comfort, or fire on defaults that mean nothing.

• Duplicate alerts for one behaviour. Ten payments that break the same rule in a day become ten tickets unless repeats are grouped.

Each of these has a fix you can make before touching a single weight.

Which rules earn their place for your business?

Start from the product, not the rule catalogue. The table below is an illustrative starting point for four common business models. It is not a regulatory checklist, and your own risk assessment should decide the final list.

Two rules deserve special care because they read as sophisticated but depend on history.

The baseline anomaly rule compares an amount with what is normal for that customer. A new customer has no history, so the comparison has to fall back to a cohort until enough events exist. Expect it to be noisier in the first weeks of a relationship.

The dormant-then-active rule only means something if dormancy is unusual in your book. For a savings product where months of silence are normal, set the dormant period long or give the rule a low weight.

What data does each rule need before it can fire?

This is a common silent failure. Behavioural rules read specific fields, and a rule with a weight but without its fields never fires. The alert queue looks calm, and the calm is meaningless.

Before tuning anything, check coverage. In Myaza Transaction Monitoring (real-time scoring of transactions and customer events), the rule configuration shows a coverage panel that flags rules which are weighted but unconfigured. The monitoring rules documentation lists the fields each built-in rule reads.

A worked example: a PSP sends payment amount, currency and customer ID, but not the counterparty, because the payout system stores beneficiaries in a separate table. Its smurfing and new-beneficiary rules are weighted at 0.6 and have never fired. The fix is an integration change, not a rule change: add the counterparty reference to each event.

How should amount limits work across currencies and customer types?

A single global amount threshold tends to produce false positives and false negatives at once. Two mechanisms help.

Per-currency limits. A ceiling set in US dollars says nothing sensible about a naira or shilling transfer once it is converted at a moving rate. Myaza holds ceilings in a base currency with optional per-currency overrides, so a ₦5,000,000 single-transaction limit and a US$5,000 limit can coexist, each applied to events in its own currency. Those figures are illustrative; set yours from your own transaction data.

Per-customer baselines. Where the product serves very different customers, a baseline rule catches a jump that is abnormal for that person even when it sits below a global limit.

The structuring pattern rule depends on the single-transaction limit. In Myaza it looks for a burst of three or more same-currency events at 70 to 100% of the limit within a window. If the limit is set far above normal activity, the band it watches is empty and the rule never fires. If it is set too low, ordinary customers fall into the band. Set the limit first, then judge the pattern rule.

How do weights and thresholds turn rules into a decision?

Every rule produces a signal between 0 and 1. Myaza combines them by weight into one composite score using a soft-OR: one strong signal can push the score high on its own, and further signals raise it with diminishing returns. The score is then compared with two cutoffs.

This shape has a practical consequence. Weights express how much a rule should be trusted on its own. A rule you would never act on alone (round amounts, for example) belongs at a low weight so it only matters alongside others. A rule that is close to conclusive (a counterparty on your blocked list) belongs near full weight.

When the built-ins do not describe a scenario, a custom rule can. A custom rule is a condition tree built from all, any and not, with its own score and weight, and it fires on alerts as custom:<name>. Keep the name meaningful, because investigators will read it on every alert and it appears on SAR reports.

How do you tune a rule without guessing?

Tuning needs outcomes. An alert closed without a label teaches you nothing, so make the label mandatory before closure. Myaza lets analysts resolve an alert as a true positive, false positive or inconclusive, and repeat firings of the same rules on the same customer fold into one alert so each label reflects one behaviour rather than ten tickets.

A tuning cycle that works in practice:

1. Pick one rule at a time. Changing three weights together makes the result impossible to attribute.

2. Read its recent labels. Count confirmed, cleared and inconclusive alerts over a period long enough to include your normal business cycle.

3. Read the cleared alerts themselves. Ten false positives from one merchant category point to a segment problem, not a threshold problem.

4. Propose the smallest change that addresses the pattern. Often that is a per-currency limit or a counterparty exclusion, not a lower weight.

5. Test it against history before saving. Myaza's Test changes replays recent scored events as a read-only test and shows how many decisions would change, with no alerts or charges created.

6. Record the reason. Write down what changed, why, and what you expect to see. The next review should check that expectation.

Two anti-patterns are worth naming. Raising the review threshold to cut volume removes alerts from every rule at once, including the ones that were working. Deleting a rule because it is noisy removes coverage of a risk you once decided you had; if the risk is still in your assessment, fix the rule instead.

A decision rule for every rule in your library

Before a rule stays on, it should pass these checks:

• It names the risk in your risk assessment that it covers.

• The fields it reads are present in live events, and you have confirmed it has fired at least once in testing.

• Its weight reflects how much you would trust it on its own.

• Its limits are set per currency where your book is multi-currency.

• Its alerts are closed with a label, and someone reviews those labels on a schedule.

• Every change to it was tested against historical events and recorded with a reason.

A rule that cannot pass those checks is not protecting you. It is either silent or noisy, and both cost you.