How to Reduce False Positives in Sanctions Screening Without Missing Relevant Matches

To reduce false positives in sanctions screening, start by finding what causes unnecessary candidates, improve the data and configuration responsible, and test that expected relevant matches remain detectable. Raising a threshold until the queue becomes manageable is not a sufficient control strategy.

CySEC's 2025 supervisory guidance distinguishes detection effectiveness from the workload generated by a screening system. It describes systems that produced few irrelevant alerts but failed tests involving altered sanctioned names.¹ The objective is therefore not the smallest queue. It is a screening process whose detection capability and operational cost can both be explained.

This guide addresses calibration and quality assurance. For legal scope and list selection, start with the practical sanctions-screening process. For procurement, use the sanctions screening software buyer guide.

What is a sanctions-screening false positive?

A candidate alert indicates a possible match. A false positive is a candidate subsequently resolved as not being the relevant listed party. An unresolved alert is neither a confirmed match nor a proven false positive.

OFSI's UK guidance distinguishes a name match from a target match and explains how identifying information can help establish whether the screened party is the listed person.²

Keep three questions separate:

For the evidence needed on a particular alert, see how to document a sanctions alert investigation. Name matching also does not replace sanctions ownership and control analysis.

Diagnose why unnecessary alerts occur

Before changing the filter, sample reviewed non-matches and group them by cause. Keep unresolved cases outside the confirmed non-match sample. The following is a practical diagnostic framework, not a prescribed regulatory scoring model.

Do not interpret every candidate generated for an unrelated person as a matching-system defect. Some ambiguity is unavoidable when the available names are similar and distinguishing information is scarce. The practical question is whether better data or controlled configuration can remove unnecessary work without hiding relevant candidates.

Test original scripts and transliteration separately

Multilingual screening involves more than removing accents. The UK Sanctions List format includes non-Latin names and associated script and language fields.³ The FCA's May 2026 findings describe weaknesses detecting variant and non-Latin names.⁴

Preserve the original name where available. Store any normalised or transliterated form alongside it rather than silently replacing it. Then test the paths your actual customers, counterparties and sanctions sources use.

Cyrillic, Arabic and Thai are examples to include where relevant to the portfolio. They are not a regulator-prescribed universal script list or a statement that every vendor supports each cross-script path.

Test through the actual integration as well as the matching service. An interface may display a name correctly while an import, upstream field limit or normalisation step changes what reaches the screen. Record both the submitted value and the value actually screened where the system exposes it.

Use secondary identifiers as evidence, not shortcuts

OFSI describes dates of birth, nationality, addresses and identifiers as useful identity context. A different address can still leave a potential target match when other attributes align.² A single conflicting field should not become an undocumented universal clearance rule.

Understand whether a field is an exact lookup, a candidate filter, a scoring input or information shown only to reviewers. Those functions have different failure modes. A hard filter can prevent a candidate reaching review at all; a scoring signal may instead change its position or confidence. Test the documented behaviour of each workflow rather than assuming all fields work alike.

Calibrate settings against a baseline

OFAC does not recommend a universal threshold for its own search tool. It leaves the choice to users' risk assessments and compliance practices.⁵ That is guidance about OFAC's tool, not a Checklynx algorithm or numerical scale.

A practical calibration sequence is:

1. Define the sources, party types and workflows in scope.
2. Record the current configuration and source-data snapshot.
3. Build independently reviewed expected-match and non-match datasets.
4. Run the baseline and retain candidate-level results.
5. Change one setting or a clearly defined group of settings.
6. Compare missed expected matches, candidate volume and operational impact.
7. Investigate unexpected differences before approval.
8. Retain the approved configuration, test evidence and rollback plan.

Where practical, reserve a separate validation set that was not used to tune the settings. Otherwise a configuration can become good at passing a familiar test without representing the wider population.

Segmentation can help when populations genuinely differ: individuals and companies, complete and sparse records, or onboarding and payment-party inputs. Document the rationale, ensure each segment has representative tests, and test what happens when a record moves between segments. Do not select settings solely to reach a target percentage of alerts.

Keep exclusions, suppression and prioritisation distinct

These working definitions help control owners evaluate changes without relying on vendor terminology.

An exclusion is not the same as clearing a particular person against a particular source record. Nor should a name alone become a permanent permission to bypass screening.

