The complete guide to AML and sanctions screening

Screening answers a question that verification cannot: is this party someone you are permitted, and prepared, to do business with? Identity checks establish who a customer is. Screening establishes whether that customer, their company, their owners or their payment counterparties appear on a sanctions list, hold public office, carry trade restrictions, or trail relevant negative news. The obligation is continuous, the liability for missing a sanctions match is generally strict, and the operational cost of doing it badly lands on the compliance team as a queue of false positives. This guide walks through each screening type in turn, then the data, tuning and governance that determine whether the program holds up.

What are regulated entities required to screen for?

Across the major regimes, four kinds of screening recur as obligations or firm supervisory expectations.

• Sanctions screening, on customers and on payments. Lists issued by OFAC in the US, Global Affairs Canada, the EU, the UK under OFSI, Australia and APAC jurisdictions designate persons, entities, vessels and restricted securities, along with comprehensively sanctioned geographies. A confirmed match is a prohibition in most cases, and sanctions regimes are generally strict liability: the defence is evidence that you screened, what you found, and what you did.
• Trade risk screening, on dual-use goods and restricted parties. The US Bureau of Industry and Security lists, the World Bank Listing of Ineligible Firms and Individuals, and the Canada Export Controls List capture exposure that a sanctions list alone does not: goods, end users and debarred counterparties in the trade chain.
• AML screening, against politically exposed persons, their relatives and close associates, and heads of international organizations. A PEP match is not a prohibition. It is a tiering signal that triggers enhanced due diligence, senior approval and closer monitoring, which is why flat yes-or-no PEP flags serve reviewers poorly. The distinction between the two responses is covered in our sanctions vs PEP screening guide.
• Reputational risk screening, against adverse media. Negative-news screening surfaces financial-crime-relevant coverage of a customer or counterparty, each finding tied to a source. It sharpens both sanctions investigations and PEP risk ratings, and supervisors increasingly expect it in a risk-based program.

The four kinds differ in what a match means and what response follows, but they share one operational spine: matching logic, alert handling and record-keeping. A program that runs them as four disconnected tools reconciles their differences by hand; a program that runs them on one spine routes each match to the correct response automatically.

Name screening: how matching actually works

Name screening, also called customer screening, matches a party's name and identifying details against the list data. The mechanics decide everything downstream, so they are worth understanding precisely.

Exact matching fails immediately in practice, because listed names rarely arrive in one canonical form. Transliteration from Cyrillic, Arabic or Chinese scripts produces several accepted spellings of the same person. Aliases, honorifics, initials, and order-reversed name parts multiply the variants. Screening engines therefore match approximately, using techniques such as edit distance and phonetic encoding, with a threshold that sets how far from exact a candidate may be and still raise an alert.

That threshold is the central trade-off of the discipline. Set it tight and true matches hide behind a spelling variant. Set it loose and every common name in the book raises an alert. The way out of the trade-off is not the threshold dial; it is the identifiers around the name. A date of birth, a nationality, a registration number, a known associate or an ownership link lets the engine separate the listed Mohammed Khan from the thousands who merely share the name. Screening against thin records forces name-only matching, which is the single largest cause of false positives. The causes and fixes are set out in our false positives guide.

Well-run name screening therefore has three properties: list data enriched with identifiers, matching that evaluates multiple attributes instead of name similarity alone, and a documented threshold policy that ties the settings to the firm's risk assessment.

Entity and KYB screening: structures, owners and the 50% Rule

Screening a business by its registered name checks the storefront and ignores the building. Corporate exposure usually sits with the people and entities behind the name: beneficial owners, intermediate holding companies, nominee directors and related parties. Entity screening links the business, its owners and its connected parties into one structure and screens the whole of it, at onboarding and afterwards.

The 50% Rule makes this mandatory in substance if not in name. Under the attribution principle applied by OFAC and mirrored in other regimes, an entity majority-owned by a sanctioned party is treated as sanctioned even when it appears on no list itself. Exposure two or three ownership layers up the chain is invisible to a name check and fully visible to deep-tier ownership mapping. The screening consequence is direct: a clean top-level company with a sanctioned ultimate owner is a prohibited relationship you can only detect structurally. Our entity screening page covers the workflow, and the KYB obligations that surround it are set out in the KYB guide.

Payment screening: the check that runs inside the flow

Payment screening matches the parties to a transaction, the originator, the beneficiary, their institutions and any intermediaries, against sanctions and watchlists while the payment is in flight. It differs from customer screening in three ways that shape how it must be built.

First, the population is different. A payment routinely involves parties the firm never onboarded and holds no file on. The beneficiary of an outbound wire is screened on the data in the payment message alone, which makes message quality a compliance issue: structured party fields, as carried in ISO 20022 messages, materially improve matching over free-text fields. Deliberate degradation of that data, the typology known as wire stripping, is itself a red flag regulators have warned about.

Second, the clock is different. A held payment is a customer promise broken and a settlement obligation at risk, so screening must run in real time and clear the overwhelming majority of payments untouched. The operational failure mode is not missing the check; it is a queue of false-positive holds that delays legitimate transfers for hours. Entity resolution applied before a hold is placed keeps clean payments moving and stops only the transfers that carry a genuine signal.

