Sanctions screening policy: turn your process into clear controls

Write down the choices your team has approved

A sanctions screening policy tells staff which parties and sources to check and what review follows. Owners and administrators publish these choices through Screening policies in SanctionsKit. Start from your approved process. The product setting does not decide which legal duties apply.

Give the policy a clear purpose and relevant jurisdictions. Choose required and optional sources for each allowed subject type, and describe exclusions. If a required source is unavailable, the policy cannot create access or silently reduce the required check.

For example, a supplier policy may require two lists and a check of its owners. Writing both down prevents a list no-match from hiding the unfinished ownership work. Each task needs a named owner and evidence before the case can close.

Choose matching and review settings deliberately

Matching sensitivity offers Standard and Focused. Focused requires closer name similarity, which can miss useful name variants as well as reduce extra alerts. Both profiles use the same candidate retrieval and keep matching typed-identifier alerts. Test relevant cases before changing the profile.

Partial-name review is a separate policy choice. It is off by default. When enabled, it includes weaker evidence from name-word prefixes of at least three characters and missing name components. The result explains that partial agreement, and broad queries can still return an error when they exceed the candidate limit.

Set the review requirements, including a different eligible approver where required. Keep identity findings separate from the business action. A required approval cannot be removed from one case simply to avoid the policy. The controls should reflect the process staff are expected to follow.

Give outside checks clear instructions

Add each required external check with instructions and an example of useful evidence. Your team or another service performs an ownership or other assessment. The reviewer records completed externally with an evidence reference, or not applicable with a reason.

Choose the approved monitoring cadence and retention trigger: review_completed, relationship_ended or business_event. These names control product behavior. They do not mean one setting meets every legal requirement. The policy guide explains how each control applies.

Use the exact published policy version

Publish the policy as an immutable version and select it for new dashboard checks. An API key with sources:read can call GET /api/v1/policies and GET /api/v1/policies/{id}; both return current versions in data.items. Send the actual returned ID and version in your request's policy object.

Include exactly one coverage selector alongside policy. It must contain the policy's required sources for that subject type and only required or optional sources. requirePolicy tells you whether new Production work must use a policy. API keys can discover policies but cannot publish or retire them.

Test a change before updating ongoing work

Run a synthetic check through review, outside tasks and any approval by a second person. Try missing required coverage and an obsolete policy version. Both should fail visibly. They must not fall back to a different scope just to complete the request.

When scope changes, publish a new version and update saved monitors deliberately. Policy-backed monitors keep the approved cadence; obsolete policy references fail closed. Earlier checks retain policySnapshot. versions.policy identifies separate matching rules. The testing guide covers validation of the change.

Record exceptions and their follow-up

For an exception, name the unmet requirement, business context, authorized owner and permitted scope. Set an expiry or review point and list follow-up work. An outage cannot become an indefinite reason to omit a required list. Keep track of affected customers so deferred checks can be reconciled.

For source or matching changes, record the reason, expected effect and test evidence. Check effects on monitors and reusable decisions before rollout. Preserve the previous version in historical cases. Use screening testing to make the acceptance decision based on observed results.

Frequently asked questions