False positives in transaction monitoring: Why calibration matters

False positives are one of the most persistent problems in AML transaction monitoring.

When alert queues become overwhelming, the instinct is often to reduce the volume, raise a threshold, add a suppression, or narrow a rule until the queue becomes manageable.

Sometimes those changes are justified, but a shorter queue does not necessarily mean a better control.

Some false positives are inevitable; persistent, unexplained noise is different. It can be evidence that transaction monitoring rules are poorly calibrated, applied too broadly or working with weak data.

The question is not simply how do we generate fewer alerts?

It is how do we reduce unnecessary alerts without weakening the risk coverage the control was designed to provide?

What persistent false positives can tell you

If the same transaction monitoring rule repeatedly generates alerts that investigators close for the same reason, the queue is telling you something.

There are several places to look.

Thresholds

A threshold may no longer reflect normal behaviour within the population it monitors. Set it too low and legitimate activity repeatedly triggers alerts. Raise it too far and genuinely suspicious activity may disappear below the line.

Segmentation

The same threshold can behave very differently across different customer populations. A configuration appropriate for one group may create excessive noise in another, particularly where transaction patterns, products or risk profiles differ materially.

Data and rule logic

Sometimes the threshold is not the underlying problem at all. Important contextual data may be missing, inputs may be incorrectly mapped, or the rule logic may no longer represent the behaviour it was designed to identify.

These are different problems, which means they require different fixes.

That is why treating false positives purely as an analyst workload problem can be dangerous. Suppressing the alerts may make the operational symptom disappear without addressing its cause.

Why simply suppressing alerts can increase risk

A noisy transaction monitoring rule creates an obvious cost: analyst time.

The less visible risk is what happens when the response is simply to turn down the sensitivity.

Imagine a threshold change reduces alerts by 30%. On the surface, that looks like a successful calibration exercise; analysts have fewer cases to review and the queue becomes more manageable.

But what happened to the activity that no longer generates an alert?

If the change also causes materially more suspicious activity to fall below the threshold, the control has not necessarily improved. It has simply become quieter.

False positives are visible because they enter the queue. False negatives are not.

The aim of calibration should therefore be to reduce unnecessary noise while preserving appropriate detection coverage.

Diagnose before you recalibrate

Before changing a threshold, understand why the rule is generating noise.

Start with the rules responsible for disproportionate alert volumes and look at what happens to those alerts during investigation:

• •Are analysts repeatedly closing them for the same reason?
• •Does the noise concentrate within a particular customer segment?
• •Has customer behaviour changed since the threshold was set?
• •Is relevant contextual data missing?
• •Is the rule identifying the behaviour it was intended to detect?

Analyst feedback is particularly valuable here.

Investigators see the output of transaction monitoring controls every day. If they repeatedly encounter the same benign pattern, that is useful evidence about how the rule is performing. If that feedback never reaches the people responsible for calibration, the institution is discarding information that could improve the control.

Once the source of the noise is understood, teams can develop alternative configurations rather than simply increasing the threshold until alert volumes become acceptable.

What would happen if we changed the rule?

That is where backtesting becomes valuable.

Rather than changing a live transaction monitoring rule and waiting to observe the consequences, teams can apply alternative configurations to historical data and compare the results.

For each proposed change, ask:

• •How many alerts would it have generated?
• •Which existing alerts would no longer have appeared?
• •Would known suspicious cases still have been detected?
• •Does the result differ across customer segments?

This makes the trade-off visible before the control is changed.

It also allows teams to test more than one alternative.

Suppose progressively increasing a threshold produces the following pattern: the first adjustment removes a significant amount of known noise while retaining the activity you need to detect. The next removes a little more noise but starts excluding substantially more relevant activity.

Testing several configurations helps identify where additional operational efficiency begins to come at too great a cost to detection. A calibration decision can then be based on evidence rather than the size of the current alert queue.

Make the calibration decision defensible

There is rarely a single mathematically perfect threshold.

Calibration involves judgement about the behaviour being monitored, the population involved, detection coverage and the operational consequences of the resulting alerts.

That judgement should be documented.

Teams should be able to show what prompted the review, what alternatives were tested, what happened under each configuration and why the final setting was selected.

This is important from an internal model governance and a regulatory perspective. The FCA highlights poorly calibrated transaction monitoring and an inability to explain the rationale for rules and scenarios as examples of poor practice.

The difference between “we raised the threshold because analysts were overwhelmed” and “we tested several configurations and selected this threshold based on the observed impact on noise and detection” is huge.

Where technology can help

The challenge with this approach is often practical.

Testing multiple configurations against historical transaction data can be slow and resource-intensive, particularly when teams depend on technical resources to extract data, change rules or run simulations.

Fortify enables financial crime teams to backtest transaction monitoring rules and thresholds against historical data, compare alternative configurations and retain the evidence behind calibration decisions.

That makes it easier to iterate before changing a live control, rather than relying on trial and error in production.

The objective is not simply to generate fewer alerts. It is to give risk owners better evidence for deciding which alerts should be generated in the first place.

Explore Fortify Transaction Monitoring →

Signs your transaction monitoring rules may need recalibrating

Your calibration process may warrant closer attention if:

• •High-volume rules repeatedly generate alerts that analysts close for the same reason.Thresholds are applied uniformly across customer populations with materially different behaviours.
• •Threshold changes are regularly made in response to queue pressure.
• •Analyst feedback is not captured or does not reach the people responsible for calibration.
• •Teams cannot explain the evidence behind existing threshold settings.
• •Rules have not been retested following significant changes in customer behaviour, products or transaction patterns.
• •Calibration decisions are not supported by a retrievable record of what was tested and why the final configuration was selected.

Reducing false positives is a legitimate objective, but the test of a successful calibration is not simply whether the queue gets shorter.

It is whether you can reduce unnecessary noise without losing the activity the control is supposed to catch.

For a deeper methodology, read our Backtesting Rules in Transaction Monitoring guide, covering how to prepare your data, test alternative configurations, assess false negatives and build the evidence behind rule changes.

Download the guide →

‍