In transaction monitoring, false positives are reduced by adjusting scenarios rather than by raising thresholds across the board. Segment the customer base by risk profile, calibrate each scenario to the segment’s expected behavior, prioritize alerts, and track the percentage of alerts that lead to an in-depth analysis or a suspicious activity report. Each adjustment must be tested and documented to demonstrate that detection capability has not been compromised.
False Positives in Transaction Monitoring: Causes, Settings, and Controls
| Common cause | What We Observe | Adjustable | Pre-application inspection |
| A single threshold for all customers | Alerts focused on customers with typically high activity levels | Thresholds defined by customer segment | Review the history and analyze any previously reported cases that are no longer detected by the scenario |
| A scenario unrelated to the client's profile | Alerts on transactions consistent with known activity | Align the forecast with reported revenue, sales, or business activity | Ensure that customer information is up to date |
| Overlapping Scenarios | Multiple alerts for the same transaction | Group alerts by customer or by case | Keep track of each triggered scenario |
| Incomplete or incorrectly labeled data | Alerts due to incorrect description, country, or counterparty information | Correct the data at the source | Compare the number of alerts before and after the correction |
| Lack of prioritization | All alerts are assigned the same priority level | Set priorities based on the risk associated with the client and the transaction | Verify that low-priority alerts continue to be handled according to a defined procedure |
| Scripts That Have Never Been Reviewed | Scenarios that do not result in any report or no longer trigger an alert | Periodic Review of Configuration Settings | Ensure that every change is approved and documented |
In transaction monitoring, every false alarm takes time away from reviewing the transactions that really matter. Setting all thresholds solves the volume problem but creates the opposite risk: letting a suspicious transaction slip through. The approach is to address each scenario separately, while maintaining evidence that detection remains effective.
Where do false positives in transaction monitoring come from?
A false positive is a legitimate transaction that is incorrectly flagged as atypical or potentially suspicious by a monitoring system. In a working paper published by SWIFT, the professionals surveyed most often cited a false positive rate of 80 to 90 percent on traditional platforms, while the rate at which alerts were converted into suspicious activity reports generally ranged from 2 to 10 percent.
The causes stem from the diversity of user profiles and the difficulty of configuring rules that detect suspicious transactions without overwhelming the analysis. A single threshold triggers alerts for customers with high activity levels. A poorly calibrated scenario flags transactions that are consistent with the declared business activity. Incomplete data generates alerts that could have been avoided by correcting the data at the source.
False positives in screening or surveillance: What's the difference?
Screening compares a name to a list: a false positive arises from a homonym or a transliteration. Monitoring compares an action to expected behavior: an alert results from a threshold or a scenario. The mechanisms differ, with identity data used for screening and segmentation, and calibration used for monitoring.
The same issue arises with false positives in sanctions screening, and an overview of false positives in AML rounds out the topic.
How can we adjust scenarios and thresholds without compromising detection?
The configuration is based on customer knowledge and risk classification. It is tailored to the business activities and is tested before being put into operation. The joint guidelines issued by the ACPR and Tracfin in 2021—replaced by the version dated April 23, 2025—specify that monitoring systems must be tailored to the identified risks.
Segment the customer base by risk profile
A single threshold triggers alerts for customers whose activity is typically high. Segmentation involves classifying customers by risk level based on their activity, location, and behavior. Each segment is assigned thresholds consistent with its profile.
This segmentation is based on the risk classification that the institution maintains in accordance with Article L. 561-4-1 of the Monetary and Financial Code. AP Scoring allows the institution to rate customer risk based on configurable criteria organized into several categories and to update this rating throughout the course of the business relationship.
Calibrate each scenario based on historical data
A scenario describes potentially suspicious behavior, such as a split payment, a transaction inconsistent with income, or a transfer to a high-risk area. Calibration sets thresholds by simulating historical data over a representative period to detect cases that should have been flagged and to limit alerts for transactions that are consistent with the profile.
Test the setting before applying it
Before implementing a new threshold, test it against historical data. The test verifies the extent to which cases already reported to Tracfin continue to be detected and measures the expected volume of alerts. Any case that is no longer detected must be analyzed to verify that it remains covered by another scenario or that the change is duly justified. The test is documented, specifying the date, author, results, and validation. AP Monitoring offers continuous monitoring with configurable scenarios and alert prioritization.
How should we prioritize and handle the remaining alerts?
Prioritization ranks alerts based on the risk associated with the customer and the transaction. Grouping alerts by customer prevents the same situation from being processed multiple times. Processing can follow several levels of analysis: automated pre-analysis for low-priority alerts, human analysis based on rules defined by the institution, and in-depth review of high-priority alerts.
Each closed alert includes a justification. AP Scoring supports this prioritization by providing an up-to-date customer risk rating throughout the business relationship.
What metrics should be tracked to manage false positives?
| Indicator | What it measures | What a discrepancy indicates |
| Number of alerts per scenario | The weight of each scenario in the processing load | A poorly calibrated scenario or a sharp decline revealing a malfunction |
| Percentage of alerts leading to a thorough investigation or a report of a suspected incident | The Relevance of the Scenario | A scenario that doesn't detect anything useful or closes too quickly |
| Average processing time | The time between the alert and its resolution | Insufficient staff to handle the volume of production |
| Number and age of pending alerts | Unprocessed inventory | The Risk of Late Filing |
| Trigger frequency for each scenario | Actual activity under the scenario over the period | An inactive scenario that needs to be reviewed or justified |
The indicators are tracked on a rolling basis, scenario by scenario. A scenario that does not result in any reports for several months does not necessarily indicate a failure: it may cover a rare but serious risk. The key lies in the ability to justify keeping it on the list.
Does explainable AI reduce false positives?
Machine learning can refine segmentation, detect deviations from typical behavior, and prioritize alerts. Its value lies in the precision of the settings, not in a guarantee of absolute detection. However, the authorities emphasize one essential condition: the results and operation of the system must be explainable in terms of their context and purpose.
An opaque engine complicates the validation, monitoring, and auditing of the system. TheACPR’s discussion paper on the governance of artificial intelligence algorithms emphasizes, in particular, the requirements for explainability, traceability, validation, and auditing.
AP Monitoring is based on “Glass Box” augmented intelligence: scenarios, thresholds, and criteria remain explainable, traceable, and modifiable. This approach helps reduce the volume of alerts while preserving the ability to justify results and decisions.
What should you show your regulatory authority regarding your settings?
An inspection focuses on the device's detection capability and verification of its proper functioning. The items that must be made available include:
- an up-to-date risk classification;
- a description of the scenarios and thresholds;
- the tests performed before each modification;
- validation in accordance with the program's governance framework AML-CFT ;
- monitoring of indicators;
- the results of the internal audit.
List the scenarios that were not analyzed in depth during the last period and review them. Is the targeted risk still included in your classification? Does another scenario cover it?
Document the analysis, have it approved, and keep a record of it. Two topics build on this analysis: the requirements and deadlines for reporting suspicious activity, and transaction monitoring (KYT).
FAQ
What is an acceptable false-positive rate for transaction monitoring?
The guidelines do not set a general target rate. The assessment focuses on trends over time, scenario by scenario, and on the proportion of alerts that lead to an in-depth analysis or a suspicious activity report. A scenario that generates a large number of alerts without ever revealing a relevant situation must be reevaluated and, if necessary, recalibrated.
What is the difference between false positives in screening and those in surveillance?
Screening compares a name to a list: false positives can result from homonyms or transliterations, among other things. Monitoring compares an action to expected behavior: false positives result from a poorly calibrated threshold or scenario. The mechanisms differ, with identity data on one side and segmentation and tuning on the other.
Can we remove a scenario that only produces false positives?
Don’t do it without an analysis. Check whether the risk in question is still included in your classification, and then see if another scenario covers it. If you remove it, keep the analysis, tests, and validation on file: an auditor may ask why an identified risk is no longer being monitored.
Who approves a change to a threshold or scenario?
The change is approved by the person or body designated in the system’s governance framework AML-CFT. The decision is based on a test conducted prior to the system going live and records the date, the author, the reason, and the results. Internal audit then verifies that the changes comply with the established procedure.
When should you review the scenario settings?
The settings must be reviewed whenever there is a significant change in risk classification, the launch of a product or channel, or the publication of new relevant typologies by Tracfin or the supervisory authority. In addition, a periodic review is conducted according to the schedule set forth in the procedures. The indicators serve as early warnings between reviews.
