How can an institution reduce false positives in sanctions screening?

Why false positives happen

Common names, short names, names transliterated from other scripts and lists that contain thousands of entries with sparse identifiers all produce hits that look plausible on the surface. Fuzzy matching, which is necessary to catch misspellings and reordered names, widens the net further. An institution with a large customer base and a broad list set can generate more alerts than its team can review, and a backlog is itself a compliance finding.

Tune the threshold with evidence

Most engines expose a similarity threshold. The right value is not a vendor default but the point at which, on your own historical data, true matches are retained and the false-positive rate is tolerable. Backtesting against a set of known true matches and a sample of cleared hits is the way to find it, and the result should be documented as a policy decision with the evidence attached.

Use secondary identifiers

Date of birth, nationality, identification numbers and entity type discriminate far better than names. A screening engine that compares them automatically, and downgrades or suppresses a hit when they clearly conflict, removes a large share of review work before a person sees it. Filtering by entity type, so that a company name is not compared against individuals or vessels, is a simple and effective example.

• Compare date of birth and nationality when the list entry has them.
• Match identification numbers exactly where available.
• Filter by entity type: person, organisation, vessel.
• Weight matches on rare names higher than matches on common ones.

Remember decisions

The same innocent customer will hit the same list entry every time the list refreshes unless the cleared decision is remembered. A whitelist that records the customer, the list entry, the reviewer and the reason, and that is reapplied automatically on rescreening, stops repeat reviews. It should be scoped to the specific list entry, not the customer in general, so a new designation is still caught. The screening guide describes the review step.

Discipline in review

Faster review is not the same as looser review. A four-eyes disposition on every hit, with a required rationale, keeps the quality of decisions visible and creates the data needed to tune the engine. Analysts should have the KYC file and screening result on one screen, so clearing a hit does not mean opening three systems.

Measure it

Track the number of hits per screening run, the share cleared as false positives, the median time to disposition and the age of the oldest open hit. Report them as key risk indicators with thresholds, so a backlog escalates before a supervisor notices it. Improvement should be demonstrated with the institution's own numbers, not a vendor's claim.

How ERMAML handles this

ERMAML, the Ontech Risk & Compliance Suite, applies entity-type filtering and secondary-identifier comparison in the Elasticsearch query, exposes the match threshold for tuning, routes hits through a four-eyes review with a reusable, entry-scoped whitelist, and surfaces alert-queue age and disposition time as monitored indicators. See sanctions screening.