---
title: "How to reduce false positives in transaction monitoring without missing real risk"
seoTitle: "How to reduce false positives in AML transaction monitoring"
description: "Cut AML alert noise without losing real cases: a 7-step tuning process, the levers that work, the metrics to watch, and what automation should never close."
date: "2026-10-03"
updated: "2026-10-03"
category: "compliance"
author: "BlindPay Team"
howto:
  name: "How to reduce false positives in automated transaction monitoring"
  steps:
    - name: "Baseline the current metrics"
      text: "Pull at least three months of alerts and record, per rule, the alert volume, false positive rate, alert-to-case rate, SAR conversion rate, time to close, and backlog age. Tuning without a baseline can't be defended."
    - name: "Segment customers by risk and behavior"
      text: "Group customers by risk rating and by expected activity, such as payroll platforms, marketplaces, and remittance businesses, so each segment gets thresholds that fit its normal pattern."
    - name: "Set thresholds from data"
      text: "Replace vendor defaults with thresholds derived from each segment's own distribution of amounts, counts, and velocity, and write down why each value was chosen."
    - name: "Add secondary identifiers"
      text: "Require date of birth, country, registration number, or wallet address to agree before a screening hit becomes an alert, so name-only matches stop reaching analysts."
    - name: "Rank alerts by risk score"
      text: "Combine customer risk, rule severity, amount, and counterparty exposure into one score, and work the queue from the top so high-risk alerts never wait behind noise."
    - name: "Run below-the-line testing"
      text: "Sample activity just under each changed threshold and review it as if it had alerted. If real suspicious activity appears in the sample, the threshold went too far."
    - name: "Document and schedule recalibration"
      text: "Record every change with its rationale, test results, and approver, and set a recalibration date proportionate to risk, plus triggers such as a new product or corridor."
faq:
  - q: "What is a good false positive rate for AML transaction monitoring?"
    a: "There is no regulatory target. False positive rates are high across the industry because rules are built to over-catch, so the useful question is whether the rate is falling while real cases still surface. Track it per rule, not program-wide. A rule that has produced zero cases in a year needs a documented review, not a quiet deletion."
  - q: "What is below-the-line testing?"
    a: "Below-the-line testing samples activity that falls just under a rule's threshold and reviews it as if it had alerted. If the sample contains suspicious activity, the threshold is too high. If it contains nothing over several cycles, there is room to raise it. It is the standard evidence that a tuning change reduced noise without hiding real risk."
  - q: "Can automation close AML alerts without a human?"
    a: "Yes, for narrow, explainable patterns that a documented rule can clear, such as a sanctions name hit where date of birth and country both differ from the listed person. Possible true matches, wallet exposure to sanctioned addresses, and anything that could lead to a SAR need a human decision. Every auto-close should log the rule, the data used, and the version."
  - q: "What is SAR conversion rate?"
    a: "SAR conversion rate is the share of alerts, or of escalated cases, that end in a suspicious activity report. It measures how much of the monitoring output is useful to law enforcement. A very low rate usually means noisy rules. A sudden jump can mean the opposite problem: thresholds raised so far that only obvious cases still alert."
  - q: "How often should transaction monitoring rules be recalibrated?"
    a: "At a set interval written into the AML policy and proportionate to risk, with higher-risk rules reviewed more often. Recalibrate sooner when something changes: a new product, corridor, customer segment, or a jump in volume. FinCEN expects monitoring parameters to match the institution's risk, so a schedule written into the AML policy is easier to defend than ad hoc changes."
  - q: "Does reducing alerts increase regulatory risk?"
    a: "Only if it is done without evidence. Cutting alerts by raising thresholds blindly can hide real activity, which examiners treat as a control failure. Cutting them by segmenting customers, adding secondary identifiers, and deduplicating, with below-the-line testing and a written rationale, usually improves the program. The UK FCA lists poorly calibrated, unexplained rules as poor practice."
---

