An alert is a question about identity, not about the name
A screening match says a string resembled a string. The review's job is to establish whether the person or entity in front of you is the person or entity on the list. Everything below serves that single question, and the reason to work in order is that each step narrows what the next one has to consider.
1. Establish what actually matched
- Which list, and which entry on it
- Which field matched — full name, alias, transliteration, entity name
- The match score, and where your threshold sits relative to it
- Whether the same customer has matched this entry before, and how it was resolved
2. Compare secondary identifiers
- Date of birth, where both sides have one
- Country of residence and nationality
- Any identification number present on both sides
- For entities: registration number, jurisdiction of incorporation, registered address
- Note explicitly where an identifier is absent rather than different — those are not the same finding
3. Consider the things that make names unreliable
- Transliteration: the same name in a different script may match poorly and still be the same person
- Common names: a high-frequency surname raises the false-positive rate and lowers the meaning of a name-only match
- Name order and compound surnames across naming conventions
- Aliases and known spellings on the list entry itself
- Corporate name suffixes, which match strongly and mean nothing
4. Decide, and be specific about what you decided
- Not a match — state which identifiers differ
- Match — state which identifiers align, and escalate under your policy
- Cannot determine — say so, rather than defaulting to dismissal, and escalate
- Record who decided and when
The third option is the one most often missing from a system, and its absence is why "not a match" is over-used.
5. What the closed alert must contain
- The list, the entry, and the matched field
- The identifiers compared, and the result of each comparison
- The conclusion in a sentence, in the analyst's own words
- Any document relied on, attached rather than referenced
- The decision-maker and the timestamp
6. Then look at the queue, not the alert
- What proportion of alerts are dismissed, and is it trending
- Which identifier most often resolves them — that names your tuning problem
- Are the same customers alerting repeatedly, and can that be suppressed safely
- Is anyone reviewing the suppressions
A review process that only ever looks at individual alerts will keep resolving the same false positive forever. The queue is where the fixable problem lives.
