· Yair Knijn
Same name, different human: the false positive your tuning made impossible to clear
A Head of Financial Crime inherits a screening setup that matches on one field: the party's name string against the list's name string. No date of birth in the comparison, no nationality, no passport or registration number. The assumption baked into that design is that a name is enough to tell two people apart. For anyone called Mohammed Ali, Wang Wei, or Maria Garcia, it is not.
The result is a match population you cannot adjudicate. Every common-name hit lands on the analyst's desk with the same thin evidence the engine had: two names that look alike. There is nothing in the record to push the decision toward clear or toward confirm, so whatever the analyst writes down is a guess wearing the costume of a determination.
Why name-only matching is structurally unclearable for common names
Tuning does not fix this, because the problem is not the threshold. You can set fuzzy matching tight and lose the real designations whose names are transliterated three different ways. You can set it loose and bury the team. Either way, the fundamental shortage is the same: the only discriminating field is the one field that does not discriminate. A common surname plus a common given name describes thousands of living people and one sanctioned person, and the name alone cannot separate them.
The diversity of naming conventions worldwide makes this worse, not better. Transliteration from Arabic, Cyrillic, or Chinese script multiplies the spellings a single name can take, so two unrelated customers routinely resolve to near-identical strings. Your match_score climbs toward 100 on a pair of people who share nothing but a writing system.
The discriminators that collapse false positives: DOB, nationality, ID numbers
The Wolfsberg Group frames the goal as raising the share of productive alerts the share that turn out to be real. You do not get there by deleting weak alerts after the fact. You get there by giving the engine more than a name to compare, so the weak alerts never reach a human in the first place.
- Date of birth. A listed individual born in 1962 does not match your customer born in 1989, no matter how the names align. One field eliminates most of the namesake population.
- Nationality and place of birth. Cheap to capture at onboarding, and decisive against a list entry tied to a different country.
- Identity and registration numbers. A passport number or a company registration number is close to unique. When it is present on both sides, the question stops being a judgment call and becomes a lookup.
How weak inputs force teams into over-blocking or rubber-stamping
When the only evidence is two similar names, an analyst has two ways to survive the queue, and both are failures. The cautious ones over-block: they escalate or hold anything that scores high, which freezes legitimate policies and trains the business to see compliance as the department that breaks things for no reason. The fast ones rubber-stamp: they clear on pattern, "looks like another common-name hit," and write a one-line rationale that would not survive thirty seconds of regulatory questioning. Same broken input, opposite coping mechanism, neither defensible.
This is where OFAC's recent enforcement record bites. Penalties in 2024 and 2025 hit firms whose controls failed to surface real sanctioned ownership and exposure. A clearance you cannot evidence is the same liability as a hit you missed; both come from a case file that does not show why the decision was correct.
Feeding richer party data into the screen so the match score means something
The fix is upstream of the engine. Capture date of birth, nationality, and at least one identifier at the point you take on the party, then pass those fields into the comparison so the score reflects identity, not spelling. A 95% name similarity that disagrees on DOB and nationality should resolve low and clear itself. A 95% name match that also agrees on date of birth and passport number should escalate hard. When the inputs carry that signal, the match_score finally means something, and both your clearances and your confirmations come with the evidence already attached.
InsureGuardAI is built around that principle: each customer's workspace screens against secondary identifiers, not name strings alone, and keeps the raw match response and the discriminating fields in the case file. So when the regulator asks why you cleared a common-name hit, the answer is a record showing the date of birth and nationality that ruled the namesake out, not a sentence that starts with "we assumed."