Practical guide
Customer screening: connect onboarding, review, and monitoring
Design customer and counterparty screening around stable identities, selected sources, documented match decisions, and changes across the relationship.
On this page
Screen the customer record, not just a name in a form
Customer screening works best when the result belongs to a stable internal record. Identify the person or legal organization, capture reliable known facts, and record which version of those facts was submitted. A name copied from an email signature is not necessarily the contracting party’s legal identity.
Identity verification and business verification are separate controls. Screening uses the information supplied; it does not establish that the person submitting the form is entitled to act for the customer.
Choose a checkpoint with a defined consequence
Decide when the organization needs the result: onboarding, a relationship change, a payment-party review, or another policy-defined event. Define the next action for potential matches, completed no matches, and incomplete checks before integrating the API.
If the application saves a customer before screening completes, use an explicit pending state. Do not let a successful database save imply that screening or approval also succeeded.
Keep one identity history across teams
Compliance and operations should be able to see the internal reference, submitted facts, source coverage, retained screening, and review outcome. Record corrections rather than silently overwriting the context for earlier results.
For an invented business customer, an onboarding operator initially enters a trading name. Later evidence identifies a different registered legal entity. The corrected entity needs a documented new screening, while the first result remains part of the history.
Handle related parties deliberately
A company’s owners, authorized representatives, and payees may be relevant under the organization’s policy. Identify those roles and screen them as appropriate rather than treating them as aliases of the company. OFAC’s ownership guidance also makes clear why direct-list matching and ownership analysis cannot be treated as the same control.
Do not infer a complete ownership tree from a customer’s name or a match result. Store the provenance and date of ownership evidence separately.
Connect monitoring to the relationship lifecycle
Define when monitoring starts, which identity version it uses, what happens when the customer changes, and when monitoring is paused or stopped. A closed relationship and a retained historical screening have different lifecycles.
SanctionsKit counterparty records can connect screening history and monitoring. Scheduled and source-triggered rescreens need review ownership, and a monitoring issue must remain visible until resolved.
Measure completeness, not only approval speed
Track the population that should be screened, completed coverage, unresolved candidates, failed checks, stale customer inputs, and monitoring issues. A fast onboarding flow can still leave gaps if failures disappear from the operational queue.
Use the rollout guide to test a representative population before expanding. Keep the screening control understandable to the people who need to explain it later.