The screening lifecycle
From data in to decision out: how a screened record passes clean, or becomes an alert, a held payment, and finally a documented disposition.
L0 Explain simply
An everyday analogy: watch one visitor cross the gate. The gatekeeper compares the visitor with the posters. Almost always there is no resemblance, and the visitor walks through without ever knowing a check happened. Occasionally something looks similar; the visitor is asked to wait, and a second, trained person compares everything on the poster with everything the visitor can show. The outcome is written in a logbook: released as an innocent lookalike, or escalated because it really might be the person on the poster. The visitor never gets a quiet shrug — every hold ends in a recorded decision. That routine, repeated millions of times, is the screening lifecycle.
L1 Core concepts
The lifecycle has a standard shape. Input data — a customer record or payment message — is normalised and compared against the watchlist. Most records match nothing and pass straight through; processing continues untouched. When the matcher finds a resemblance above threshold, it raises an alert: the payment is held in a queue, or the onboarding pauses, until a trained reviewer compares the alerted party with the list entry. The reviewer's documented outcome is the disposition: release as a false positive, or escalate as a potential true match, at which point sanctions compliance decides on freezing, rejecting, or reporting — with legal advice where needed. Every step is logged: what was screened, against which list version, who decided what, and why.
L2 Practitioner view
Practitioners live in the proportions. The overwhelming majority of screened traffic passes untouched; of the alerts that are raised, most turn out to be false positives; genuine matches are rare. That shape has consequences: reviewer staffing follows alert volume, queues must be worked fast enough that held payments still meet cut-offs, and the rare true match must survive the monotony — the process has to stay sharp through thousands of innocent lookalikes. Controls reflect this: maker-checker review on releases, so no single person can wave a payment through; queue aging and backlog monitoring, because a growing queue is both a service problem and a risk problem; and quality sampling of closed alerts to confirm dispositions would survive scrutiny.
L3 Technical details
Details that distinguish well-run implementations: each disposition is recorded against the exact list version and matching configuration in force, so the institution can later reconstruct why Tuesday's payment passed but Thursday's alerted. Alerts carry explicit lifecycle states — new, in review, escalated, closed — with timestamps that feed service metrics: alert rate, false-positive rate, time to disposition. Related alerts about the same party are linked into a case rather than decided in isolation. Suppression of repeat matches on recurring traffic is possible but governed: documented criteria, expiry dates, and re-review when either the list entry or the underlying party data changes. The metrics loop back into tuning — the lifecycle produces the evidence that later justifies changing it.
Sources & standards1
- Market practice
Wolfsberg Group Sanctions Screening Guidance ↗ — The Wolfsberg Group · Alert generation and handling; presentation of alerts to trained sanctions personnel
Wolfsberg guidance is industry market practice, not law; institutions vary in how they apply it.
Sources for this topic2
- Market practice
Wolfsberg Group Sanctions Screening Guidance ↗ — The Wolfsberg Group · Screening technology and generating productive alerts
Wolfsberg guidance is industry market practice, not law; institutions vary in how they apply it.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: The single-visitor walkthrough compresses parallel, automated processing into one sequential story, and alert-state models differ between screening products. The linked clean-pass scenario uses fictional parties and a simplified queue model.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
Deepest material on this page: L3 — Technical details. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.