Reducing False Positives in Watchlist Screening

More than nine in ten screening alerts are false positives, and the ones that matter arrive without the reasoning an examiner will ask for. This framework lays out the matching, policy, and agentic-resolution layers that clear the noise without losing coverage, and specifies what a defensible disposition has to contain.
Alexandre Berkovic
Reducing False Positives in Watchlist Screening
Reducing False Positives in Watchlist Screening

Alexandre Berkovic and Chrisjan Wüst · Sphinx Frameworks · 2026

TL;DR: More than nine in ten screening alerts are false positives, and the alerts that matter still get waved through when the queue is too large to read. A defensible program separates matching from the decision: generate candidates broadly, apply a versioned policy, and resolve each survivor with a written argument an examiner can replay.

Most alerts are noise

Name screening generates more alerts per true match than any other financial-crime control. Peer-reviewed work on bank screening programs puts the false-positive share at over 90 percent of all alerts (Kim and Yang, Frontiers in Artificial Intelligence, 2024). One major U.S. bank reported that of 1.1 million transactions received daily, 35,000 alerted on a potential sanctions match. Of those, 3,550 could not be cleared the same day, and 80 a day reached a central compliance function (Zytnick and Gimbert, 2021). That is tens of thousands of human touches to find a few dozen cases worth a senior analyst's attention.

The lists keep growing. Annual new OFAC listings rose from 880 in 2017 to over 3,000 in 2024, and in 2025 the SDN List absorbed another 1,764 persons (U.S. Treasury, May 2026; CNAS, January 2026). Treasury has said businesses are often forced to spend their time on low-risk matches "at the expense of focusing on high-risk, sophisticated sanctions evasion schemes." When the list owner says the list is too noisy to screen efficiently, the problem is the program around the list.

The cost shows up in enforcement, and it is rarely a matching failure. In July 2025 OFAC settled with a U.S. broker-dealer for $11,832,136 after staff "incorrectly dispositioned the sanctions alert as a false positive," and a second blocked person sat uncleared for over a month "due to a lack of resources" (OFAC, 2025). The FCA's 2024 action against a UK challenger bank is the configuration case: for five and a half years the bank screened customers only against Consolidated List individuals with UK citizenship or residency, 39 of 3,088 designated persons. For seven months the system generated no customer screening alerts at all, and nobody noticed. The penalty was £28,959,426 (FCA, 2024).

Supervisors who tested the engines directly found the same pattern. In 2024 the Swedish Finansinspektionen ran 5,000 UN and EU sanctions names through the customer-screening systems of 19 banks. Exact spellings were found 86.3 percent of the time. Manipulated spellings, the kind a real customer record carries, fell to 63.9 percent. Banks running the same vendor produced different results, which the regulator attributed to configuration (Finansinspektionen, 2024). The false-positive problem is a decision problem. Better fuzzy logic trims the margin. The alerts that remain still need an answer to "is this the same person?"

Six stages, from list to disposition

A modern screening control runs in six stages. The first three produce candidates. The last three turn candidates into decisions. Naming the stages makes it possible to ask, for each alert, exactly where the decision came from. Banks running this as a single score cannot answer that question when an examiner asks.

End-to-end watchlist screening flow: inputs feed candidate generation, then a decision stage, then the case manager.

The end-to-end screening flow. The first three stages generate candidates. The last three convert them into explainable dispositions.

Source ingestion and normalization. Sanctions lists, PEP data, adverse-media feeds, and ownership records arrive in different schemas and update cadences. Ingestion unifies them, deduplicates records that appear on several lists, and versions every snapshot so a later decision can be tied to the list state it was made against. The Wolfsberg Group is explicit that lists must be accurate, up to date, and relevant to the risks the institution is managing. Versioning is what makes "up to date" provable.

Candidate generation. A customer or counterparty record is compared against the unified index, handling aliases, transliterations, nicknames, and entity type. The goal is recall. Ten candidates, nine of them dismissed, is a better outcome than a miss.

Feature extraction. Each candidate pair is described by signals: how close the names are and by which measure, whether dates of birth or identifiers agree or conflict, how severe the listing is, how recent the record is, and whether the customer's own data is internally consistent. Nothing is decided here.

Policy application. The institution's screening policy decides which candidates become alerts, which are auto-dismissed on reliable negative evidence, and which go straight to a human. A domestic retail account, an international wire, and a corporate customer with a multi-layer ownership chain should not clear the same bar. Those thresholds are the institution's, tied to its risk appetite, and they have to be versioned. The audit question is never "what is your threshold?" It is "what was your threshold on the day this alert was closed, and can you replay the alert under it?"

Resolution and delivery. Every candidate that survives policy gets a reasoned disposition: match, no match, or escalate, with the evidence attached. The result lands in the case manager with the policy version that governed it. An alert that arrives as a bare score forces the analyst to redo the work. Sphinx's compliance agents are built to deliver that record into the queue the team already uses.

