Set a sanctions screening policy for your team

A screening policy tells the team which sources to check and what to do with the result. Owners and administrators publish policy versions in the dashboard. A published version stays fixed, so an earlier result keeps the rules it used even after the policy changes.

Record why you screen and which jurisdictions apply. Choose required and optional sources for each subject type, and explain any exclusions. Add checks done elsewhere, review and approval steps, how often to recheck, and when retention starts. Choosing lists alone does not establish that the policy meets your obligations.

Call GET /policies with sources:read. The response contains data.items, nextCursor, and requirePolicy. The default page limit is 100; follow nextCursor for more results. GET /policies/{id} uses the same items envelope for the current published version, rather than returning a bare policy object.

Choose the policy approved for your business purpose and subject type. Read requiredSources, optionalSources, review, external checks, monitoring cadence, and retention rules. Send its exact id and version under policy, plus one coverage selector. The example UUID only shows the request shape. Replace it with an ID returned for your organization.

If requirePolicy is true, a production request without an approved policy fails. Retired or replaced versions cannot be used for new work. Fetch the current policy and review changed rules before choosing it. Earlier results keep their policySnapshot; later settings do not rewrite them.

curl --fail-with-body "https://www.sanctionskit.com/api/v1/policies?limit=100" \
  -H "Authorization: Bearer $SANCTIONSKIT_API_KEY"

Owners and administrators publish and retire policies in the dashboard. An API key cannot approve a policy. Your backend reads published policies and sends their IDs and versions with screenings. If a policy is rejected, show the error so an administrator can resolve it.

Keep policySnapshot and versions.policy. The first records your organization's approved business controls. The second records the engine's matching rules. They explain different kinds of change and should not be compared as if they were the same version.

GET /api/v1/policies requires sources:read and returns current policy versions plus requirePolicy. GET /api/v1/policies/{id} returns the current version inside the same items envelope. Publishing or retiring a policy requires an authorized human session. Retirement stops new use while preserving the policy snapshot on earlier results.

Send policy with its id and version, alongside subject and one coverage choice. The coverage must include the policy's required sources for that subject type. Other sources must be listed as optional. Missing sources, unsupported subject types, and retired or changed policy versions cause an error before screening.

The result saves the policy in policySnapshot. This is the organization's business policy. The separate versions.policy field identifies the matching rules used by the engine. Keep both fields when saving a result.

Your organization can require a published policy for each new production screening. You can still test with invented records in the sandbox. A monitor that uses a policy follows that policy's approved cadence.

{
  "subject": {
    "name": "Alex Morgan",
    "entityType": "person",
    "birthDate": "1984"
  },
  "package": "sandbox@1",
  "policy": {
    "id": "00000000-0000-4000-8000-000000000001",
    "version": 1
  }
}

An external check is a task a reviewer completes outside SanctionsKit. Record whether it is outstanding, completed externally with an evidence reference, or not applicable with a reason. SanctionsKit does not research ownership or control, calculate aggregate ownership, decide jurisdiction, grant a licence, or authorize a transaction.

Choose review_completed, relationship_ended, or business_event to determine when retention starts. Your policy or organization settings can require a different eligible person to approve the case. Reviewers cannot remove those requirements from a case to bypass the policy.

Request and response reference

Frequently asked questions