· Yair Knijn
You bought a screening tool and never asked which lists were in the box
A Risk and Compliance Director runs a clean procurement. Three vendors, a scoring matrix weighted on price, integration effort, and how the console feels to click around. The winner demos well. The contract gets signed and nobody asks the question that decides whether the tool works: which lists are in it, how often they refresh, and where the data came from.
The assumption underneath is that a sanctions screening tool screens against sanctions. All of it, kept current, by definition. That assumption is wrong often enough to put a designated party clean through your book.
The questions that should fail a vendor: which lists, how fresh, from where
Three questions, asked before the scoring matrix. Which lists? Named by program, not by region. "Global coverage" is marketing; you want OFAC SDN and the non-SDN lists, the EU Consolidated List, the UN Security Council list, UK OFSI, and whatever national lists your book touches, in writing. How fresh? Not "real-time" as a slogan but a stated polling interval per source. From where? The provenance of each feed, and what happens when a source format changes upstream. A vendor who routes these to a sales engineer who "will follow up" has told you the data is someone else's problem.
OFAC-only coverage as a hidden gap for EU and UN-exposed books
The common failure is a tool built around OFAC SDN, with everything else bolted on or absent. OFAC moves fast: the SDN list updates three to four times a week on no fixed schedule. But if your insureds, their UBOs, or their counterparties sit anywhere near EU or UN exposure, OFAC alone leaves a hole. A party designated by the EU Council but not yet by OFAC will screen clean on an OFAC-only feed, and your case file will say so.
Refresh cadence is the second trap. The EU Consolidated List changes after a Council Decision, and there is a window before the downloadable file catches up to the Official Journal. OpenSanctions has documented a lag past twenty days: the sanction was legally in force while the consolidated file every vendor pulls from still showed the old data. Poll EU sources weekly, and the gap between "designated" and "in your engine" is measured in days you are liable for.
Why a normalized, multi-source feed matters
Running fifty ingestion pipelines, each parsing a different government's file format and absorbing every upstream schema change, is expensive and breaks quietly. This is why modern platforms build on a normalized layer. OpenSanctions, for instance, pulls 200-plus feeds into one consistent schema, so a name, an alias, and a designation reference look the same whether they came from Washington, Brussels, or New York.
So ask whether a vendor normalizes across sources or stitches a few feeds by hand. Normalizing is what matches a UBO across an EU spelling and a UN transliteration of the same name. Ad hoc stitching produces a no match because the alias only lived in the one list the vendor never wired up.
Writing list coverage, refresh SLA, and provenance into the contract
Provenance belongs in the contract, not in a footnote you find during an audit. Put the specifics in the schedule and make them enforceable.
- The named lists in scope, by program, with new ones added by amendment, not silent vendor discretion.
- A per-source refresh SLA, stated as a maximum lag from official publication to availability in your engine.
- The provenance for each feed, and the right to audit coverage so a missed designation is the vendor's documented failure, not your gap.
InsureGuardAI screens against a normalized, multi-source feed, surfaces the refresh state of every list in your workspace, and keeps the raw match response for each cleared name as evidence. When the regulator asks which lists were in the box and how current they were, the answer is already in the file. See how it works.