Sanctions Screening / Learning brief
Sanctions screening system architecture
Your notes
In simple terms / 01
What this means in plain language
A screening platform connects list management, a matching engine, hold queues, and case-management tools inside the payment path. Its design answers hard questions about latency and availability, because a filter that silently stops checking is the dangerous failure.
A sanctions screening platform is not one program but several parts that must fit together. List management ingests files from official issuers and vendors, cleans them, and publishes the single watchlist the engine runs against. The matching engine scores names and raises alerts. Integration wiring connects that engine to its callers: the onboarding system, the payment engine for each rail, and overnight batch jobs that re-screen the whole customer base, some needing an answer in seconds, others submitting millions of records at once. An alert store and case-management layer gathers related alerts, evidence, and decisions into one investigable file with a full audit trail. Reporting sits across everything, tracking volumes, backlogs, and hit rates. The parts may come from one vendor or several, and the seams between them are where coverage gaps hide. The design also has to survive stress, meaning tight time budgets, outages, and alert spikes after major events.
Complete lesson / 02
Understand the full idea, step by step
A tollbooth on a busy motorway has two hard jobs at once: check every vehicle and never become the reason traffic stops. Build it too slow and the queue backs up for miles; switch it off to clear the queue and the check is worthless. A sanctions screening platform lives with the same tension, sitting directly in the path of live payments.
The parts of a screening platform
A platform is best understood as cooperating parts, each with a clear job. List management ingests files from official issuers and commercial vendors, normalises their differing formats, resolves duplicates, and publishes the single watchlist everything else runs against. The matching engine scores a name against that list and raises an alert when similarity crosses the configured line. Integration wiring connects the engine to its callers. An alert store and case-management layer gathers related alerts, their evidence, and their decisions into one investigable case with a full audit trail. Management reporting sits across all of it, tracking volumes, backlogs, queue aging, and hit rates. These parts may come from one vendor or several — and the seams between them are exactly where coverage gaps hide.
Real-time (inline) vs batch screening
The same engine is called two ways. Inline screening sits in the live payment path: the payment engine asks about each payment and waits, so screening is handed a strict slice of the rail's time budget and must hold to it around the clock. Batch screening re-screens a whole population at once — every customer when a list changes, or a day's traffic in a lookback — where throughput matters more than per-item latency. A mature build uses both: inline to stop a payment before it moves, batch to catch what a newly designated party or a fixed filter would now match.
How a held payment moves through the platform
- VALIDATION
The payment engine calls the matching engine inline, within its slice of the rail's clock, and waits for a verdict.
- VALIDATION
The matching engine scores the parties against the published watchlist and returns pass or alert.
- NOTIFICATION
On an alert, the hold mechanism parks the payment in a queue and opens a case in the alert store, gathering related alerts about the same party.
- NOTIFICATION
A reviewer works the case against the clock, records a disposition, and the payment is released onward or stopped — every step logged with the list and configuration versions.
WHAT IF — The matching engine becomes unavailable while payments are arriving
What happens: The caller must choose in advance: hold and queue payments until the engine recovers, or let them through unchecked. Releasing payments unscreened — failing open — is rarely defensible for sanctions.
How it is handled: The chosen failure posture is documented and tested before any outage, not improvised during one. For sanctions, the safe default is to fail closed: hold the payments and let the queue grow rather than let an unchecked payment settle.
Why size the engine for a quiet Tuesday's volume when most days look like that?
Because the day that matters is the loud one. A major geopolitical event triggers a large list update and an alert spike at precisely the moment timeliness matters most. An engine sized for the average will fall behind exactly when it can least afford to. So capacity is planned for peaks, not averages — and duplication is designed out, because if both the payment engine and a customer channel screen the same payment, investigators drown in double alerts unless the platform removes them.
STRICTLY SPEAKING
Strictly speaking, what separates a mature build is reconstruction. Every screening decision is logged with the list version and configuration version in force, so any past outcome can be explained — why Tuesday's payment passed and Thursday's alerted. That record is the foundation for a lookback, re-examining historical traffic after a new designation or a filter fix. Duties are separated: the person who tunes the engine is not the person who approves the tuning, and neither can silently alter the audit trail. Institutions assemble these pieces very differently — a shared utility or a filter per rail, built or bought — but the reconstruction test does not vary.
FOR NOW, REMEMBER
- A screening platform is cooperating parts: list management, a matching engine, integration wiring, an alert store with case management, and reporting.
- The same engine is called inline (in the live path, on a strict clock) and in batch (whole populations when lists change) — both are needed.
- The revealing questions are about stress: latency budget, failure posture, and peak capacity; failing open is rarely defensible for sanctions.
- Maturity is proven by reconstruction — every decision logged with list and configuration versions, with duties separated and an untouchable audit trail.
TRY IT YOURSELF
Bank Alfa's matching engine goes offline mid-morning and payments keep arriving on a real-time rail. No failure posture was agreed in advance. What is the defensible default for sanctions?
The platform can only screen the names it is given. The next lesson turns to the data itself: why complete party information must reach every institution, and what controls detect when someone strips it out.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
A screening platform has recognisable parts: list management, a matching engine, integration to each caller, hold queues, and case management with an audit trail.
- 02
The same filter serves callers with very different needs; a payment rail wants an answer in seconds, while rescreening the customer base submits millions of records overnight.
- 03
The dangerous failure is silence: a filter that loses its list feed yet keeps releasing payments looks healthy while checking nothing, so architecture must make that failure loud.
Practical use cases / 04
Where you would use this
A solution architect places the screening engine in the payment path with a strict time budget, and designs a documented, tested failure posture instead of discovering one during an outage.
A list-management team ingests and normalises issuer and vendor files, then publishes a versioned watchlist so every alert can be tied to the exact list version in force.
An investigator uses case management to see customer-screening and transaction alerts about the same party in one file, rather than deciding parallel half-pictures in isolation.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional bank, Harbourline Bank, joins an instant-payment rail that promises the payer a final answer within 10 seconds. The bank allots the screening engine a strict 2-second slice of that budget, running around the clock. One morning a geopolitical event triggers a large watchlist update, and the alert rate jumps from a typical 40 alerts per hour to 900. Because the engine was sized for peaks and its failure posture is documented, meaning hold and queue payments for review rather than release them unchecked, the rail keeps its 10-second promise for clean payments while flagged ones park safely in the hold queue. A separate channel that also screened the same payments would have doubled every alert, so the bank deduplicates them into one case. Each decision is logged against the exact list version in force.
Evidence & review / 07
Evidence & review
Sanctions screening system architecture generally; deployment models and rail rules vary by institution and jurisdiction.
What this brief simplifies: Describes a canonical component set and the inline/batch split. Real platforms differ in vendor mix, alert-state models, and utility-versus-per-rail design.
Sources for this brief2
- Market practice
Wolfsberg Group Sanctions Screening Guidance ↗ — The Wolfsberg Group
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
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.