Sanctions alert management: triage cases and failed checks

Identify the kind of work before assigning it

Sanctions alert management starts by asking what needs attention. In SanctionsKit, Review queue holds cases needing investigation or decisions. Monitoring shows events about saved subjects and source changes. Screening history holds the original completed checks.

A possible identity match, a failed rescreen and a case awaiting approval need different actions. A webhook receipt is not a confirmed match. A technical error is not a legal finding. Keep those distinctions visible so each item reaches the person able to resolve it.

Give the reviewer a precise question

Open the case and check its subject, current screening, sources, assignment and review state. Name the missing evidence or decision and assign it to someone with the right access and authority. 'Check this alert' is less useful than explaining which identifier or date needs verification.

Review every candidate. Record each identity conclusion and the separate business action through the case controls. If one candidate remains open, another candidate's dismissal cannot clear the whole case. Keep its next action visible when handing work between people.

Read what changed in the monitoring event

In Changes needing attention, inspect the change type, monitor, current and previous screening references and linked case. New evidence and a failed check are different events. A failure may have no new screening ID because no result was created.

Open the current result or case to inspect the facts. If the earlier baseline is missing or expired, record that limit instead of inventing a comparison. Acknowledge an event to manage the inbox; the linked case still needs its own review and completion.

Recover a failure and verify the next result

Read the monitor's health, last success and error. Resolve the source, allowance or setup issue first. For an active failed or overdue monitor, Retry check now queues another attempt. Refresh afterward and verify a later successful screening with all required coverage.

Queued work is not completed work. If someone else changed the monitor or case, reload its current state before acting. Keep earlier failures and decisions in the history. A broad 'passed' label should not erase the record of what failed and how it was fixed.

Use reports alongside the actual cases

Operations reports summarizes screening and case activity. Review audit trail shows retained human decisions. Sample the underlying cases as well as reading the totals. A smaller queue could mean work was resolved, or that something stopped entering the queue.

An integration should read GET /api/v1/monitoring/inbox and current investigation state rather than treat a webhook receipt as completion. The webhook guide covers delivery and recovery. Assign an owner to repeated delivery or processing failures.

Measure quality as well as queue size

Track the age of open work, evidence quality, missed handoffs and reasons cases reopen. Use the same labeled cases to assess a matching-setting change. Fewer alerts alone cannot show whether noise was removed or useful matches were missed.

For a fictional queue, 40 new alerts, 25 resolved candidates and 10 cases waiting on documents are different units. State whether a report counts candidates, checks or cases. Track incomplete checks separately so failed operations cannot make the false-positive rate look better.

Frequently asked questions