False positives in sanctions screening — how to handle a false hit

Legal status as of: 2026-05-20.

You run a sanctions screening check, the system returns a POSSIBLE result, and you stop dead. Is this the same person as the one on the EU sanctions list? Or is it just a coincidental name match? You cannot ignore the alert — but you also cannot automatically block the transaction without verification. This is precisely what a false positive is, and virtually every company that conducts screening will encounter one sooner or later.

This article explains what a false hit is, why it occurs, and — most importantly — how to handle it correctly and document your decision so that your company is protected both legally and operationally.

TL;DR

• A false positive (false hit) is a situation where the screening system flags a match against a sanctions list, but upon verification it turns out to be a different person or entity from the one subject to sanctions.
• False positives are inevitable — the more common the name, the greater the risk of ambiguity.
• Never dismiss an alert automatically without checking additional identifiers (date of birth, document number, country, tax identification number).
• A POSSIBLE result is a signal for manual verification, not for immediate action or immediate closure.
• Every decision — whether CLEAR or MATCH — must be documented in the hits register.
• High-quality input data and a correctly configured match threshold significantly reduce the number of false positives.

What is a false positive (false hit)

A false positive is a situation where a sanctions screening tool raises an alert — that is, it identifies a potential match between your counterparty’s data and an entry on a sanctions list — but upon careful examination it turns out to be two different people or two different entities.

Example: your client is named Aleksei Nowak and lives in Warsaw. On the EU sanctions list there is an Aleksei Nowak from Moscow, a different year of birth, a different passport. The system — operating on the basis of comparing names and their phonetic similarity — raises an alert because the match is sufficiently strong not to be ignored. This is a false positive: the alert was technically justified (the first and last names look similar), but after verification it turns out that the counterparty is not the person subject to sanctions.

A false hit is not a system error — it is a characteristic feature of every screening tool that is designed to ensure no genuine hit slips through. A better system prefers to raise too many alerts than to miss a person on the list. Your task is to process those alerts sufficiently efficiently.

Why false positives occur

False positives have several typical causes. It is worth knowing them, as this helps you understand what to look for during verification.

Common surnames and forenames. Sanctions lists — EU, UN, OFAC, and the Polish MSWiA (Ministry of the Interior and Administration) list¹ — contain hundreds of entries with names that are not unique. If you run a business operating in Russian-speaking markets or serve clients from Eastern Europe, you will encounter statistically common surnames: Ivanov, Kuznetsov, Novikov.

Cyrillic transliteration. Many individuals and entities on sanctions lists come from countries that use the Cyrillic alphabet. Their names and designations appear on lists in transliteration, that is, in a phonetic rendering using the Latin alphabet. The problem is that no single standard for Cyrillic transliteration exists — Polish, English, German, and Russian transliteration rules produce different results for the same word. The name “Александр” may be rendered as Alexander, Aleksandr, Alexandre, or Aleksander. If your client has provided data in one form and the list contains another, the system may still flag a match because the letters are similar.

Fuzzy matching, i.e. approximate matching. Screening tools do not compare names character by character — that would be too risky, because a single typo would be enough to bypass a person on the list. Instead, they use approximate matching algorithms (fuzzy matching) that measure the degree of similarity between two strings of characters. This allows the system to catch spelling variants, abbreviations, and errors. At the same time, the lower the similarity threshold, the more alerts are generated for people who only superficially resemble entries on the list.

Partial data overlap. The first and last name match, but the date of birth, country, or document number is missing or does not match. The system cannot independently determine whether this is the same person — it therefore signals a POSSIBLE result instead of immediately returning MATCH or CLEAR.

Company names. Legal entities have a problem analogous to natural persons: common words in company names (Trading, Investment, Group, International) appear repeatedly on lists and in client databases. An additional complication is the 50% ownership rule — sanctions also apply to entities in which a listed person holds more than 50% of the shares or exercises control over them². Indirect capital relationships can be difficult to establish without a dedicated tool.

Why you must not ignore or automatically dismiss an alert

This is where the biggest operational pitfall lies. Many companies, upon seeing yet another alert about a similar name with no obvious match, start “clicking CLEAR” reflexively after a week — without any real verification. This is a serious mistake.

First, if the alert turns out to be a genuine hit (MATCH) and you dismissed it without verification and went ahead with a transaction involving a sanctioned person, you are liable for breaching an EU regulation³. EU regulations are directly applicable in all Member States — you do not need a national statute to be bound⁴. An administrative penalty for breaching sanctions rules can reach up to PLN 20,000,000⁵.

