KYC vs AML vs sanctions screening: a practical comparison

Start by asking what each task proves

KYC, or know your customer, helps establish who a customer is. AML, or anti-money laundering, covers a wider set of controls. Sanctions screening compares known customer facts with selected sources. SanctionsKit handles that comparison and review; it does not verify identity documents or discover company owners.

After KYC or KYB has identified the person or business, open the dashboard. Create or select a Counterparties profile for an ongoing relationship, then choose New screening. For an API check, include a stable operation reference. Use the correct subject type and the actual precision of dates and identifiers.

Submit facts without filling gaps by guesswork

The example below sends POST /api/v1/screenings with a sandbox key. It uses invented data. Follow the quickstart for Authorization and a stored Idempotency-Key. If you know only the birth year, send that year. Adding a month and day creates a fact you have not verified.

For Production, replace sandbox@1 with one approved coverage selector checked through source discovery. Add the published policy reference when required. Use counterpartyId only for a real saved profile whose current subject matches the request. The reference links records; it does not make different identities the same.

{
  "subject": {
    "name": "Alex Morgan",
    "entityType": "person",
    "birthDate": "1984"
  },
  "reference": "synthetic-onboarding-27",
  "package": "sandbox@1",
  "retention": "standard"
}

Track four separate milestones

A completed API response returns data.status as potential_match or no_match. Store it with the result ID and coverage. Missing results, errors and source failures remain pending work in your application. They are not extra successful ScreeningResult statuses.

Use Review queue for candidates and policy-required tasks. 'Identity verified,' 'screening complete,' 'match reviewed' and 'relationship approved' each describe a different milestone. The review API lets your application read the current case while leaving human decisions with permitted reviewers.

Handle a correction as new evidence

When you verify a corrected name or date, update the saved profile in the authorized dashboard flow. Earlier screenings keep the facts they used. Linked monitors pause so you can check their saved subject and resume them with the right details.

If a correction arises during a case, use its identity-correction flow. This creates a linked new screening and replacement case while keeping the earlier history. Review the replacement result. An old dismissal may have relied on a fact that is now different.

Keep outside checks visible

Screening policies can require tasks your team performs elsewhere. State what evidence a reviewer should record and finish each task through the approved process. Adding a PEP or ownership check does not make SanctionsKit perform that research.

Follow customer screening to finish the product steps. Test a corrected date, an unresolved match and a no-match with an unfinished outside task. Your onboarding screen should make each remaining task clear, rather than hiding all the states behind one risk score.

Leave room for wider AML work

An AML program can involve payment review, reporting, training, internal controls and independent testing. The requirements depend on the institution and activity. A sanctions case can support that work, but it cannot replace every part of the program.

For a fictional company, verified registration details establish one set of facts. A no-match establishes what a selected list check found. An open source-of-funds question is still open. Keep the evidence and scope for all three so the person making the business decision can see the full task.

Frequently asked questions