Sanctions screening fires false positives because it matches strings, not people. To cut hit volume without losing true positives, resolve the entity first: keep name matching as a permissive recall layer, then rank candidates on identifiers, jurisdiction, and ownership structure before any alert is dispositioned. The name match starts the process. It should not end it.
Legacy screening compares a name in your transaction to a name on a list, scores the string distance, and raises an alert when the score clears a threshold. It has no idea whether the two names belong to the same real person or company. So it fires on “Mohammed Ali” the boxer, the customer, and the freight forwarder in Karachi with equal confidence. Entity resolution fixes that by asking who the party actually is before it decides the match matters.
That distinction is the whole game. A name is a string. An entity is a person or an organization with a date of birth, a jurisdiction, a passport number, a registered address, an ownership structure. Screening on the string alone means you are matching on spelling, and spelling is cheap. Two unrelated people share a name constantly. A sanctioned individual and a retiree in Ohio can score 100 percent on a name comparison and have nothing to do with each other. The list entry carries far more than a name, and most screening systems throw all of it away at the comparison step.
The false-positive tax and where it comes from
Ask a sanctions team what their hit rate is and the honest ones will tell you the high nineties are false positives. That number is not a tuning failure. It is structural, and it comes from three places.
- Name-only comparison. The matcher scores “Ivan Petrov” against every Ivan Petrov on the consolidated list without using the DOB, nationality, or identifier fields that would eliminate most of them in one step.
- Threshold theatre. Teams are afraid to raise the match threshold because a missed true positive is a regulatory event and a false positive is only labor. So the threshold sits low, the queue floods, and reviewers clear the same benign name a hundred times a week.
- List handling. OFAC’s 50 Percent Rule means entities owned 50 percent or more, in aggregate, by one or more blocked parties are themselves blocked, even when they never appear on the SDN list by name. Systems that screen only the published names either miss these entirely, or, when someone bolts on a crude ownership expansion, generate a fresh flood of weak matches.
The cost here is not only the review hours. Every false positive that reaches a customer means a payment held or an account frozen at onboarding, and a relationship you then have to repair. Worse, a queue that is 98 percent noise trains reviewers to clear fast, which is exactly the condition under which a real hit slips through. Alert fatigue is a recall problem wearing a precision costume.
Resolve the entity, then decide the match
Our method puts entity resolution before disposition. Name matching still runs, and it stays deliberately permissive, because it is the recall layer and its job is to never drop a candidate that could be real. What changes is everything downstream of the candidate list.
For each candidate pair, we assemble the context a human analyst would actually look at, and we compute it as features:
- Identifier agreement. Does the DOB match, or fall in a plausible range? Do passport, national ID, or tax numbers align? A single strong identifier match is worth more than any name score.
- Jurisdiction and geography. A party wiring euros between two German accounts, matched against an SDN entry whose only known addresses are in Pyongyang, is a different proposition than one with overlapping geography.
- Name structure, not just distance. Transliteration variants, patronymics, corporate suffixes, and word-order swaps get handled with logic that knows they are the same phenomenon, rather than a raw Levenshtein score that treats “Al-Rashid Trading LLC” and “Rashid Al Trading Limited” as far apart.
- Ownership graph. For entity screening, the resolved ownership structure that the 50 Percent Rule depends on, so the derived blocked entities are first-class candidates and not an afterthought.
These features feed a model that ranks and routes candidates, and this is where discipline earns its keep. The eval set is built from your own dispositioned alerts, with point-in-time correctness so a match is scored against the list and the party data as they existed on the transaction date. Backtesting against a current list that has since been amended is leakage, and it will flatter your numbers until the day a real case is reviewed. Keep a held-out set of confirmed true positives and watch recall on it like it is the only metric that exists, because for a regulator it nearly is.
What “reduce hits” is not allowed to mean
There is a wrong version of this project, and it is easy to build by accident. It looks like a model that quietly suppresses low-scoring alerts to make the queue smaller. That is not risk reduction. That is moving your false-negative rate somewhere you cannot see it.
The version that survives an audit keeps a full trail. Every candidate the name matcher produced is retained. Every feature that informed the ranking is stored. When the system routes an alert to auto-close, the reason is logged in language a reviewer and an examiner can read: identifiers contradicted, jurisdiction incompatible, resolved to a known cleared entity from prior review. A reviewer can pull any auto-closed alert back and override it, and those overrides become new labels that feed the next eval cycle.
Two operational points decide whether this holds up over time. First, lineage. When the consolidated list updates, which it does constantly, you rescreen the affected population and you can show exactly which version of the list produced which decision. Second, drift. Match-score distributions move as your customer base and payment corridors change, and a threshold that was right last quarter can silently degrade. Monitor the score distributions and the auto-close rate, and treat a sudden shift in either as an incident rather than something to look at when quarter-end frees up.
Done this way, hit volume falls because the system stops confusing distinct people who share a name, not because it learned to look away. Reviewers spend their hours on the candidates where identity is genuinely ambiguous, which is the only place their judgment was ever worth paying for.
FAQ
Will adding entity resolution make us miss a real sanctions hit?
Only if you let the model drop candidates. Keep name matching as the recall layer and use entity resolution to rank and route, so no alert is suppressed without a logged reason a reviewer can override.
How do we tune the name matcher without a labeled dataset?
Start from your own dispositioned alerts. Every closed hit is a label, and the false-positive ones tell you which name-distance thresholds are firing on nothing. Build the eval set from historical decisions before you touch the algorithm.
Does OFAC's 50 Percent Rule change the matching logic?
It changes the reference data, not the matcher. You need ownership graphs to derive the entities that inherit sanctions, then screen against that expanded set. The 50 Percent Rule is an entity-resolution problem sitting upstream of name comparison.