Customer screening: run a check and keep records up to date

What does customer screening involve?

Customer screening checks a person or business against the lists your team has chosen. You then review possible matches and decide what else needs to happen before the relationship can proceed. SanctionsKit keeps the check, review and later checks linked, so your team can follow the customer's history.

For a one-time check, open New screening in the dashboard. For an ongoing customer, choose Use a saved profile or create a record in Counterparties. Add your own customer reference and the legal name, subject type and facts you have verified. Two customers with the same name still need two records. Screen a company and its owners as separate subjects when your policy requires both.

Choose the coverage before running the check

Select the approved policy or the available sources your process calls for, then choose Run screening. Check that the choice fits the subject type. If a required source is unavailable, keep the check pending while you resolve the gap. Saving a customer profile does not mean that customer has been screened.

An API request sends subject and exactly one of sources or package. Use reference for the operation. Include counterpartyId only when it identifies a saved profile with the same current subject facts. API keys can read and link saved profiles; a permitted person must create or edit them. The counterparty API guide explains these fields.

Review the result before closing the task

A retained potential match opens a case for review. In Review queue, compare the listed record with the customer. Add useful facts, explain each match decision and record the separate business action. Finish any outside checks and approval that the policy requires.

A no-match result can still need a case when the policy requires outside checks or business approval. For example, a company may have no list match while its ownership review remains open. Keep screening errors pending in the onboarding system. Neither an error nor an unfinished case should become an approved customer by default.

Find the history behind a customer record

Open Counterparties to find the customer's screenings, cases and monitors. Read the facts submitted with the check you are reviewing. A current address or corrected name does not change what an earlier check used. Keeping both versions helps explain a result that differs from today's result.

Developers can read GET /api/v1/counterparties/{id}/history with kind=screenings, cases or monitors. Follow nextCursor until it is null to read the full history. The short arrays in the detail response are previews. An empty preview is not proof that no older record exists.

Update the customer and any linked monitors

Create a monitor when the relationship needs repeat checks, then confirm that its first screening succeeds. An active label alone is not enough. A change to saved customer facts pauses linked monitors. Check the monitor's full saved subject and coverage, make the needed changes, and resume it. Read the next result to confirm the change took effect.

Correcting a case identity creates a replacement screening and case; the older history stays available under its retention policy. When the relationship ends, stop monitoring through the approved process and keep the required records. The monitoring walkthrough covers setup and follow-up.

Check for customers who fell through a gap

Compare the customers who should have been checked with those who have a completed result for the required lists. Look for accounts opened during an outage, changed names that were never checked again, and closed accounts with active monitors. These gaps can exist even when the review queue is empty.

Give each gap an owner and a next step. For a large import, count source records, submitted rows, completed checks and failed rows separately. The batch-screening guide shows how to match each row to its result. An accepted file cannot prove that every customer in it was screened.

Frequently asked questions