Continuous sanctions monitoring: how repeat checks work

Monitoring repeats a defined check over time

Continuous sanctions monitoring means an ongoing process of repeat checks and review. SanctionsKit keeps a subject, screens it against selected sources and brings relevant changes back to your team. It does not promise instant updates from every authority. Use it for the relationships your approved process requires you to recheck.

Open Monitoring in the dashboard and create a monitor. Enter an Internal label, then choose a saved Counterparties profile or supply known subject facts. Select the policy or coverage and choose Create monitor. The label helps your team find the monitor; the actual subject name is what gets screened.

Create a monitor through the API

The synthetic body below uses POST /api/v1/monitors with a sandbox key and monitors:write. Store an Idempotency-Key and follow the monitoring API guide. Choose exactly one of package or sources and include a real published policy reference when required.

HTTP 201 returns data.id, name and status active. The first screen is queued asynchronously, so creation does not mean it has finished. The create body has no retention, intervalHours, reference or runNow field. Cadence starts at the policy interval, or 24 hours without a policy. The monitor retains the subject for future checks.

{
  "name": "Synthetic customer monitoring",
  "subject": {
    "name": "Alex Morgan",
    "entityType": "person",
    "birthDate": "1984"
  },
  "package": "sandbox@1"
}

Confirm that the first screening actually finished

Open Monitored subjects and inspect health, last success and latest result. GET /api/v1/monitoring?monitorId=ID returns the detailed data.items entry, including health, lastSuccessfulAt, lastScreeningId, revision and nextRunAt. Save the monitor ID and read the result when a successful check exists.

active means scheduling is enabled. lastScreeningId can be null before a first successful run or after a failure with no completed result. A missing result or future schedule is not a no-match. If required coverage fails, keep the issue open until it is resolved and a check completes.

Follow changed evidence into the case

In Changes needing attention, inspect the event's current and previous screenings, change details and case link. A new candidate, changed evidence or renewed review needs a permitted person to read the case and decide what follows.

Acknowledge clears an event's unread state. It does not close the investigation. API keys can read the inbox and case, but acknowledgement and human review require a permitted human session. Webhooks can tell your application that an event is waiting.

Keep the saved subject and schedule current

Use Edit monitor to update the intended facts and coverage. When a linked customer profile changes, check the saved monitor request before resuming its paused checks. Change cadence offers six-hour, daily or weekly intervals; policy-backed monitors must keep the policy's cadence.

Read the capacity forecast before a change. Pause stops scheduled checks. Remove stops the monitor and clears its saved request, while old results follow their retention policy. Use the operations checklist to check both enrollment and completed work.

Keep other customer controls separate

A monitor does not study payment behavior, find all company owners or guarantee that every restriction appears in the chosen lists. Reviewers still assess identity and the authorized business action. A completed rescreen answers the defined list question for the saved subject.

The frequency guide explains schedule choices. The monitoring checklist helps confirm the process is working. Use both: a suitable schedule is useful only when the intended checks finish and someone handles the results.

Frequently asked questions