Practical guide
Sanctions screening false negatives: trace a missing match
Find why an expected sanctions candidate did not reach review by checking submitted facts, source versions, matching policy, and the handoff.
On this page
Find the exact check and expected record
An expected candidate can go missing at several points: the submitted identity, coverage, matching or the handoff to review. In SanctionsKit, open Screening history in the dashboard, or read GET /api/v1/results/{id}. Keep the screening ID, facts, coverage and versions in approved evidence storage.
Name the source record you expected and why it should have appeared. A completed result without a candidate is different from a failed request, expired result or returned candidate that no reviewer saw. Each path needs a different fix.
Read the submitted facts, not just today's profile
Inspect the retained name, subject type, date precision and ID scheme and issuer. A trading name may differ from the intended legal company. A contact person sent as an organization changes the question being asked. Today's corrected customer profile does not show what the original request used.
Correct verified errors through the dashboard and run a new screening. A case correction creates a replacement and keeps the old history. Do not overwrite the earlier result or reuse the old operation key for changed subject facts.
Check whether the expected record was in the selected source
Read result.coverage and versions. Confirm the expected source was selected and the entry existed in that version at the time. GET /api/v1/sources shows current availability and currentVersion. A later lastImport does not prove the earlier check used that data.
An unavailable required source is an error, not a valid empty result. If your application converted it to no_match, fix that handling. The freshness guide shows how current source state differs from the evidence retained for an earlier screening.
Inspect the policy without changing several things at once
Read policySnapshot and the matching information. If Focused omitted an expected name variant, evaluate the same case under an authorized Standard policy. The sensitivity guide explains these controls. Compare evidence before deciding which change caused the gap.
Create a small synthetic reproduction where possible. Keep source selection, inputs and profile stable except for the factor under test. Changing all three at once prevents a clear diagnosis. Do not put customer details or keys in diagnostic logs.
Follow a returned candidate into the current case
If matches contains the candidate, read GET /api/v1/cases?screeningId=ID and the current investigation. Check for reopened work, a replaced case, pending approval or a stale reused decision. An old dismissal must not act as approval of changed facts.
For monitoring, check the event, screening reference and webhook processing. An acknowledged event can still have an unresolved case. Repair the failed handoff, verify it with a synthetic regression, and record any evidence or coverage gap you could not resolve.
State the limits of the fix
A representative test set can find a defect and compare changes. It cannot prove that no real-world identity will ever be missed. Record the tested population, coverage gaps, unsupported cases and open issues. Keep ownership and activity controls separate.
Use screening validation and ownership guidance together. A useful quality claim names the population, source versions and method it tested. Avoid turning one repaired example into a promise about every future customer.
Sources and references
Authority and technical sources
SanctionsKit documentation
Frequently asked questions
Is every absent expected match a matching-engine false negative?
No. The check may have used different facts or coverage, failed entirely, or returned a candidate that never reached the reviewer. Locate the exact result and expected source record before changing the matcher.
Can current source data prove an older screening missed a record?
Only if you establish that the relevant entry was present in the version used by that screening. A current import may contain later changes. Compare the retained source version and screening date, not just today's source directory.
What if the candidate appears in the API response but not in review?
Trace the linked case and current investigation. Check routing, reopened or replaced cases, approval state and any reused decision. Repair the handoff and test it; changing name sensitivity will not fix a lost review task.
How should I report a successful false-negative fix?
Describe the failed case, root cause, change and regression evidence. State the tested inputs and source scope, plus remaining limits. One repaired example does not prove that all real-world matches will always be found.