Matching is not the decision

Before any similarity is computed, both names are normalized: Unicode, case, honorifics, corporate designators, and known alias forms. Transliteration is the hard step. A name in Arabic, Cyrillic, or Chinese has several valid Latin renderings, and the noisiest variations are the ones benchmarks under-represent (Blair and Bar, LREC-COLING, 2024). The Swedish drop from 86.3 percent to 63.9 percent is that problem measured in the field.

No single method handles every variation, so a mature stack layers them. String similarity catches typos and is explainable, and it is blind to sound. Phonetic matching catches transliteration and over-matches on short names, which is why it generates candidates and never decides. Semantic matching, including across scripts, is where language models earn a place. A 2025 Federal Reserve study found that across thresholds from 80 to 95, large language models cut sanctions-screening false positives by 92 percent and raised detection 11 percent against the best fuzzy baseline. They were also more than four orders of magnitude slower, unworkable for payment screening on their own. The study's answer is a cascade: exact and fuzzy methods clear the easy cases, and the language model is reserved for the uncertain ones (Federal Reserve Board, FEDS 2025-092).

Deterministic signals then turn a name candidate into a person candidate. Agreement on a verified date of birth, a passport number, or a registered address raises confidence. Disagreement on a reliable identifier lowers it. A missing date of birth is absent evidence, and it is not a mismatch. OFAC does not expect firms to screen weak aliases as primary names; those aliases exist to confirm a hit that arose from something else (OFAC FAQ 124). Programs that screen them as names manufacture their own false positives.

Name screening also cannot satisfy the OFAC 50 Percent Rule. An entity owned 50 percent or more in the aggregate by one or more blocked persons is itself blocked, whether or not it is listed (OFAC, 2014). Ownership data has to be recomputed when the list or the cap table changes. OFSI has named inaccurate ownership assessments as a common cause of breaches.

A disposition an examiner can read

Sphinx resolves the candidates that survive policy with three agents, each with a defined role. The pattern is set out in the Interpretable Agentic Framework. The Prosecutor builds the case for a match: name similarity by each method, identifier agreement, list severity, and any PEP or adverse-media context. The Defender builds the case against, looking for reliable differentiators, a common name in the customer's country, a weak alias, a corporate designator that changes the entity type. The Judge arbitrates under the versioned policy: match, no match, or escalate. Where the two sides contradict each other, or the inputs are incomplete, the case goes to a person.

A defensible disposition contains the decision in the institution's own categories, the reasoning in plain language, the evidence attached rather than referenced, the policy version, and a tamper-evident record of every automated step and every human override. Asset-freeze candidates where confidence in a false positive is not high should always reach an analyst. Automation earns autonomy. It does not start with it. The same standard sits underneath what actually reduces false positives once the queue is in production, and it is the through-line of Financial Crime in the Age of AI.

PEP hits are the clearest example of why a match is the start of a risk assessment. FATF Recommendation 12 treats foreign PEPs as high risk and requires only reasonable measures for domestic PEPs unless other factors are present. The FCA's FG25/3 tells UK firms to start from a lower-risk position for domestic PEPs and their families. The disposition has to record which category was matched, in which country, and how current the function is. A former deputy minister and the sitting head of a state oil company both "match a PEP." They are not the same alert.

Frequently asked questions

Do I have to screen against weak aliases?

No. OFAC does not expect firms to screen weak AKAs as primary names, and expects them to be used to confirm hits that arose from other information. Screening them as names is a self-inflicted false-positive problem. The policy should say which alias classes are screened, and why.

Can I auto-dismiss on a date-of-birth mismatch?

Yes, with conditions. Wolfsberg accepts auto-discounting on reliable information that shows a clear difference, such as a material year-of-birth gap. A date of birth from a verified identity document qualifies. A self-entered web-form field may not. A missing date of birth is never a mismatch.

Does name screening satisfy the OFAC 50 Percent Rule?

No. The rule blocks entities owned 50 percent or more in the aggregate by blocked persons whether or not they are listed. Satisfying it requires ownership data and a recomputation whenever ownership or the list changes.

Read the handbook

The full framework, including adverse-media scoring, trigger models, and the practitioner playbook, is in Reducing False Positives in Watchlist Screening. Screening is one control in a stack. The same standard of an explained alert carries into behavioral transaction monitoring, where the customer, rather than the name, is the unit of detection. Institutions that want the queue argued from both sides before a person sees it can see how banks run it.

Get Your Free AI Compliance Handbook

What compliance leaders need to know about AI-driven fraud, autonomous laundering, and how your team can
fight back.
Submit
Thank you! Your submission has been received!
Something went wrong while submitting the form. Please try again.