Name and entity screening

Name screening is the oldest sanctions control and still the one supervisors test first. It decides whether a designated person can open an account, receive a withdrawal or appear as the beneficiary of a Travel Rule message. Done badly, it either floods analysts with meaningless alerts or quietly misses the one name that matters; this lesson covers how to build, tune and evidence it.

List sources and list management

List management is the end-to-end process of choosing, sourcing, loading and maintaining the lists a firm screens against. It starts from the regime decision described in the lesson How sanctions work:

• the UN Security Council Consolidated List, published in machine-readable form, with a permanent reference number for every entry;
• the lists of every autonomous regime the firm applies;
• internal lists: former customers exited for sanctions reasons, known front companies, and persons or entities the firm has decided not to serve.

Every list load is a controlled event. The firm should record the list source, the version or publication timestamp, the time it was loaded into the screening system, and the number of entries added, changed and removed. Comparing those counts with the publisher's own announcement is a simple completeness check. Because the FATF expects freezing without delay, the time from a list publication to rescreening of the whole customer base should be measured in hours, and the measured time should be reported to management.

List data needs care. Entries may carry several names in different scripts, partial dates of birth, and aliases of uneven quality. The UN list labels some aliases as low quality, and the Wolfsberg Guidance on Sanctions Screening (2019) describes weak aliases as broad or generic names, such as nicknames and common acronyms, against which screening is "not expected, nor is it typically productive". A documented decision to exclude or down-weight weak aliases is a legitimate tuning choice; an undocumented one is a gap.

What gets screened

Beneficial owners matter as much as account holders, since ownership and control rules can make an entity prohibited even when its own name is clean. Travel Rule data is easy to forget: the beneficiary name in an incoming message is a party the firm is dealing with, and it should be screened before funds are credited (see the lesson Travel Rule data and messaging).

Preparing the firm's own data

Screening quality depends as much on customer data as on list data. Many missed matches trace back to how the firm stored the name in the first place. Good practice for reference data includes:

• separate fields for given names, family name and full name as written, rather than one free-text field;
• the name in its original script as well as the Latin transliteration shown on the identity document;
• full date of birth, nationality and document numbers captured as structured fields, so they can be compared automatically with list identifiers;
• for legal entities, the registered name, trading names, former names and registration number;
• a rule that every record must be screened before an account becomes active, so that a missing field cannot let a customer bypass the engine.

Normalization before matching removes noise that would otherwise lower scores: converting to one case, stripping punctuation and diacritics consistently, standardizing legal suffixes such as "Ltd" and "Limited", and removing honorifics. The same normalization must be applied to list data and customer data, or the comparison is lopsided. Changes to normalization rules are changes to the control and should be tested and approved like any threshold change.

Fuzzy matching

Exact matching fails because names are not stable strings. The same person may be recorded with different spellings, word orders and scripts. Fuzzy matching scores how close two names are rather than demanding identity. Common difficulties include:

• transliteration: names from Arabic, Cyrillic, Chinese, Korean or other scripts can be rendered in Latin letters in many ways, so a system needs transliteration variants or phonetic comparison;
• name order and structure: family name first or last, patronymics, compound surnames, particles and honorifics;
• truncation and initials: names shortened by a form field or recorded with initials;
• aliases: a match against any listed alias counts, but weak aliases generate noise;
• entity names: legal suffixes, translated names and abbreviations.

Algorithms combine edit-distance measures, phonetic codes and token comparison into a score. The score alone should not decide anything. Secondary identifiers such as date of birth, nationality, place of birth, identity document numbers and registration numbers separate a real match from a namesake. Partial dates of birth are common on lists: an entry may show only a year, or "circa" a year, or several possible dates. A customer born in that year is consistent with the entry; a customer born decades later is not.

Onboarding screening and rescreening

Screening at onboarding stops a designated person from entering. Rescreening keeps the customer base clean as lists and data change. Three triggers are needed:

1. List change: every addition or amendment is screened against the whole customer base, usually through a delta file, the same day.
2. Customer data change: a new name, nationality, address or beneficial owner triggers screening of the changed record.
3. Periodic full rescreening: a full run catches anything the deltas missed, such as a change in matching rules or a failed load.

A firm that screens only at onboarding will miss customers designated after they joined, which is one of the failures most often cited in public enforcement actions.

Threshold tuning: false positives and false negatives

Every match score is compared with a threshold. A lower threshold catches more variants and generates more alerts; a higher threshold reduces noise and raises the risk of a miss.

Because a false negative can be a violation, thresholds should be set by testing, not by complaint volume. Good practice is to run a test file of seeded names, including transliteration variants, reordered names, typos and aliases of real list entries, through the production configuration, and to measure how many the system catches at different thresholds. Sampling below the threshold, by having analysts review a random set of near-miss pairs, shows what is being lost. The Wolfsberg guidance expects tuning before deployment and on an ongoing basis, with independent testing supported by metrics.

Alert resolution and documentation

An analyst resolving an alert compares the customer's data with the list entry, identifier by identifier, and records a decision: false positive, possible match requiring escalation, or true match. True and possible matches go to the sanctions officer, and confirmed matches trigger the freeze, block and report steps. A record might look like this:

{
  "alert_id": "SAN-2026-004417",
  "list_source": "UN Consolidated List",
  "list_version": "2026-10-27T18:05Z",
  "list_ref": "QDi.xxx",
  "customer_id": "C-88213",
  "match_score": 0.91,
  "matched_field": "alias",
  "comparison": {"name": "partial", "dob": "customer 1994 vs listed circa 1961",
                 "nationality": "different", "document": "no listed number"},
  "decision": "false_positive",
  "rationale": "Shared surname only; DOB 33 years apart; nationality differs",
  "analyst": "A-117", "reviewed_by": "A-042",
  "closed_at": "2026-10-28T09:14Z"
}

The record names the list version, so an auditor can reproduce what the system saw; compares each identifier rather than saying "not the same person"; and shows a second reviewer, which many firms require for true matches and for a sample of false positives. The list reference is truncated here because it is a fictional example.

Repeated false positives on the same customer can be suppressed with a good-guy list entry, but only for that customer-entry pair, with a reason, an approver and an expiry or review date. If the list entry changes, the suppression must lapse automatically.

Exam focus: list management and evidencing each load (source, version, timestamps, counts); rescreening the whole base within hours of a list change; what to screen, including beneficial owners and Travel Rule originator and beneficiary names; fuzzy matching problems (transliteration, name order, aliases, weak aliases) and the role of secondary identifiers, including partial dates of birth; the three rescreening triggers; false positives versus false negatives and tuning with seeded test files and below-threshold sampling; what a complete alert record contains; controlled good-guy lists.