Unit 05 · Chapter 2 · 9 min read

Screening engines and match resolution

Build a reliable list pipeline and an explainable review process.

The name is spelled three ways in three systems. One version loses an accent; another reverses the family name. Screening is a data-engineering problem before it is a matching problem.

Version the list pipeline

A screening decision depends on the list data used at that time. Track source, retrieval time, publication version where available, integrity checks, and activation time. A download that succeeds does not prove the file was parsed completely or deployed to every worker.

Use a staged activation: fetch, validate, compare, approve according to policy, activate, and confirm coverage. Preserve prior versions for replay and investigation. Alert on stale data, malformed records, unexpected count changes, and inconsistent worker versions. Do not silently continue forever with an old list after an update failure.

List ingestion is a production dependency. The system needs evidence that it obtained the expected release, parsed it correctly, loaded the intended records, and activated the right version. A successful download can still contain an unexpected format or an incomplete file. Compare counts and structural properties, preserve the source version, and define a controlled response when validation fails.

Screening results should identify the list and matching logic used at the decision time. Without that information, a later reviewer may replay an old payment against today’s data and mistake a changed result for an earlier system error. A current rescreen and a historical reconstruction are both useful, but they answer different questions and need separate labels.

Version the list pipeline Version the list pipeline — the flow Follow the sequence. Confirm the version used by workers. Fetch Retrieve the authoritative data Validate Check integrity and record changes Activate Confirm the version used by workers — Follow the sequence. Confirm the version used by workers. Chapter sources · Open image

Version the list pipeline Version the list pipeline — the distinction These concepts answer different questions. Read each definition in the context of the section. Downloaded version File reached the pipeline Active version Matching workers actually use it — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Version the list pipeline List deployment Fictional teaching record. Partial activation remains. List deployment Illustrative data; not a real customer record or a prescribed policy. Fetched v102 New source data Validated v102 Parsing passed Worker group B v101 Partial activation remains A successful download is not deployment completion — Fictional teaching record. Partial activation remains. Chapter sources · Open image

Version the list pipeline Version the list pipeline — control and failure modes A successful download is not deployment completion. The branches show why alternative designs fail. Control design Verify active versions across workers. A successful download is not deployment completion. Failure mode 1 Overwrite the prior list without history. Past decisions become hard to reproduce. avoid Failure mode 2 Ignore stale-list alerts. The control may miss new restrictions. avoid Failure mode 3 Accept an empty parse as a clean list. It may be a pipeline failure. avoid — A successful download is not deployment completion. The branches show why alternative designs fail. Chapter sources · Open image

Normalize without destroying identity

Normalization can standardize spacing, case, punctuation, and script handling. Preserve original names and identifiers. Some transformations improve matching; others collapse distinct names or lose useful information.

Test transliteration, name order, aliases, organization suffixes, and non-Latin scripts using representative fixtures. Keep the normalization version with the result. A matching change can alter both missed matches and false positives. Do not assume English name structure applies everywhere. The review screen should show the original source strings alongside normalized forms so the analyst can inspect the evidence.

Normalize without destroying identity Normalize without destroying identity — the flow Follow the sequence. Use aliases and relevant identifiers. Preserve Keep original identity strings Normalize Apply documented transformations Compare Use aliases and relevant identifiers — Follow the sequence. Use aliases and relevant identifiers. Chapter sources · Open image

Normalize without destroying identity Normalize without destroying identity — the distinction These concepts answer different questions. Read each definition in the context of the section. Normalized form Representation for comparison Original form Source evidence with its original detail — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Name processing

Fictional educational excerpt / Not for execution

Name processing

Illustrative data; not a real customer record or a prescribed policy.

Originalaccented source name
Retained evidence
Normalizedstandard comparison form
Search input
Versionnormalizer-v4
Reproducible transformation

Normalization can change identity meaning

Fictional teaching record. Reproducible transformation. Chapter sources · Open image

Normalize without destroying identity Normalize without destroying identity — control and failure modes Normalization can change identity meaning. The branches show why alternative designs fail. Control design Preserve originals and version transformations. Normalization can change identity meaning. Failure mode 1 Discard original script. Review loses useful evidence. avoid Failure mode 2 Assume all names have one first and last name. Name structures vary. avoid Failure mode 3 Tune only on English examples. Coverage may fail for other scripts. avoid — Normalization can change identity meaning. The branches show why alternative designs fail. Chapter sources · Open image

Use more than name similarity

A similarity score ranks candidate strings. It is not the probability that a person is sanctioned unless a separate validated model establishes that meaning. Dates, addresses, identifiers, aliases, and other relevant attributes can help resolve identity.

Define which mismatches are reliable and which fields can be incomplete. A missing birth date is not the same as a conflicting verified birth date. Record the evidence used for resolution and avoid a single unexplained false-positive button. Review decisions should be reproducible from the list record and customer evidence available then.

Use more than name similarity Use more than name similarity — the flow Follow the sequence. Record the evidence and reason. Candidate Generate plausible matches Identifiers Compare supporting attributes Resolution Record the evidence and reason — Follow the sequence. Record the evidence and reason. Chapter sources · Open image