To reduce false positives in AML transaction monitoring, segment customers by risk and behavior, set thresholds from your own data, add secondary identifiers to screening matches, deduplicate alerts, and rank them by risk score. Then prove nothing real was lost with below-the-line testing, and document every change. Fewer alerts is the result, not the goal.

This article is general information, not legal advice. It assumes a monitoring program already exists; if you are still mapping the parts, start with [what automated risk monitoring is](/resources/more/what-is-automated-risk-monitoring-fintech).

**Key takeaways**

- A false positive is an alert that review closes as not suspicious. Most programs produce far more of these than real cases.
- High alert volume is a control weakness, not a safety margin. Real cases wait in the same queue as the noise.
- Tune with data, per customer segment, and test below the line before and after every change.
- Automation can close narrow, explainable patterns. Possible true matches and SAR decisions stay with people.
- Keep the rationale, the test results, and the approver for every change. That record is what an examiner reads.

## What counts as a false positive in risk monitoring?

A false positive is an alert that a reviewer closes because the activity turned out to be normal. A true positive is an alert that review confirms as suspicious or as a real sanctions match.

| Term | Definition | What it tells you |
| --- | --- | --- |
| False positive | An alert closed after review as not suspicious | How much analyst time goes to noise |
| True positive | An alert confirmed as suspicious activity or a real list match | Whether the rule catches what it was built for |
| Alert-to-case rate | Share of alerts escalated into a full investigation case | How often an alert needs more than a first look |
| SAR conversion rate | Share of alerts, or of cases, that end in a suspicious activity report (SAR) | How much monitoring output is useful to law enforcement |

Measure each one per rule and per segment. A program-wide rate hides the two rules that make most of the noise.

## Why is high alert volume a control weakness?

High alert volume is a weakness because analysts can't give every alert real attention, so real cases get the same rushed review as the noise. It also signals that the rules don't fit the business, which is what regulators look for first.

