What is sanctions screening?

Screening is the operational core of sanctions compliance: designations only protect you if you actually check counterparties against them. The check itself is conceptually simple — does this identifier appear on a list? — but doing it well means handling normalization, list updates, match review and record-keeping, at the speed of a product flow rather than a batch job.

In crypto and fintech products the identifiers go beyond names: sanctions records now carry wallet addresses, email addresses, websites and ID numbers, and each of those is screenable at the moment it enters your system.

A screening system ingests the lists it covers, extracts and normalizes the identifiers in each record, and answers lookups against that data. Matching strategy depends on the identifier type. Wallet addresses, emails and websites are exact identifiers: after normalization (case, formatting), an identifier either appears in a record or it does not. Names and ID numbers are messier — transliteration, aliases and partial data mean systems use similarity techniques, and every candidate match needs human review against the official source record.

CompliAPI's implementation reflects that split: exact lookups on normalized values for addresses, emails, websites and countries, and exact or substring matching for government IDs with candidates ranked by trigram similarity — so a partial ID still surfaces ranked candidates, each with the official source record attached for review.

Screening is a checkpoint, and products have several natural ones. At onboarding, screen the identifiers a customer or partner submits before the relationship starts. Before value moves, screen the transaction-specific identifiers — a withdrawal address, a payment recipient — because the counterparty of a transfer is often not the customer you onboarded. And on an ongoing basis, re-screen stored identifiers as lists change: a customer who was clear at onboarding can be designated afterwards.

The right cadence for re-screening is a policy decision, but the data side is measurable: screening is only as current as the list data behind it, which is why ingestion frequency matters when evaluating tooling. CompliAPI re-ingests the OFAC SDN list every 15 minutes and refreshes its other sources daily or weekly.

Direct screening answers whether an identifier appears on a list. Indirect screening — the domain of blockchain-analytics platforms — asks whether a counterparty is connected to designated actors through transaction history, address clustering or exposure scoring, even when the counterparty itself is not listed.

The two answer different questions and carry different costs. Direct checks are fast, deterministic and easy to audit, which suits inline product flows. Indirect analysis is probabilistic and needs interpretation, which suits investigation and risk-scoring workflows. Many compliance programs use both; CompliAPI provides the direct layer.

A bare yes/no answer is hard to defend to a regulator or an auditor. A reviewable screening result names the list that matched, labels what kind of list it is — a sanctions designation carries different obligations than a crime or risk dataset — and links to the official source record so a human can verify the hit. Equally important is the request log: a record of what was screened, when, and what came back, kept per organization.