Second, in the event of an inspection by a supervisory authority (in Poland, penalties are imposed by the Head of KAS — the National Revenue Administration⁶), you must be able to demonstrate that you verified every alert and that your decision was supported by specific data. “It looked different” is not a justification. “I checked the date of birth, passport number, and country — the data does not match the list entry, decision: CLEAR” — that is a justification.

Third, automatically dismissing alerts without documentation defeats the purpose of conducting screening. If you ever have to prove that you acted with due diligence, the absence of documented verification will be evidence against you, not in your favour.

How to handle a POSSIBLE result — step by step

A POSSIBLE result means: “the system has found a potential match but is not certain — someone must check this manually.” Below is a practical process you can implement in your company.

Step 1. Do not block the transaction immediately, but place it on hold pending resolution.

Do not proceed with the transaction until the alert has been resolved. At the same time, do not treat the hold as a decision — it is merely an operational pause that gives you time for verification.

Step 2. Compare the list entry with the counterparty’s data, identifier by identifier.

Go to the entry on the sanctions list — if you are unsure how to read an entry on a sanctions list, start there — and compare it with the data you hold on the counterparty:

• first and last name (all variants from the list, including transliterations),
• date and place of birth,
• document number and type (passport, identity card),
• nationality and country of residence,
• for companies: registration number, country of incorporation, registered address.

One non-matching identifier is not in itself sufficient reason to dismiss the alert. Several non-matching identifiers with no overlap whatsoever beyond name similarity — that is a solid basis for closing as CLEAR.

Step 3. Check the list of alternative names and aliases.

EU sanctions list entries often contain a section with aliases, pseudonyms, and alternative transliterations. Check whether your counterparty appears under any of those variants. If your tool does not display this data, check directly in the European Commission’s consolidated database⁷ or on the EU Sanctions Map⁸.

Step 4. Obtain missing data from the counterparty if you do not have it.

If you do not have enough identifiers (for example, you only have a first name, last name, and country, and the date of birth is missing), ask the counterparty for an identity document. This is standard due diligence procedure and the counterparty should not be surprised — especially if you cite compliance requirements.

Step 5. Make a decision and document it.

Based on the data gathered, you make a decision: CLEAR (the match has been excluded with sufficient certainty) or MATCH (the match has been confirmed — escalate in accordance with your internal procedure). The decision must be documented — see the section below.

When to close as CLEAR and when to escalate to MATCH

Closing as CLEAR is justified when:

• at least two independent identifiers (e.g. date of birth and document number) unambiguously distinguish your counterparty from the person on the list,
• the alternative names and aliases in the list entry do not match the counterparty’s data,
• the counterparty has provided an identity document that confirms the data are different.

The more identifiers confirming the absence of a match, the safer the CLEAR decision. One identifier is the minimum — for large transactions or high-risk industries it is advisable to have two or three.

Escalation to MATCH is necessary when:

• several key identifiers (e.g. first name, last name, date of birth, nationality) overlap with the list entry,
• the counterparty refuses to provide documents enabling verification,
• a comparison of aliases reveals additional overlaps,
• you have doubts that you cannot resolve with the available data.

In the event of a MATCH, you do not proceed with the transaction, you freeze any assets in your possession, and you immediately refer the matter to the designated person responsible for compliance in your company. Further steps depend on the type of sanctions and the competent authority.

Bear in mind: the “in dubio” principle works in reverse here compared to criminal law. When in doubt — escalate, do not close.

How to document a false positive decision

Documentation is not a formality — it is your evidence of due diligence in the event of an inspection. Every alert resolution, whether it resulted in CLEAR or MATCH, must be entered in the sanctions hits register.

The minimum scope of documentation for a CLEAR decision should include:

• the date and time of the alert and the date and time the decision was made,
• the counterparty data that triggered the alert,
• the identifier of the sanctions list entry that the system matched against the counterparty (list name, entry number or alias),
• the verification identifiers used and their outcome (e.g. “counterparty date of birth: 1978-03-15, list entry: 1963-07-02 — non-match confirmed”),
• the name of the person who made the decision,
• a justification of the decision in one or two sentences.

For a MATCH decision, a record of the actions taken is also required: who received the escalation and when, and what remedial measures were applied.

The register can be maintained in a simple spreadsheet or a dedicated module of the screening system. What matters is that it is accessible, complete, and chronological. We discuss how to build a complete counterparty verification procedure for sanctions in a separate article.

How to reduce the number of false positives

The number of false positives depends on two factors: the quality of input data and the configuration of the screening tool. You have influence over both.

Better quality input data. The more identifiers you collect from the counterparty at the onboarding stage, the less often the system will be forced to guess. Instead of just a first and last name, collect: date of birth, country, identity document number, or tax identification number (NIP/REGON) for companies. The onboarding form is the best place to collect this data naturally.

