AML screening: how sanctions checks fit your customer process

Give each AML check a clear job

AML means anti-money laundering. A customer process may include identity checks, sanctions screening, PEP review and checks on account activity. These tasks use different evidence. SanctionsKit provides the selected-source screening, saved results and review for the sanctions step. It does not perform your whole AML program.

Choose the customer and related parties your policy requires you to screen. Use the identities established by your intake process. Open New screening in the dashboard, or send POST /api/v1/screenings. Keep a stable customer reference so the result goes back to the right person and the right stage of onboarding.

Choose sources and assign outside checks

An owner or administrator can publish a policy in Screening policies. It names the required sources for each subject type and any limits to the scope. Add required outside tasks, such as an ownership review or a PEP assessment done by another service. Tell reviewers what evidence to record.

An external-check label creates a task for your team. It does not buy data or make SanctionsKit run that check. Before Production, verify that every required source is available. If one is unavailable, keep the sanctions step incomplete instead of quietly dropping the list.

Review the sanctions finding on its own evidence

Open a retained match in Review queue. Compare the customer with the listed party and record the evidence for each identity decision. Then choose the separate business action under your policy. Keep the identity question open when the facts do not settle it.

Record an outside check as completed externally with evidence, or not applicable with a reason. A no-match can still require a case for those checks or business approval. See review controls before using a no-match as the final onboarding status. Finishing the list search and finishing the customer's review are different steps.

Return a result your customer system can explain

Read the result with GET /api/v1/results/{id}. Find the case with GET /api/v1/cases?screeningId=ID and read its current state through GET /api/v1/investigations/{caseId}. Store the screening outcome, review state and business action separately. A reader should be able to tell which decision is still pending.

An API key can read the case and route work to people. A permitted person must make match decisions, complete outside checks and give approval. Dismissing a sanctions candidate must not close an unrelated activity case or mark an unfinished identity check complete.

Keep ongoing customers up to date

Use Counterparties for the customer's saved screening history and Monitoring for repeat checks. When facts change, review the monitor's saved request before restarting it. Inspect the latest successful screening and unresolved events. The existence of a monitor alone does not prove a recent check ran.

Follow the customer-screening walkthrough. Before linking it to onboarding, test three cases: an unresolved candidate, an unfinished outside check and a failed screening. Each should leave the right task open and tell the next person what to do.

Use four questions to explain the difference

Identity verification asks, 'Is this customer who they claim to be?' Sanctions screening asks, 'Do these facts match a party in our selected sources?' PEP screening looks for relevant public roles. Transaction monitoring looks at activity. One customer ID can connect the results without making the questions interchangeable.

For example, a fictional customer can pass an identity check and have no sanctions candidate while an unusual payment still needs review. Keep all three findings visible. SanctionsKit supports selected-source screening, review and monitoring; it is not a complete identity, PEP, media or transaction-monitoring service.

Frequently asked questions