Screening system architecture
One filter, many callers: how watchlist feeds, matching engines, hold queues, and case management fit into the bank's payment estate.
L0 Explain simply
An everyday analogy: the gate is not one guard but a small system. A poster room receives and organises the posters from every authority. Scanners stand at each entrance — the front door, the parcel gate, the loading dock — all consulting the same poster room. A waiting room holds anyone flagged. And an investigation office gathers every piece of paper about one flagged visitor into a single file, so the decision is made once, with everything known, instead of three times with fragments. The dangerous failure is silence: if a scanner loses its connection to the poster room and keeps waving people through, the gate looks open and working — and checks nothing. Architecture is what makes that failure loud.
L1 Core concepts
A screening platform has recognisable parts. List management ingests issuer and vendor files, normalises them, and publishes the watchlist the engine runs on. The matching engine scores names and generates alerts. Integration connects the engine to its callers: the onboarding system, the payment engine for each rail, batch jobs for rescreening the customer base — some callers need a synchronous answer in seconds, others submit millions of records overnight. An alert store and case management layer collects related alerts, evidence, and decisions into one investigable case with a full audit trail. Management reporting sits across it all: volumes, backlogs, aging, and hit rates. The parts can come from one vendor or several; the seams between them are where coverage gaps hide.
L2 Practitioner view
The hard practitioner questions are about behaviour under stress. Latency: an instant-payment rail gives the whole bank seconds, so screening gets a strict slice of that budget, around the clock. Failure posture: if the engine is down, does the caller queue payments until it recovers, or stop the rail — fail-open is rarely defensible for sanctions, and whichever posture is chosen must be documented and tested, not discovered during the outage. Capacity: list updates after major geopolitical events produce alert spikes precisely when timeliness matters most. Duplication: when the payment engine and a channel both screen the same payment, investigators see double alerts unless deduplication is designed in. And configuration promotion — a threshold change tested in one environment must be verifiably the thing deployed to production.
L3 Technical details
Marks of a mature build: every screening decision is logged with the list version and configuration version in force, so any historical outcome can be reconstructed exactly — the foundation for lookbacks, where an institution re-examines past traffic after a designation or a filter fix. Case management links customer-screening and transaction alerts about the same party, giving investigators one view instead of parallel half-pictures. Duties are segregated: the person who tunes the engine is not the person who approves the tuning, and neither can silently alter the audit trail. Retention honours both audit and lookback horizons. Institutions assemble these pieces differently — single utility or per-rail filters, in-house or vendor — but the reconstruction test is universal: can you prove what was screened, against what, and who decided?
Sources & standards1
- Market practice
Wolfsberg Group Sanctions Screening Guidance ↗ — The Wolfsberg Group · Screening technology; list management; historical reviews (lookbacks)
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 list management
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 component model is a reference architecture, not a product description; real estates split and combine these functions in many ways, and failure-posture choices depend on rail rules and institutional risk decisions that vary widely.
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.