Screening is string matching, and string matching is blunt. A short abbreviation turns up inside an unrelated longer word, a common industry token is shared by thousands of companies, and a name written in another script loses letters on the way to Latin. Most hits are not the company in front of you.
| Compare | Real hit | False positive |
|---|---|---|
| Country of registration | Matches the entry | Different country, or the entry has none recorded |
| Address | Same city and street as recorded | An address that does not exist in the entry |
| Registration number | Present in the entry and consistent | Belongs to a different entity, past or present |
| Business activity | Consistent with the stated reason for listing | Different sector entirely |
| Script of the listed name | Same name in the same script | The match only appears after transliteration |
If two or more of those disagree, you are looking at different companies. Write down which ones disagreed and the date you checked — the note is the thing that protects you six months later, not the memory of the decision.
Word-boundary matching instead of substring matching removes the largest class of junk, and normalising accents and other scripts removes a second class. Both come with a cost: loose matching hides nothing and drowns you, tight matching is quiet and risks missing a real variant. The honest position is that no single configuration is right for every counterparty, which is why the result is read by a person.
Not on the strength of the hit alone. Clear it against identifiers first. Only a confirmed match is a confirmed match.
Before onboarding, before each payment run in high-risk corridors, and whenever the counterparty's details change. Lists change continuously, so a check carries the date it was made.