Third, the consequence is different. A payment released to a sanctioned party is a completed violation, not a pending risk, which is why payment screening concentrates on sanctions and why every hold, release and escalation needs its own recorded rationale. The full workflow is described on our payment screening page.

Delta screening: re-screening without the alert flood

A customer who cleared at onboarding can become a match the next day, because the lists changed or because the customer did. The traditional answer is the periodic batch re-screen: run the whole book against the whole list set every night, week or month. It works, but it produces a predictable pathology: every run re-adjudicates thousands of matches the team has already dispositioned, and any list update touching common names lands as an alert spike on review day.

Delta screening is the sharper instrument. Instead of re-running everything, the engine screens the standing book against the changes: new designations, amendments and delistings as they are published, and re-screens a customer record in full only when that record itself changes. The result is a steady stream of small, explainable alert sets, each tied to a cause. When a new designation lands, the firm knows the same day which customers it touches, and the alert arrives with the reason attached: this name was added, this record was amended, this is what changed.

Delta screening does not retire the full re-screen entirely. Three events still call for one: a change to matching logic or thresholds, since prior clearances were made under different rules; a data migration or backfill, since the book itself changed shape; and periodic assurance, where a full pass validates that the delta process has not silently missed a feed. A documented policy stating when each mode runs, and why, is exactly the kind of evidence an examiner asks for. Cadence by risk tier is covered in our screening frequency guide.

The screening modes side by side

The data layer: what you screen against decides what you catch

Screening quality is set upstream of the matching engine. A record with no identifiers beyond a name forces any engine, however sophisticated, into name-only matching. Four properties of the list data determine the outcome.

• Coverage. Sanctions across OFAC, Canada, the EU, the UK, Australia and APAC regimes, including sanctioned geographies, vessels, ports and restricted securities; trade restriction lists; tiered PEP, RCA and HIO data; adverse media with source citations.
• Enrichment. Aliases, dates of birth, locations, identifiers, relationships and ownership information on each record, so matching can discriminate rather than guess.
• Structure. Ownership links and associate networks recorded as connections, which is what makes 50% Rule exposure computable at all.
• Freshness. Continuously maintained records with regular updates, because a designation issued this morning is exposure this afternoon. Delta screening is only as good as the change feed beneath it.

Firms that run their own screening technology face the same data questions, which is why watchlist data is worth evaluating as a product in its own right. Ours is described on the data page.

False positives: the operational tax on every mode

With traditional name-only screening, the vast majority of alerts are false positives, and the cost compounds differently in each mode: stalled approvals at onboarding, held payments in the flow, and reviewer fatigue in monitoring, where a genuine match risks being cleared on autopilot among the noise. Loosening thresholds is not a fix; it trades false positives for missed true matches, which is the worse failure. The durable fix is resolution: scoring identity coherence across candidate matches so that spelling variants, transliterations and homonyms collapse into one assessed identity before a human sees them. Done with enriched data, this approach is designed to reduce false positives by up to 80% without dropping true risk, and every surviving hit keeps the reasoning that escalated it.

From alert to disposition: working what screening raises

Screening ends in a decision, and the decision is what the regulator examines. A workable alert process has four elements: scored prioritization so the highest-risk matches are worked first; evidence assembled onto the case, including the match rationale and the conflicting information that argues against it; a recorded disposition naming the reviewer and the reasoning; and retention of the whole chain, including the false positives that were cleared and why. Automation can prepare all of it, and triage, routing and case preparation are precisely where human-in-the-loop automation earns its keep, provided material decisions remain subject to human review and approved policy. The workflow is described on our alert triage and case investigation page.

Governance: what an examiner actually reads

Examiners rarely fault a firm for the existence of a false positive. They fault undocumented thresholds, clearances without reasoning, list coverage nobody can state, and re-screening policies that exist only in practice. The governance file for a screening program is short to describe and demanding to maintain: a documented risk-based threshold policy tied to the firm's risk assessment; a stated list of what is screened against and when; testing evidence for matching logic, before deployment and after every material change; a delta and full re-screen policy with its rationale; and a complete audit trail from alert to disposition. The expectation is consistent whether the examiner is FINTRAC in Canada, FinCEN and the federal banking agencies in the US, the FCA and OFSI in the UK, or a national supervisor in the EU. Screening evidences itself when the system records the decision as a by-product of the work, which is the standard to hold any platform to.

How our platform runs the full cycle

Our screening engine runs all four kinds of screening on one spine: name and entity screening with deep-tier ownership mapping under the 50% Rule, real-time payment screening on originators, beneficiaries and counterparties, and event-driven re-screening as lists change, with an explanation of what changed on every new alert. Agentic entity resolution clears the noise before a reviewer sees it, and every hit, hold and disposition is captured as an audit-ready case history. It deploys three ways: a self-serve screening API, a compliance platform with integrated case management, or the watchlist data on its own for firms that run their own technology. The product detail is on the AML screening page.

FAQ