The right similarity threshold. Screening tools allow you to set how great the name similarity must be for the system to raise an alert. Too low a threshold = a flood of false positives. Too high a threshold = the risk that a genuine hit will be missed because of a typo. The optimal threshold depends on the specifics of your client base and must be a deliberate decision — not a default setting that someone configured at implementation and then forgot about.

Keeping counterparty data up to date. If your counterparty data is old or incomplete, you have more points of contact with entries on the lists. Regularly refreshing data — particularly for long-standing clients — reduces the number of alerts caused by missing identifiers.

The right tool. Not every screening tool handles Cyrillic transliteration, Arabic name variants, or corporate name abbreviations equally well. If your company serves clients from a specific geographic region, check that the tool has the appropriate dictionaries and algorithms for that region.

We discuss the differences between on-premise and SaaS screening, and what that means for match threshold configuration, in the article on the sanctions screening obligation.

FAQ — frequently asked questions

Can I dismiss an alert without verification if I am certain it is a false positive?

No. “Certainty” without documented verification is not a sufficient justification. You must check the identifiers and record the outcome. If verification takes 2 minutes and the result is obvious — write it up in two sentences. That is all due diligence requires in a typical case.

What if the counterparty refuses to provide their date of birth?

A refusal to share basic identifying data is itself a risk signal. You may decline the transaction or require an identity document as a condition of providing the service. The decision is yours, but the inability to verify in the face of an existing alert is an operational risk that should not be ignored.

How long must I retain documentation of alert resolutions?

The minimum retention periods for compliance documentation depend on the type of business and the applicable legal basis. Recognised industry practice is to retain records for at least 5 years, by analogy with AML documentation — however, the specific obligation for your company is determined by the rules applicable to your sector. If in doubt, consult a lawyer or a compliance adviser.

Can a false positive occur for a company, not just an individual?

Yes. Company names — particularly those containing common words such as “Group”, “International”, “Holdings”, “Trading” — generate false positives just as frequently as individuals’ names. Verification follows the same process: you compare the registration number, country of incorporation, and address with the list entry.

Do I have to check each list separately?

If you use a tool that aggregates the EU, MSWiA, OFAC, and UN sanctions lists, screening is carried out simultaneously against all lists and the alert indicates which list and entry the system identified a match with. For manual verification — yes, you must check the specific entry on the specific list identified by the system.

How long should verification of a single alert take?

For a typical false positive with an obvious difference in identifiers — between 2 and 10 minutes, including documentation. Complex cases, where data is incomplete or the overlap covers multiple identifiers, may require a longer investigation, obtaining documents from the counterparty, and internal consultation. There is no single standard — what matters is that the time is proportionate to the risk of the transaction.

How Sanqto can help

Sanqto is sanctions screening software installed directly on your company’s network — counterparty data never leaves your infrastructure. The system operates on a three-state model: MATCH, POSSIBLE, and CLEAR, with a response time of under 30 ms. A POSSIBLE result is automatically placed in the manual review queue, and every analyst decision is recorded along with its justification — without the need to maintain a separate register in a spreadsheet. If you serve clients in the travel sector, see the page for the tourism industry, and if you operate in insurance — the page for the insurance industry.

Legal basis

• Council Regulation (EU) No 269/2014 of 17 March 2014 concerning restrictive measures in respect of actions undermining or threatening the territorial integrity, sovereignty and independence of Ukraine — CELEX 32014R0269
• Council Regulation (EU) No 833/2014 of 31 July 2014 concerning restrictive measures in view of Russia’s actions destabilising the situation in Ukraine — CELEX 32014R0833
• Council Regulation (EC) No 765/2006 of 18 May 2006 concerning restrictive measures in view of the situation in Belarus — CELEX 32006R0765
• Directive of the European Parliament and of the Council (EU) 2024/1226 of 24 April 2024 on the definition of criminal offences and penalties for the violation of Union restrictive measures — CELEX 32024L1226
• Act of 13 April 2022 on special solutions for counteracting support for aggression against Ukraine and for the protection of national security (Journal of Laws 2022, item 835) — ISAP
• Act of 1 March 2018 on combating money laundering and terrorist financing (Journal of Laws 2018, item 723) — ISAP
• Polish sanctions list — MSWiA: gov.pl/web/mswia/lista-osob-i-podmiotow-objetych-sankcjami
• EU Consolidated Financial Sanctions Database (FSD) — DG FISMA: finance.ec.europa.eu
• EU Sanctions Map: sanctionsmap.eu

Footnotes

Information, not legal advice. This article is for informational and educational purposes only. It does not constitute legal advice. Legal status as of: 20 May 2026. Your company’s specific obligations depend on your business profile and require individual assessment — if in doubt, consult a lawyer or a compliance adviser.