Use more than name similarity Use more than name similarity — the distinction These concepts answer different questions. Read each definition in the context of the section. Missing identifier No value to compare Conflicting identifier Evidence supports a different value — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Use more than name similarity Match resolution Fictional teaching record. Documented resolution. Match resolution Illustrative data; not a real customer record or a prescribed policy. Name similar Candidate generated Identifier verified different number Distinguishing evidence Reason separate entity Documented resolution Name similarity alone is not a legal identity finding — Fictional teaching record. Documented resolution. Chapter sources · Open image

Use more than name similarity Use more than name similarity — control and failure modes Name similarity alone is not a legal identity finding. The branches show why alternative designs fail. Control design Resolve with identifying evidence. Name similarity alone is not a legal identity finding. Failure mode 1 Call a score a probability without validation. The scale may only rank strings. avoid Failure mode 2 Treat missing as conflicting. Absence is not disagreement. avoid Failure mode 3 Allow unexplained dismissals. The result cannot be reviewed. avoid — Name similarity alone is not a legal identity finding. The branches show why alternative designs fail. Chapter sources · Open image

Control suppression and re-screening

A resolved false match can reduce repeated work if the evidence and list context remain applicable. Suppression should be specific, documented, and reviewable. A blanket allowlist on a common name can hide a future relevant match.

Define when a prior resolution expires or must be reconsidered: changed customer data, changed list record, new ownership evidence, or another relevant trigger. Re-screen the required populations after material updates. Preserve why an alert was suppressed and what evidence supported the reuse. The system must be able to distinguish a reused valid resolution from an alert that was never evaluated.

Suppression reduces repeated work when a prior review has established a valid reason to clear a recurring match. Its scope matters. A clearance for one customer and one list entry should not silently clear every customer with a similar name. Bind the suppression to the evidence, relevant identifiers, reviewer, date, and conditions that invalidate it. Changes to the list, customer identity, or ownership can require a new assessment. The queue becomes quieter for a defensible reason rather than because yesterday’s conclusion became an unlimited exemption.

Control suppression and re-screening Control suppression and re-screening — the flow Follow the sequence. Trigger on relevant changes. Resolve Store the specific false-match basis Reuse Apply only within the valid scope Re-screen Trigger on relevant changes — Follow the sequence. Trigger on relevant changes. Chapter sources · Open image

Control suppression and re-screening Control suppression and re-screening — the distinction These concepts answer different questions. Read each definition in the context of the section. Specific suppression Customer-list pair with supporting evidence Blanket allowlist Broad bypass without sufficient scope — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Control suppression and re-screening Suppression record Fictional teaching record. Requires reconsideration. Suppression record Illustrative data; not a real customer record or a prescribed policy. Customer entity-72 Specific subject List record target-18 Specific candidate Trigger list identity changed Requires reconsideration New evidence can change the match — Fictional teaching record. Requires reconsideration. Chapter sources · Open image

Control suppression and re-screening Control suppression and re-screening — control and failure modes New evidence can change the match. The branches show why alternative designs fail. Control design Scope and expire reused resolutions. New evidence can change the match. Failure mode 1 Allowlist every similar name. That can hide another person. avoid Failure mode 2 Suppress without an audit record. The decision is not explainable. avoid Failure mode 3 Skip re-screening after relevant changes. The old conclusion may no longer apply. avoid — New evidence can change the match. The branches show why alternative designs fail. Chapter sources · Open image

Test failures and release controls

Screening outages need a defined product response. Mandatory controls cannot be bypassed merely to preserve conversion. A preapproved contingency might stop new releases, queue eligible work, or route to an alternate controlled process, depending on the legal and operational context.

Test timeouts, stale lists, partial updates, queue failures, and unauthorized release attempts. Keep manual release authority limited and logged. Reconcile all transactions held during an outage with their eventual disposition. A system that recovers technically but loses the held population has not recovered operationally.

Test failures and release controls Test failures and release controls — the flow Follow the sequence. Reconcile held work and dispositions. Fail Detect the control outage Contain Apply the approved contingency Recover Reconcile held work and dispositions — Follow the sequence. Reconcile held work and dispositions. Chapter sources · Open image

Test failures and release controls Test failures and release controls — the distinction These concepts answer different questions. Read each definition in the context of the section. Service restored Screening responds again Operational recovery Every held item has a supported outcome — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Test failures and release controls Outage recovery Fictional teaching record. Recovery not yet complete. Outage recovery Illustrative data; not a real customer record or a prescribed policy. Held payments 240 Preserved population Resolved 238 Completed dispositions Remaining 2 Recovery not yet complete Restored uptime does not resolve missing work — Fictional teaching record. Recovery not yet complete. Chapter sources · Open image

Test failures and release controls Test failures and release controls — control and failure modes Restored uptime does not resolve missing work. The branches show why alternative designs fail. Control design Reconcile all held transactions after recovery. Restored uptime does not resolve missing work. Failure mode 1 Approve all during timeout. That can bypass required controls. avoid Failure mode 2 Give every agent release authority. Sensitive overrides need restricted ownership. avoid Failure mode 3 Drop the queue on restart. The obligations and decisions remain. avoid — Restored uptime does not resolve missing work. The branches show why alternative designs fail. Chapter sources · Open image

Chapter connections

This chapter builds on Sanctions scope, prohibitions, and licenses. Continue with Ownership graphs and the 50 Percent Rule to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.

Sources

Reviewed 2026-09-17