Most AML screening programs are generating alerts at exactly the volume their configuration was designed to produce. The problem is that the configurations were never built for the risk profile the institution actually has.
Threshold adjustments and additional analyst headcount are the standard response, but neither addresses what generates the volume in the first place.
The decisions that drive false positive rates (how names are matched, what customer data is captured at onboarding, and how thresholds are calibrated across risk tiers) are made long before any alert reaches a queue.
This guide explains what drives alert volume and why reducing false positives in AML screening requires fixing the data and configuration behind them, not the alerts themselves.
Key takeaways:
- Not all AML false positives share the same root cause
Name-match, entity-type, geographic, and threshold-triggered false positives each originate at a different point in the screening workflow, and each requires a different fix.
- Customer data quality at onboarding sets the alert volume for the entire relationship
Records without secondary identifiers give the screening engine nothing beyond a name to anchor a match against, multiplying partial hits across every screening cycle.
- Calibration is an ongoing discipline, not a one-time setup
Default matching settings are rarely revisited after deployment, even as customer volumes grow and risk profiles change.
- Clearing alerts without documentation creates regulatory exposure
Regulators penalize programs that cannot show how each alert was reviewed and discounted, not just those that failed to screen.
- Sigma360 addresses false positive volume at the matching, alert, and prioritization layers
Entity resolution, AI-assisted clearance, and configurable risk scoring help Sigma360 clients reduce false positives by up to 93% without compromising detection.
Why AML screening generates so many false positives
Most false positive volumes are built into a screening program before it goes live. Getting them under control starts with understanding what those decisions get wrong.
Rule-based matching logic
Legacy systems compare names against watchlists using fuzzy algorithms that flag anything exceeding a similarity threshold, without accounting for context, entity type, or jurisdiction.
A corporate entity named “Global Trading Holdings” will produce a high volume of partial matches against sanctioned entities with overlapping terms, none of which represent a genuine risk.
Incomplete customer data at onboarding
When records lack date of birth, nationality, or registration number, name similarity is the only basis the screening engine has for a match. Every partial match that cannot be confirmed or ruled out automatically joins the analyst queue, a volume problem that originates at intake, not at review.
Poorly calibrated thresholds
Programs that apply the same screening depth and sensitivity to a low-risk retail customer and a high-risk politically exposed person generate alert volume with no relationship to actual risk distribution.
The 2021 interagency statement on model risk management for BSA/AML systems (issued jointly by the Federal Reserve, OCC, and FDIC) makes clear that institutions should apply risk management principles to their AML models, including setting and reviewing thresholds in line with their risk appetite.
Treating high false positive rates as a fixed cost rather than a calibration problem is precisely what that guidance was intended to address.
The four false positive types in AML screening
Each of the three structural causes generates a distinct false positive type, and addressing the wrong one leaves alert volume unchanged.
| False positive type | Root cause | Primary fix |
| Name match | Fuzzy matching returns similar-sounding names with no secondary identifier check | Entity resolution using date of birth, nationality, and registration data |
| Entity-type | Screening logic does not distinguish individual from corporate entities, generating cross-type hits | Entity type filters applied before alert creation |
| Geographic | Broad matching across jurisdictions flags entities in low-risk countries against unrelated sanctioned parties | Risk-based geographic filters and jurisdiction-level thresholds |
| Threshold-triggered | Conservative default thresholds treat all customers identically regardless of risk profile | Risk-tiered thresholds calibrated to customer risk category |
Programs that treat all false positives as a single problem and raise the overall match threshold end up trading one type of volume for another, or more consequentially, raising the risk of missing genuine matches in the process.
Read more:
How to reduce false positives in AML screening
The most effective way to reduce false positive rates is to address what generates them before they reach the review queue.
1. Fix the data before it reaches the screening engine
Most compliance teams treat false positives as a review problem. Alert volume is shaped by the quality of customer records long before any screening runs. Records without secondary identifiers (date of birth, nationality, registration number, address) generate more alerts per entity throughout the customer relationship.
Steps to address data quality at the source:
- Capture secondary identifiers for every customer at onboarding, not only for high-risk profiles.
- Validate legal entity names against corporate registry data before screening runs.
- Apply a consistent transliteration standard for non-Latin script names across all customer records.
- Review and update existing customer data as part of scheduled KYC refresh cycles.
2. Recalibrate matching logic and screening configuration
Default matching settings are often not revisited after initial deployment. Most programs go live with conservative, broad-match configurations designed to catch every possible hit, and then stay that way as customer volumes grow and alert queues accumulate.
Automated sanctions screening programs that run on default settings without periodic threshold review are particularly exposed to this problem. List updates and customer volume growth both increase alert counts while the underlying configuration stays static.
Key configuration decisions that reduce false positive volume include:
- Apply risk-tiered matching thresholds, with higher sensitivity for PEPs, high-net-worth individuals, and customers in elevated-risk jurisdictions, and calibrated thresholds for verified, lower-risk retail customers.
- Configure entity-type filters so that individual screening does not generate hits against corporate watchlist entries and vice versa.
- Set deduplication rules that prevent previously reviewed events from generating repeated alerts across monitoring cycles.
- Define and document materiality thresholds by risk category, specifying which alert types are in scope and which are not.
FATF’s risk-based approach guidance calls for concentrating screening resources where genuine risk lies and scaling back where it does not. Identical screening intensity applied across all customer tiers produces a volume problem, and no amount of analyst headcount resolves a configuration issue.
ACAMS has documented the same pattern across institutions: Programs that go live without calibrated thresholds quickly build alert backlogs that overwhelm compliance teams, and remediation must then be documented and aligned to the institution’s broader compliance framework.
3. Apply technology that reduces alert volume before analysts see it
Fixing data and configuration removes the structural causes of false positive volume. Technology addresses what persists by applying entity-aware intelligence before a hit ever becomes an alert.
Four capabilities play a role before alerts reach the review queue:
- Entity resolution models that cross-reference secondary identifiers, entity type, and jurisdiction data beyond name similarity alone, before generating a hit
- Risk scoring at the alert level that assesses materiality automatically and filters low-scoring alerts before they reach analysts
- AI-assisted match review that clears easily identifiable false positives based on confirmed identifier mismatches, with each clearance logged for audit purposes
- Perpetual monitoring that flags only genuine new developments in a customer’s risk profile, rather than re-alerting on previously reviewed events at each periodic screening cycle
A Federal Reserve Board working paper published in 2025 found that large language models, tested against common fuzzy matching algorithms in a sanctions screening context, reduced false positives by 92% while increasing detection rates by 11%.
Independent research points in the same direction. A peer-reviewed study in Future Generation Computer Systems, drawing on interviews with AML practitioners, found that AI and machine learning improve screening accuracy and reduce the false-positive burden that traditional rule-based approaches generate. The performance gap between name-matching logic and entity-aware AI is structural, not incidental.
The regulatory floor: Why over-suppression is as risky as over-alerting
Lower alert volume is a legitimate objective. The exposure comes when programs pursue it without documentation discipline, clearing alerts informally and leaving no defensible record of how each decision was reached.
Getting financial crime compliance programs past regulatory examination requires both.
The FinCEN proposed AML/CFT program rule published in April 2026 recenters enforcement expectations around program effectiveness rather than technical compliance. The proposed framework distinguishes between establishing a program and implementing it effectively, with scrutiny directed at significant or systematic failures in implementation rather than minor deficiencies.
Enforcement actions in this space consistently penalize two failures:
- Insufficient screening coverage: Programs that did not screen the right entities, at the right depth, against the right lists
- Insufficient evidence of how alerts were resolved: Programs that screened but could not show how each alert was reviewed and why it was discounted
The real examination question is: “Can you show how each alert was reviewed and why it was discounted?” Institutions that clear alerts informally to manage volume, without documented rationale, have no defensible answer, regardless of how well-calibrated their matching logic is.
The US Senate Permanent Subcommittee on Investigations’ 2012 HSBC case history documented a backlog of 17,000 unreviewed alerts and thresholds absent or miscalibrated across the bank’s highest-risk accounts.
These conditions persisted for years while the compliance function continued processing other alerts. Regulators concluded that the volume of screening activity did not constitute an effective program.
Maintaining a complete audit trail has three practical requirements:
- Every automated clearance requires a recorded rationale tied to the specific data used to make the determination.
- Configuration changes to thresholds or suppression rules require documentation showing the risk rationale behind the change.
- Analysts clearing alerts manually need a consistent, documented standard, applied case by case, with decisions logged.
Regulators reviewing AI-assisted programs will scrutinize the auditability of automated decisions, not just the volume they produced.
Read more: How AI Cuts AML Delays and Regulatory Risk
How Sigma360 reduces false positives in AML screening
Sigma360’s AI risk intelligence platform addresses false positive volume at each of the three levels covered in this guide.
At the matching layer
Screening runs against 100B+ data points spanning sanctions and watchlist data, corporate registries across 150+ countries, and 225M+ articles from 730K+ publishers.
Secondary identifiers, entity type, jurisdiction, and ownership data all feed into the match determination, so the platform distinguishes between a sanctioned individual and a customer who shares only a similar name.
At the alert layer
The Match Agent applies AI to clear false positives that can be confirmed through identifier mismatches, autonomously and with a documented rationale for each decision. Sigma360 reports that clients see up to a 93% reduction in false positives across their screening programs.
At the prioritization layer
Configurable risk scoring sets materiality thresholds by customer risk category, jurisdiction, and screening type. Higher-risk alerts are ranked by severity so analyst attention concentrates on the cases that most warrant a decision.
When AML investigations do escalate, the platform’s Entity Summary draws on watchlist records, registry data, and adverse media signals to produce a structured risk profile at the start of each review, cutting the time analysts spend assembling information before they can act.
Request a demo to see how Sigma360 reduces false positive volume across your screening program, or speak to a compliance expert about your specific alert management challenges.
FAQ
What is the difference between a false positive and a false negative in AML screening?
A false positive is a legitimate customer or transaction incorrectly flagged as suspicious. A false negative is a genuine risk the system fails to detect, and because it produces no alert, it is far harder to catch.
How often should AML screening thresholds be reviewed?
At minimum annually, and whenever customer volumes, risk appetite, or regulatory guidance change significantly. Raising the overall match threshold to manage volume trades one type of false positive for another.
Does reducing false positives require replacing existing AML systems?
Not always. Many programs achieve meaningful reductions by improving customer data quality and recalibrating thresholds before adding new technology. AI-assisted review typically layers over existing infrastructure rather than replacing it.
What metrics should compliance teams track to measure progress?
The most useful are false positive rate by screening type, alert-to-case conversion rate, average analyst review time per alert, and the proportion of alerts cleared automatically versus manually.
How do transliteration issues contribute to false positive volume?
Names in non-Latin scripts produce multiple spelling variants across systems, and without a consistent transliteration standard, the screening engine treats each variant as a separate potential match. The result is higher alert volume with no corresponding increase in genuine risk detection.
What is the difference between name screening and transaction monitoring false positives?
Name screening false positives come from matching logic: similar names, missing identifiers, or broad thresholds. Transaction monitoring false positives come from behavioral rules that flag legitimate activity patterns as suspicious. Both require separate calibration approaches.
