Practical guide
Sanctions screening thresholds: reduce noise without hiding misses
Evaluate sanctions matching thresholds with labeled tests, source context, name variants, and explicit review policies instead of treating scores as probabilities.
On this page
A score ranks resemblance, not legal risk
A matching score is an output of a particular comparison method. It can help order candidates, but it is not the probability that a person is sanctioned or that a transaction is prohibited. Different systems may calculate scores differently, so identical numbers are not automatically comparable.
The name-matching guide explains how aliases, normalization, and derived forms affect discovery. Review the actual explanation rather than displaying the score as “confidence of wrongdoing.”
Define the objective before changing a threshold
A threshold affects which candidates reach review. Raising it may remove unrelated names while also hiding meaningful variants. Lowering it may increase candidate discovery and analyst workload. The useful question is the measured effect on an appropriate labeled set.
Do not tune solely to a target alert count. A quiet queue can indicate precise retrieval or a broken control. Distinguish those possibilities through testing.
Use representative positive and negative cases
Include common names, short names, original scripts, aliases, reordered names, and real source-data precision. For organizations, test meaningful suffix and registry variations without assuming all legal suffixes can be discarded.
Label expected retrieval separately from final identity outcomes. A correct candidate can still be a false positive after investigation. An unrelated candidate is not proof that the retrieval system is universally ineffective.
Keep source and policy versions with the results
A threshold test is tied to a source snapshot, matching implementation, input population, and policy. If any changes, the earlier result may not describe current behavior. Record the proposed change, test comparison, approvals, and rollback conditions.
Use versioned policies where supported. Do not invent an undocumented per-request threshold parameter or assume every matching setting is public API configuration.
Evaluate the review workload honestly
Measure candidates per subject, missed expected candidates, reviewer effort, unresolved evidence gaps, and repeated dismissals. A rule that saves minutes in one population may create misses in another. Review specific failure cases rather than averaging them away.
For an invented test population, a stricter setting removes many short-name candidates but also loses an expected alias case. That tradeoff should be visible in the change decision, not hidden behind the reduced queue size.
Use better evidence as well as better retrieval
Reliable identifiers, source context, and clear review notes can reduce repetitive uncertainty without suppressing name variants. Keep decision reuse narrow and invalidate it when relevant facts change.
Pair threshold evaluation with screening tests and false-positive review. No threshold eliminates the need for a reasoned identity comparison.