Sanctions screening thresholds: compare Standard and Focused

Use the sensitivity control the product supports

SanctionsKit offers Standard and Focused under Matching sensitivity in Screening policies. Use these profiles to evaluate review work or investigate a missing name variant. An owner or administrator publishes the chosen profile in an approved policy version.

There is no arbitrary threshold field in the screening request. Inspect the policy in the dashboard and read the methodology for search and evidence behavior. A match score is not the measured probability that someone is sanctioned.

Understand what a stricter name setting changes

Standard includes more fuzzy-name alerts. Focused requires closer similarity. That can remove unrelated candidates, but it can also miss useful variants. Both use the same candidate retrieval and keep matching typed-identifier alerts. The reviewer still needs to compare identity facts.

To evaluate incomplete names, enable Partial-name review separately in the policy. This includes weaker partial_name evidence in either profile; it does not turn a prefix into a complete-name match. Keep the partial-name setting identical when comparing Standard with Focused, and evaluate it separately before adoption.

Do not copy a numeric cutoff from another vendor or an official tool. Scores belong to the system that calculates them. SanctionsKit accepts a published policy reference, not an undocumented score override. Comparing settings starts with the supported controls and their actual outputs.

Run the same cases under explicit policy versions

Choose invented subjects for integration tests and authorized fixtures for source-specific evaluation. Include aliases, short names, partial dates, companies and IDs that matter to your users. Decide which candidates should appear before reading the engine output.

Publish clearly labeled evaluation policies through a permitted human session. Select them in the dashboard or send their real id and version to POST /api/v1/screenings. Keep the subject facts and source versions stable. Sandbox checks the mechanics; it cannot measure live-source recall.

Look closely at candidates that disappear

Read returned matching information, evidence and coverage. Keep policySnapshot with each result. Count expected candidates lost under the new setting as well as unrelated candidates removed. A shorter queue may hide an important missed alias.

Add reliable subject facts to help resolve uncertainty. Close names can still refer to different parties. IDs are useful only when the scheme and issuer are comparable. Record the human conclusion separately from the automated result so you can inspect both later.

Adopt a change with an owner and recovery plan

Record the test evidence, chosen profile, owner and conditions for rolling back. Update saved monitors to the approved policy and coverage. An obsolete version must fail closed rather than silently use another profile.

Inspect new results and Monitoring events after the change. Keep old policy snapshots with their historical cases. The testing guide covers failures and reviewer handoffs. Use false-negative diagnosis when a particular expected record is missing.

Example: fewer alerts can also mean more missed matches

In a synthetic comparison, setting A finds 47 of 50 expected candidates and 70 unrelated candidates. Setting B finds 43 expected candidates and 25 unrelated candidates. B creates less review work, but misses four more expected records. Investigate those misses before choosing it.

Check which types changed: script variants, shortened company names, weak aliases or incomplete inputs. Keep source versions and name-processing rules fixed while comparing the profiles. Test changes to those other factors separately so you can explain what caused the difference.

Frequently asked questions