How to Reduce KYC False Positives Without Losing Coverage

Table of Contents

To reduce KYC false positives, fix three things: the data you screen, the rules that decide what counts as a match, and the thresholds you apply to each risk tier. Raising the match score across the board is not a fix. It buries real hits. The durable gains come from secondary identifiers, tighter list scoping, disciplined whitelisting, and testing every change before it goes live.

Most teams start in the wrong place. They ask the vendor to turn the sensitivity down, the queue shrinks, and everyone relaxes. Six months later an auditor asks what you stopped catching. Nobody can answer.

What follows is the tuning work in the order it should be done, with the evidence to keep at each step. It assumes you already run denied party screening on customers, suppliers and counterparties.

What a false positive actually is, and what it is not

A false positive is an alert your screening engine raised against a list record where the person or entity in front of you is a different person or entity. The name looked close. The identity was not the same.

Three other things get mislabelled as false positives, and the confusion distorts your metrics.

A true match you decide not to act on. The customer is on a list you screen for information only, such as a low-relevance adverse media source. That is a true match with a business disposition, not a false positive.
A duplicate alert. The same customer hits the same list record again after a refresh. That is a suppression failure.
A false rejection. You declined or delayed a legitimate customer because the alert was never resolved in time. That is a customer outcome, and it should be counted separately.

Keep those four buckets apart in your case management system. If they all close under one reason code, you cannot tell whether tuning helped. Precision is the share of alerts that turn out to be real. Recall is the share of real matches your system caught. A change that lifts precision while holding recall steady is a win. A change that lifts precision by dropping recall is a risk transfer.

Find the root cause before you touch a setting

Pull a sample of closed false positives. Two hundred is enough to see the pattern. Read the alert, the customer record and the list record side by side, then code each one against a cause.

Thin customer records

If all you hold is a name, the engine has nothing to discriminate with. A common surname against a list of tens of thousands of entries will alert forever. Date of birth, nationality and a registry number are what kill those alerts dead.

Dirty name fields

Look at what is actually in the field you screen. Teams routinely find job titles, salutations, “c/o” strings, freight forwarder names sitting in a consignee field, and two directors concatenated into one line. Fix that at the point of capture, not in the screening engine.

Over-broad screening scope

Some configurations screen every field they can reach, including free-text remarks and address lines. Screening an address line against a list of persons generates hits on street names. Decide field by field what is screened, and write that decision down.

One threshold for everybody

One match score applied to a retail customer in a low-risk market and to a trade finance counterparty in a high-risk one serves neither. Too loud for the first. Too quiet for the second.

List problems rather than your problems

Sometimes the list record is the issue. It carries a name and nothing else, or it duplicates an entry that already sits elsewhere in your list set. Note these separately. The SDN list and the Consolidated Screening List overlap in ways that create repeat hits if you load both without deduplication.

Enrich the record with secondary identifiers

This is the highest-yield change available to most teams, and it needs no vendor. A name-only comparison can only guess. Add one strong identifier and most near-name alerts resolve automatically. Capture identifiers at onboarding, store them in structured fields, and pass them to the engine so it can score them. A date of birth sitting in a scanned passport image does nothing. The engine has to be able to read it.

Entity type	Identifiers to capture and screen on	What it lets you rule out
Individual, retail	Full date of birth, nationality, country of residence, gender	Same-name hits with a different birth year or a different nationality
Individual, higher risk or PEP	All of the above plus place of birth, passport or national ID number, known aliases, role and employer	Namesakes of politically exposed persons, which are the noisiest category in most books
Company	Company registration number, country of incorporation, Legal Entity Identifier where held, registered address	Unrelated firms sharing a common trading word such as a place name or a family name
Bank or financial counterparty	BIC, LEI, country, branch identifier	Branch-level and group-level confusion within large banking groups
Vessel or aircraft	IMO number, flag, call sign, tail number	Renamed and reflagged assets, where the name is the least stable attribute

Set a rule for what happens when an identifier is missing. A record with no date of birth should not silently get the same treatment as one with a confirmed mismatch. Route it for collection instead.

Tune the matching logic, not the master threshold

Fuzzy matching is a set of components, each adjustable on its own. Ask your vendor for the component list and what each one currently does.

Edit distance catches typographic slips such as a swapped letter. Useful, and a frequent source of noise on short names.
Phonetic matching groups names that sound alike. It performs badly across language families and is often the single loudest component.
Token and word-order handling deals with reversed given and family names, and with middle names that appear in one record and not the other.
Transliteration maps Arabic, Cyrillic, Chinese and other scripts to a canonical Latin form. Without it you miss real matches. With it set too loose you drown.
Normalisation rules strip legal suffixes such as Limited, GmbH, LLC and Pte Ltd, and handle particles such as bin, al, van der and de la.

Tune the component that your root cause analysis blamed. If phonetic matching produced most of your noise, restrict it to names above a minimum length, or disable it for corporate entities where it adds little. That is a targeted change you can explain. A blanket threshold rise is not.

Segment thresholds by risk, and write the logic down

Different populations deserve different sensitivity. A low-risk domestic retail customer with a full identity record can sit at a tighter match requirement. A counterparty in a high-risk jurisdiction, or one involved in a sector under export control, should sit looser so marginal hits still surface.

Three or four tiers is usually enough. More than that becomes impossible to govern. The segmentation has to sit in the screening policy, approved by the accountable officer and reviewed on a fixed cycle. An examiner will ask why a given customer sat in a given tier, and the answer needs to come from a written rule rather than an analyst’s memory.

Ownership structures cut across this. An entity can be caught by sanctions through its owners even when its own name appears nowhere on a list, which is why the 50 percent rule in sanctions screening has to be handled by ownership data and not by name matching at all.