The UK Financial Conduct Authority (FCA) says this directly in its [Financial Crime Guide](https://handbook.fca.org.uk/handbook/FCG/3/2.html). Section FCG 3.2.5A lists, as poor practice, a weak control framework around automated monitoring, threshold-based rules used where they don't suit the activity, and poorly calibrated rule systems where the firm struggles to explain why a particular rule exists. Good practice in the same section includes a holistic view of customer behavior and monitoring at several levels of aggregation.

The Wolfsberg Group, an association of global banks that publishes financial crime standards, made the same point from the reporting side. Its [2024 Statement on Effective Monitoring for Suspicious Activity](https://wolfsberg-group.org/resources/168) argues that the growing volume of SARs isn't producing a proportionate gain in effective outcomes, and pushes programs toward outcomes over volume. The [2025 Part II statement](https://wolfsberg-group.org/resources/202) covers moving to newer approaches responsibly: validate the change, balance model risk against financial crime risk, and keep the system explainable.

In the US, FinCEN's [October 2025 SAR FAQs](https://www.fincen.gov/system/files/2025-10/SAR-FAQs-October-2025.pdf) say monitoring parameters should be commensurate with the institution's money laundering and terrorist financing risk. The same FAQs clarify that a transaction near the USD 10,000 currency transaction report threshold is not, by itself, enough to require a SAR. A rule that alerts on proximity alone and nothing else will mostly generate noise.

So the regulators agree. A noisy program is not a cautious program. It is an uncalibrated one.

## How do you tune transaction monitoring in 7 steps?

Tune in a fixed order: measure, segment, set thresholds, add identifiers, rank, test, document. Skipping the first or the last two steps is how tuning turns into a finding.

1. **Baseline current metrics.** Pull at least three months of alerts. For each rule, record volume, false positive rate, alert-to-case rate, SAR conversion rate, time to close, and backlog age.
2. **Segment customers by risk and behavior.** A payroll platform, a marketplace, and a remittance business have different normal activity. Group them by risk rating and expected pattern.
3. **Set thresholds from data.** Replace vendor defaults with values drawn from each segment's own distribution of amounts, counts, and velocity. Write down why each value was chosen.
4. **Add secondary identifiers.** A name hit alone shouldn't reach an analyst. Require date of birth, country, registration number, or wallet address to agree first.
5. **Rank alerts by risk score.** Combine customer risk, rule severity, amount, and counterparty exposure into one score, and work the queue from the top.
6. **Run below-the-line testing.** Sample activity just under each changed threshold and review it as if it had alerted. If real suspicious activity shows up, the change went too far.
7. **Document and schedule recalibration.** Record each change with its rationale, test results, and approver. Set the next review date, plus triggers like a new product, corridor, or segment.

The rule library itself is in [12 transaction monitoring red flags for stablecoin payments](/resources/more/transaction-monitoring-red-flags-stablecoin-payments).

## Which tuning levers cut false positives, and what do they risk?

Six levers do most of the work: segmentation, peer group baselines, secondary identifier matching, deduplication, risk-based prioritization, and auto-close rules. Each one cuts noise and each one can hide something if applied without evidence.

| Lever | What changes | Benefit | Risk to manage | Evidence to keep |
| --- | --- | --- | --- | --- |
| Customer segmentation | Thresholds differ by segment instead of one value for everyone | Rules stop firing on normal activity for high-volume segments | A bad actor placed in a lenient segment | Segment definitions and the assignment logic |
| Peer group baselines | A customer is compared to similar customers, not to a fixed number | Catches outliers that a flat threshold misses | Peer groups drift as the business grows | Peer group membership and refresh dates |
| Secondary identifier matching | Screening hits need date of birth, country, or ID to agree | Name-only sanctions noise drops sharply | Missing data on the record lets a real match through | Match logic and how missing fields are handled |
| Alert deduplication | Several rules firing on the same activity become one alert | Analysts review each event once | Merged alerts lose the detail of which rules fired | The rule list attached to each merged alert |
| Risk-based prioritization | Alerts are scored and worked highest first | High-risk alerts don't wait behind noise | Low-score alerts age out unreviewed | Score inputs, weights, and backlog age by band |
| Auto-close rules | Narrow, explainable patterns close without a person | Analyst time goes to real decisions | A rule broader than intended clears true matches | Rule text, version, and a sampled QA of closures |

Name matching drives most screening noise; cadence and matching choices are in [ongoing sanctions screening: how often to rescreen](/resources/more/ongoing-sanctions-screening-how-often-to-rescreen).

## What does tuning look like on 1,000 alerts a week?

Illustrative example: every number in this section is made up to show the mechanics, not drawn from any real program.

A payments company produces 1,000 alerts a week. 600 come from sanctions name screening and 400 from transaction rules.

**Deduplication.** Of the 400 transaction alerts, many are the same activity firing two or three rules (velocity, round amounts, and new counterparty, for one burst of payouts). Merging alerts on the same customer and time window turns 400 alerts into 250 events to review.

**Secondary identifiers.** Of the 600 screening alerts, most are common names where the listed person has a different date of birth and nationality. A documented rule closes hits where both identifiers are present and both disagree. That leaves 150 screening alerts where an identifier matches or is missing.

**Result.** Weekly reviews fall from 1,000 to 400. Say review still escalates 12 cases and 3 end in a SAR. SAR conversion moves from 0.3 percent of alerts to 0.75 percent, with the same cases found.

That last clause is the point. The team then samples the 450 screening closures and runs below-the-line tests on the merged transaction alerts. If the samples are clean for several cycles, the change holds. If one sample turns up a real case, the auto-close rule gets narrowed.

## What metrics show whether tuning is working?

Track six numbers per rule and per segment, every week: alert volume, false positive rate, backlog age, time to close, alert-to-case rate, and SAR conversion rate. Trends matter more than levels.

What warning signs look like:

- **False positives stay high on a rule that never produces a case.** The rule doesn't fit the business. Review it with evidence; don't delete it quietly.
- **Backlog age keeps rising.** Alerts are piling up faster than people can review them. Real cases are now waiting.
- **Time to close drops sharply with no tuning change.** Analysts may be clearing alerts without reading them. FCA guidance flags staff who always accept a customer's explanation at face value as poor practice.
- **SAR conversion jumps after a threshold increase.** The change may have removed the borderline cases along with the noise. Check the below-the-line sample.
- **Volume collapses for one segment.** Data may have stopped flowing to the rule. A silent feed failure looks exactly like successful tuning.

Report these monthly to the AML program owner. Tuning nobody above the analyst saw is hard to defend.

## What should automation close, and where must a human decide?

Automation should close alerts that a written rule can explain with data on the record. People should decide anything where the outcome is a judgment, a report, or a blocked payment.

Reasonable to auto-close, with logging:

- Screening hits where date of birth and country both disagree with the listed person.
- Duplicate alerts on an event already under review.
- Known, documented patterns, such as a customer's scheduled payroll run that matches its declared activity and history.

Keep with a person:

- Possible true sanctions matches, including partial identifier matches and missing data.
- Wallet addresses with direct or close exposure to sanctioned or illicit addresses.
- Any alert that could lead to a SAR, an account exit, or a held payment.
- Cases where Travel Rule data is missing or doesn't validate, which the [Travel Rule workflow guide](/resources/more/travel-rule-workflow-hold-return-reject) treats as a hold decision.

[Compliance agents](/resources/more/what-are-compliance-agents-in-fintech) can gather evidence and draft the narrative, but the decision stays with a named person.

## What are the common mistakes when tuning alerts?

The most common mistake is treating alert volume as the target. The others follow from it.

- **Tuning only to reduce volume.** If the goal is fewer alerts, raising every threshold works. It also blinds the program.
- **No documented rationale.** A threshold nobody can explain is the poor practice the FCA describes. Write the reason when you set the value.
- **Changing rules without testing.** Every change needs a before and after comparison and a below-the-line sample.
- **Vendor tuning with no internal understanding.** A vendor can calibrate rules, but the firm answers for them. Someone in house must be able to explain each one.
- **One threshold for every customer.** Flat thresholds fire constantly on high-volume customers and miss outliers among small ones.
- **No recalibration date.** Rules tuned once drift as products and customers change.

Picking a vendor that exposes tuning and keeps a tuning history is covered in the [risk monitoring vendor guide](/resources/more/how-to-choose-automated-risk-monitoring-vendor).

## How does BlindPay handle flagged transactions?

BlindPay runs transaction monitoring inside the payment flow, before money moves. A flagged payin or payout moves to `on_hold`, and the compliance team reviews it manually to determine whether it is a false positive.

If the flag can't be cleared internally, BlindPay sends a request for information asking about the relationship between the sender and the customer, the purpose of the transaction, and its expected outcome. If that request isn't answered within 24 hours, the transaction may be refunded to the sender. The process is described in [on-hold transactions](/docs/kb/on-hold-transactions).

## What to do next

Pull last quarter's alerts and compute the false positive rate per rule. Pick the two noisiest rules, segment their customers, and set new thresholds from data. Run a below-the-line sample before switching anything off, and write down the result. Then set the date for the next review.

## Sources and further reading

- FCA, [Financial Crime Guide, FCG 3.2](https://handbook.fca.org.uk/handbook/FCG/3/2.html), including transaction monitoring good and poor practice.
- Wolfsberg Group, [Statement on Effective Monitoring for Suspicious Activity, Part I (2024)](https://wolfsberg-group.org/resources/168).
- Wolfsberg Group, [Statement on Effective Monitoring for Suspicious Activity, Part II (2025)](https://wolfsberg-group.org/resources/202).
- FinCEN, [Frequently asked questions on SAR requirements (October 2025)](https://www.fincen.gov/system/files/2025-10/SAR-FAQs-October-2025.pdf).
- FinCEN, [31 CFR 1022.320, SAR requirements for money services businesses](https://www.law.cornell.edu/cfr/text/31/1022.320).

*This article is general information, not legal advice.*