Sanctions Screening Alerts and False Positives: CGSS Guide

Table of Contents

• • Alert, False Positive and True Match
• • Exact and Approximate Matching
• • A Defensible Alert Review Workflow
• • Why Data Quality Drives Alert Quality
• • Tuning Without Creating Blind Spots
• • CGSS Exam Traps

Quick answer: A sanctions screening alert is not a confirmed match. It is a similarity signal that must be compared with identifiers, context and the applicable sanctions requirements. False positives are reduced through better data, tested matching logic and documented tuning—not by closing alerts simply because they are inconvenient.

Sanctions screening can cover customers, beneficial owners, counterparties, payments, trade documents and other relevant parties. The control works only when the correct lists and data enter the system, the matching rules fit the risk and reviewers can explain the final disposition.

Alert, False Positive and True Match

These terms describe different stages and outcomes:

Term	Meaning	Required response
Alert	The system found a possible similarity	Review and gather enough information to decide
False positive	The reviewed party is not the listed party	Close with a documented rationale
Potential match	Similarity remains after initial review	Escalate and obtain further evidence
True or confirmed match	Evidence supports that the party is the listed target	Follow the applicable legal, escalation and reporting process

An alert may be caused by a common name with no other shared identifiers. The opposite problem also matters: a weak configuration may fail to alert when a party uses an alias or a different transliteration. Screening effectiveness therefore cannot be judged only by how few alerts it produces.

Exact and Approximate Matching

Exact matching is strong when the screened value and list value are identical. It is transparent and can limit noise, but it may miss altered spellings, reversed name order, initials, aliases, missing fields or translations between writing systems.

Approximate or fuzzy matching looks for near matches. It can identify variations that literal matching misses, but broader logic usually creates more alerts. A threshold that works for a long, distinctive corporate name may not work for a short personal name.

The best exam answer is rarely “use the strictest threshold everywhere.” It is to use a risk-based, tested configuration that considers the data, population, products, jurisdictions and consequences of a missed match.

A Defensible Alert Review Workflow

1. Confirm the list record. Check the source, list version, names, aliases and available identifiers.
2. Check the screened record. Verify that the customer, payment or trade data is accurate and complete.
3. Compare primary and secondary identifiers. Names matter, but dates of birth, nationality, address, registration number, vessel identifiers and ownership information can resolve ambiguity.
4. Consider transaction context. Identify the parties, purpose, route, goods, jurisdictions and any missing or inconsistent information.
5. Escalate unresolved risk. A reviewer should not force a closure when evidence remains insufficient.
6. Document the disposition. Record what was checked, which evidence supported the decision and who approved it.
7. Take the required action. A confirmed match may require blocking, rejecting, reporting or another response under the governing regime.

The decision should remain reproducible after the reviewer has moved roles. A note such as “not the same person” is weak unless it identifies the decisive differences.

Why Data Quality Drives Alert Quality

Screening cannot compare information that was never captured. Missing dates of birth, inconsistent legal names, truncated payment fields and stale ownership records increase both false positives and missed matches.

List management matters as much as customer data. Controls should identify the list source, scope, version, update frequency, fields received and successful deployment into each relevant system. A downloaded list that never reaches one screening channel creates a control gap.

Data-quality metrics should connect to decisions. Useful questions include: Which fields are most often missing? Which source systems truncate names? Which alert types are repeatedly resolved by the same identifier? Which records were not screened after an update?

Tuning Without Creating Blind Spots

Tuning changes matching rules, thresholds, exclusions or workflow logic. A sound change process starts with a defined problem and ends with evidence that the change improved performance without creating unacceptable missed-match risk.

Testing can use known listed records, controlled spelling variations, aliases and representative customer or transaction data. Reviewers should compare results before and after the change, investigate unexpected misses and preserve approvals and test evidence.

Alert volumes alone do not prove effectiveness. A falling false-positive rate is useful only if relevant matches still surface. Independent testing should examine governance, list coverage, data lineage, matching behavior, dispositions and escalation—not just system uptime.

CGSS Exam Traps

• Alert equals violation: an alert starts review; it does not establish identity or a breach.
• More alerts equals better screening: uncontrolled noise can hide important cases and delay decisions.
• Exact matching catches everything: it can miss aliases, transliteration and incomplete inputs.
• Fuzzy matching solves every problem: broad matching without testing can overwhelm reviewers.
• Technology owns the decision: management remains accountable for configuration, validation and outcomes.
• One global action fits every match: blocking, rejecting and reporting depend on the applicable regime.

Next, connect screening decisions to sanctions due diligence and the CGSS exam guide. Explore the full practice system on the ACAMS CGSS course page.