CySEC reported missed sanctioned records caused by a deceased-person filter. Its guidance also identifies weak-alias matching as an area requiring attention.¹ Do not adopt blanket exclusions of deceased persons or weak aliases as general noise-reduction advice. Apply the requirements relevant to your regulator and test the effect on the in-scope sanctions population.

For a proposed reuse of a resolved non-match, document the following design choices:

• The customer and source-record relationship covered by the decision.
• The facts and evidence that justified the original non-match.
• Who can approve, review or revoke reuse.
• Which customer, source, alias, identifier or configuration changes trigger reconsideration.
• How previously suppressed candidates remain traceable to their original decision.
• How QA will test that suppression is neither too broad nor stale.

These are recommended controls to evaluate, not a claim that every product automatically implements them. If the system cannot detect a relevant change, define another review mechanism before relying on continued suppression.

Build a test pack that measures detection and workload

Use the following adaptable test matrix. Select sample sizes and acceptance criteria according to your risk, data and applicable supervisory expectations. A regulator's particular test-set size is not a worldwide requirement.

For every case, retain a test ID, input, expected target where relevant, rationale for the expected result, source reference and configuration. Separate an expected candidate from an expected final legal decision. The matching test generally checks retrieval; it does not prove that sanctions legally apply to the relationship.

CySEC's testing used both official control names and altered records, including misspellings and missing or duplicated words.¹ That supports testing beyond exact-name searches, without converting a particular sample result into a universal detection guarantee.

Before using real customer data, apply your organisation's access, privacy and test-environment controls. Synthetic variants of official test records can be useful, but they should not replace realistic portfolio characteristics.

Report metrics with explicit denominators

Do not compress detection, operational burden and reviewer quality into a single unexplained accuracy percentage.

Keep unresolved cases visible. Excluding the hardest cases from outcome reporting can make the apparent quality improve without any real improvement. Also distinguish candidates, unique screened subjects and screening executions: one person can generate several candidates or be screened repeatedly.

A strong change report explains which unnecessary candidates disappeared, whether any expected candidates were lost, and how reviewers' work changed. If a new miss appears, investigate it explicitly; a favourable average does not make it immaterial.

Govern changes and retesting

The FCA's 2026 findings support calibration, assurance testing and stronger oversight of exclusions and screening changes for firms in its scope.⁴ The following change record is a practical implementation recommendation:

Retest after relevant matching-engine, configuration, source-data or integration changes. Revisit the dataset when the customer population or geographic and script mix changes. Monitor production outcomes after release as well as testing before it.

An alert backlog deserves a capacity and process review alongside configuration analysis. Do not make the queue smaller by silently narrowing detection. Connect reviewer evidence to case management and retain an audit trail that distinguishes system output from authorised judgement.

How Checklynx supports the workflow

Checklynx connects sanctions screening with names, aliases, identifiers, source context and review evidence. Its sanctions product supports API, batch, customer and re-screening workflows and reuse of resolved non-match decisions. Its matching product describes profile-level identity context while retaining reviewer judgement.⁶⁷

Use matching and scoring capabilities alongside a representative test pack, and confirm the exact settings and workflow semantics in the current developer documentation. Validate script support, filtering and decision reuse on the integration you intend to operate. Your organisation retains responsibility for configuration, applicable sanctions obligations and final decisions.

Frequently asked questions

What is the best threshold for sanctions screening?

There is no universal setting. Define the source scope and expected behaviour, then compare configurations using representative positives, variations and non-matches. A vendor score should not be interpreted as a probability unless that meaning is explicitly supported.

Does fewer alerts mean better screening?

Not by itself. A restrictive configuration can reduce candidates while losing relevant variations. Demonstrate expected-match detection separately from operational efficiency.

Can a different date of birth clear a name match?

A reliable conflict may be important evidence, but it is not a universal automatic-clearance rule. Consider partial or multiple dates, source quality and the remaining identity information. Missing data is not a verified conflict.

Should previously cleared names be excluded forever?

No. Evaluate reuse of a specific resolved non-match, with evidence and conditions for reconsideration. A previous decision about one source record should not silently clear every future record with a similar name.

Should we test Cyrillic, Arabic and Thai names?

Where those scripts or their transliterations occur in your portfolio or source data, include them in testing. Test native-script and cross-script paths separately and verify support rather than assuming it.

Does passing every test prove there are no false negatives?

No. It establishes the observed result for that dataset, configuration and source state. Preserve the test boundaries, add cases as new failure patterns emerge and monitor production changes.