· Yair Knijn
OFAC updated the list on a Thursday. Your batch ran on Monday. Three days of exposure.
The Risk and Compliance Director signs off on a re-screening schedule once and treats it as solved. Every Monday at 02:00 the whole book runs against the latest sanctions files, exceptions queue up, analysts clear them by Wednesday. It looks disciplined. It is auditable. And it rests on an assumption that does not hold: that the list waits for the calendar.
It does not. OFAC publishes changes to the SDN List on any business day, with no predetermined schedule, and in practice that means several times a week. A name added on a Thursday first appears to you on Monday. Between those points the policy is live, premium is collected, claims are paid, and the party is sanctioned. You just have not looked yet.
The mismatch between a weekly batch and a list that moves on its own clock
A fixed cadence has a fixed worst case. A weekly sweep means the gap between a designation landing and you reacting can run up to seven days. A monthly sweep makes that worst case a month. You set the cadence; you do not set the timing of the designation, and the two have nothing to do with each other.
The cost of that gap is not abstract. Once you have a match, OFAC expects blocked property to be reported within 10 business days, and that clock starts when the property is blocked, not when your batch finds it. Days spent waiting for Monday are days already burned off the response window, and "our re-screen runs weekly" is the sentence that turns a timing gap into a documented failure to act.
Delta screening: re-run only the new designations the moment they land
OFAC already ships the mechanism. Its Sanctions List Service publishes a delta file describing exactly what changed in a given update: additions, removals, modifications. You do not have to diff two full snapshots to find the new names. You consume the delta, take the entries that are new or amended, and screen your entire active book against just those entries.
That inverts the expensive part. A full-book sweep screens every party against every entry, which is why it only runs weekly. A delta check screens every party against a handful of new entries, cheap enough to run the instant the file changes. The Thursday designation gets matched Thursday, and the three-day window never opens.
Full-book sweeps versus delta checks, and when each is the right tool
Both belong in the program. They answer different questions:
- Delta check, on every list change: did any party already on my book just become sanctioned? This is the fast path that closes the exposure window.
- Full-book sweep, on a cadence: does my whole portfolio still clear against the complete current list, catching fuzzy-match logic changes, data corrections, and anything a delta consumer missed?
The full sweep is your backstop and your proof that nothing rotted between deltas. The delta check is what keeps you current. Run only the sweep and you have a gap; run only deltas and you have no periodic proof of completeness. Run both, and let the delta carry the time-sensitive load.
Triggering a re-screen on list change, not on the calendar
The fix is a change of trigger. Stop firing the re-screen from cron and start firing it from the event that actually matters: the list updated. Poll the Sanctions List Service, and when the published file changes, pull the delta and screen the book against it automatically. The cadence becomes the list's cadence, which is the only cadence that closes the window.
InsureGuardAI is built around that trigger. Each customer workspace watches the source lists, and when a new designation lands it re-screens your active parties against the change in minutes, records why each fuzzy match was cleared or escalated, and keeps the raw match response as evidence. The gap between a Thursday designation and your response is measured in minutes, not days. See how event-driven screening closes the window that a weekly batch leaves open.