Practical guide
Sanctions monitoring program: an operating checklist
Check that the right customers are enrolled, saved facts are current, scheduled screenings finish, and new evidence reaches a reviewer.
On this page
Compare active relationships with enrolled subjects
A sanctions monitoring program needs more than a list of enabled schedules. In SanctionsKit, open Monitoring in the dashboard. Compare Monitored subjects with the customers or suppliers your approved policy says to recheck. Record authorized exclusions and pauses.
A missing monitor, paused monitor and active monitor with no successful result are different gaps. For API reconciliation, read GET /api/v1/monitoring and follow nextCursor until null. Use stable business references and saved Counterparties links to find the intended identities.
Check the saved facts and policy version
Compare each monitor's saved request with verified current customer details. Editing a linked profile pauses its monitors so the requests can be checked. Use Edit monitor to update the full intended subject and coverage, then Resume when appropriate.
Verify the approved current policy version and cadence. A retired policy does not permit a fallback to fewer sources. Preserve the older screening evidence so a reviewer can explain why a correction or policy change led to a different result.
Inspect successful results and failed attempts
Read health, lastSuccessfulAt, lastScreeningId, lastAttemptAt and lastErrorCode in the detailed resource. Open the latest completed check and confirm the intended coverage and source versions. active and nextRunAt only describe scheduling.
For a failed or overdue check, inspect source eligibility, allowance and saved settings. Fix the cause, use Retry check now where available, then verify the later result. One recovered endpoint or queued retry cannot prove that every affected customer was successfully rechecked.
Connect changed evidence with actual review work
Read Changes needing attention, inspect the event and open its current case. Changed facts, a missing baseline and a failed check each need a different action. Assign the question to someone who can resolve it instead of merely clearing notifications.
If webhooks feed your system, compare durable processing state with product events and cases. Duplicate delivery must not duplicate decisions. New evidence must not hide behind an old dismissal. API clients read review state; permitted people make human decisions.
Plan capacity and stop work when the relationship ends
Check the Monitoring forecast and Usage & limits before changing enrollment or cadence. Scheduled rescreens and qualified source-triggered work share allowance with other screenings. A forecast is for planning. Compare it with actual completed usage afterward.
Use Pause for a temporary stop. Remove stops the monitor and clears its saved request when your approved process calls for that. Earlier evidence follows its retention policy. Ending future checks does not mean the historical case record has been deleted.
Example: reconcile enrollment, then completed work
A fictional business has 800 relationships selected for monitoring. It finds 790 active monitors, five paused monitors and five relationships without one. Those totals reveal an enrollment gap. They do not yet prove that the 790 active monitors completed their checks.
Next inspect successful results, subject versions and source scope. Investigate overdue runs and failures, then match new events to assigned cases. Record each approved pause or exclusion. These steps reveal gaps a single dashboard total can hide.
Assign gaps and verify recovery
For each issue, record the customer or monitor reference, failed requirement, owner and next action in your operations process. Use Operations reports for totals, and sample the real cases behind them. A resolved ticket should point to evidence of the result.
After recovery, recheck the affected group: current saved facts, available required sources, successful results and assigned open cases. The monitoring reference gives endpoint formats; webhook guidance covers event-delivery recovery.
Sources and references
Frequently asked questions
What should a routine monitoring reconciliation compare?
Compare the relationships requiring checks with enrolled monitors, then verify current subjects, policies, successful results and assigned review cases. Enrollment, scheduling, completion and review are different parts of the process.
Can an active-monitor count prove all customers were checked?
No. An active monitor can be overdue, failed or awaiting its first successful run. Read the last completed result and required source scope for the relevant subjects. Use totals to find work, not as proof of completion.
What proves recovery after a monitoring outage?
Verify successful checks for the affected subjects with their intended facts and required sources. Then reconcile resulting events with review work. A recovered service or queued retry alone does not show that the backlog was processed.
How should a team record an approved monitoring pause?
Record the affected relationship, reason, owner and review point through your approved process. Keep it visible in reconciliation. A pause is distinct from both a missing monitor and a successful check, and should not disappear into an active total.