Scope your lists to your actual exposure

Screening against every list your vendor offers feels safe. It is not. Each extra list adds alerts, and lists with poor structured data add the worst kind.

Start from obligation. Work out which regimes bind you through your incorporation, your currencies, your customers and your goods. Those lists stay in scope whatever the noise. Then look at the discretionary ones. For each, ask what it caught in the last twelve months that a mandatory list did not. If the answer is nothing, take the evidence to your risk committee and propose retiring it.

Treat adverse media and PEP screening as separate populations with their own thresholds and metrics. They are noisier by nature, and folding them into the sanctions numbers hides what is happening in both. Globalior’s free denied party screening tool is a quick way to sanity check a name against the main public lists.

Whitelist properly, or do not whitelist at all

Whitelisting stops the same cleared alert reappearing every cycle. Done badly it is the fastest way to create a genuine miss.

Five rules make it safe.

Bind the entry to a specific customer record and a specific list record identifier. Never to a name string, and never across all lists.
Record the list version it was cleared against. When the publisher amends that record, the entry expires and the alert returns for review.
Store the evidence that supported the clearance. The conclusion on its own is worthless.
Require a second reviewer for any whitelist entry on a sanctions list, and set an expiry date on every entry.
Report whitelist volume and age to the compliance committee so nobody can quietly park a problem there.

The clearance evidence is what saves you in an audit. If the file shows how the analyst distinguished the customer from the list record, the disposition stands. Our guide to resolving a false positive in denied party screening covers the discriminators to look for, and record keeping for screening turns a good decision into a defensible one.

Test every change before it reaches production

This is the step most teams skip, and it is the one a regulator asks about first. Tuning without testing is guessing.

Below-the-line testing

Sample the matches falling just under your proposed new threshold, in the band that would no longer alert. Have an analyst review them blind. If a true match appears there, the threshold is wrong. This is the evidence that recall held.

Parallel run

Run the new configuration alongside the old one for a full screening cycle. Compare alert counts, true match counts, and the alerts that appeared under one configuration but not the other. That last set is the interesting one.

A fixed test pack

Build a standing set of test names the system must always catch. Include real list entries in native script, transliterated forms, reversed name orders, misspellings and known alias variants. Run it after every list update, vendor release and configuration change. If the pack fails, you have a regression, and you found it before a regulator did.

Instrument the programme so drift shows up early

Report these monthly, cut by list, by rule and by risk tier rather than as one blended figure.

Alert volume per thousand screened records.
Share of alerts closing as non-matches, tracked per list.
Median and ninety-fifth percentile time to disposition.
Repeat alert rate, meaning alerts on pairs already cleared.
Escalation rate and the share of escalations confirmed as true.
Quality assurance error rate from independent sampling of closed alerts.

A sudden jump in one list’s alert volume usually means the publisher restructured its data. A slow rise across everything usually means your customer data quality is decaying. The trade-offs in automated versus manual denied party screening get easier to judge once you can see which queues are genuinely mechanical.

Things that look like fixes and are not

Raising the master threshold with no below-the-line evidence.
Removing a list because it is noisy rather than because it is out of scope.
Auto-closing alerts in bulk by name pattern.
Whitelisting on the name string instead of the record pair.
Screening less often. Alert volume falls and so does your ability to catch a newly designated party, and you can run a denied party screening check against the current lists in seconds, so frequency is rarely the constraint it is claimed to be.

Key takeaways

A false positive is a name-similar alert where the identity differs, and it should be coded separately from duplicates and false rejections.
Adding date of birth, nationality and registry identifiers to structured fields removes more alerts than any threshold change, and removes no detection capability.
Fuzzy matching is a set of tunable components, so tune the component your root cause sample blamed rather than the master score.
Risk-segmented thresholds belong in the screening policy, because an examiner will ask why a customer sat in a given tier.
Whitelist entries must bind a customer record to a specific list record and expire when the publisher amends that record.
Below-the-line testing is the evidence that a tuning change preserved recall, and no change should go live without it.
Track alert metrics by list, rule and risk tier, since a blended false positive rate hides both improvement and drift.

Frequently asked questions

What is a normal false positive rate for sanctions screening?

There is no published regulatory benchmark, and rates vary with customer mix, name populations and list scope. A book of common surnames screened against large person lists will always be noisier than a small corporate portfolio. Compare yourself against your own trend, cut by list and risk tier, rather than a headline industry figure drawn from a different business.

Can I just raise the match threshold?

Only with evidence. A threshold rise silently removes alerts you can no longer see, so you need below-the-line testing on the band you are switching off to show no true matches sit there. Without that sample, you have moved risk rather than reduced it, and you will not be able to answer an examiner who asks what the change suppressed.

How often should we retune?

Review the metrics monthly and retune when the data tells you to, rather than on a calendar. Trigger a review when a list publisher restructures its data, when you enter a new market, when you acquire a customer book, or when your repeat alert rate climbs. Formal validation of the whole configuration should happen at least annually.

What should an analyst write when closing a false positive?

Name the discriminator. A note saying “different date of birth, customer born 1974, list entry born 1961, nationality also differs” is defensible. A note saying “not a match” is not. Attach or reference the document that supported the discriminator, and record which list version was screened.

Do false positives matter if we clear them quickly?

Yes. Volume drives rushed dispositions, and that is where real matches get closed by mistake. Long queues also delay legitimate customers, which costs revenue and surfaces as a false rejection problem rather than a screening one. Measure both alongside the alert count.

If you want a second view on your screening configuration or help building a tuning evidence pack, get in touch with the Globalior team.