Aggregation and provenance
Most banks screen against an aggregated watchlist built from many official lists — convenient, powerful, and a new layer of risk to govern.
L0 Explain simply
An everyday analogy: instead of checking visitors against four separate stacks of posters, the gatekeeper works from a single binder into which someone has merged all the stacks — plus a few in-house posters the building has added from its own experience. The binder is far more convenient, but it introduces new questions. Was every poster copied in correctly? When the same person appears in two stacks, were the copies merged well — or were two different people accidentally merged into one? And when a source stack changes, how quickly does the binder catch up? The binder is the watchlist, and its quality is now part of the gate's quality.
L1 Core concepts
A watchlist is the combined dataset a screening system actually runs against. It typically merges: the official sanctions lists the institution must obey; additional lists chosen for risk reasons; and internal lists — parties the institution itself has decided to flag or exit. Many banks buy the aggregation from commercial data vendors, who collect issuer files, normalise them into one schema, deduplicate overlapping records, and enrich entries with extra identifiers. Aggregation adds real value — one format, one feed, cross-references between issuers — but it inserts a processing layer between the legal source and the screening engine, and every layer can introduce delay, mapping errors, or merge mistakes. Provenance — knowing which official entry a watchlist record came from — is what keeps the layer honest.
L2 Practitioner view
Practitioners govern the aggregation layer like any critical supplier. Latency is measured per source list: the vendor's processing time adds to the issuer-to-live gap, and contractual update commitments are checked against observed reality. Coverage is reconciled: periodic comparisons between the watchlist and the official lists it claims to contain, catching dropped or mangled records. Merge quality is sampled, since over-merging can hide an alias under the wrong identity and under-merging inflates alert volume. Internal lists need their own governance — criteria for adding a name, an owner, and a review cycle — because an unmanaged internal list grows forever and nobody remembers why half its entries exist. However good the vendor, the regulatory obligation stays with the institution.
L3 Technical details
A well-built watchlist record preserves: the issuing authority and source list; the issuer's unique identifier for the entry; the list version or publication date it was taken from; and a change history. That provenance enables the operations that matter — answering "which official entry caused this alert", honouring delistings precisely, and reconstructing what the watchlist contained on a past date, which investigations and regulators ask for. Cross-issuer linking, where a vendor asserts that a UN entry and an OFAC entry describe the same person, deserves particular care: the assertion is helpful context for investigators, but obligations attach per regime, so the record must keep the underlying entries distinguishable rather than collapsing them into one anonymous merged identity.
Sources & standards1
- Market practice
Wolfsberg Group Sanctions Screening Guidance ↗ — The Wolfsberg Group · Reference data quality and list management
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 · 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 binder analogy treats aggregation as a single step; commercial watchlist products differ substantially in structure, enrichment, and delivery, and vendor names are deliberately omitted. Internal-list governance practices vary between institutions.
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.