· Yair Knijn
Screened at bind, never again: the re-screening gap that turns a clean policy into a blocked one
An MLRO signs off a five-year liability policy in March 2023. The named insured is clean, the UBO is clean, the fuzzy matches are all resolved. The case file is closed, the policy binds, and that screen is quietly treated as a permanent stamp. It is not. Eighteen months later OFAC designates the policyholder's parent company, and the next premium installment that lands in the bank account is now a blocked transaction. Nobody ran the check again, because as far as the file was concerned, this party was already cleared.
This is the most common way insurance sanctions exposure actually happens, and it is not exotic. The list moved. The contract did not.
Why a clean check at inception is a snapshot, not a clearance
An inception screen tells you one thing: this party was not on the list on the day you checked. It says nothing about the day after. The SDN List, the SSI List, and the consolidated non-SDN lists change constantly, and designations are not announced to you, they are published and you are expected to have caught them. A multi-year policy is a live obligation sitting on top of a status that can flip overnight without anyone in your shop touching the file. Treating "cleared at bind" as "cleared for the term" is treating a photograph as a live feed.
OFAC's 2024 insurer FAQs: screen at renewal, amendment, claim, and on every list update
On 13 November 2024 OFAC updated its insurance-industry FAQs for the first time since January 2015, and the shift in tone is the whole story. The old line was that screening frequency was "up to your firm and your regulator." That hedge is gone. OFAC now says insurers should screen at policy renewal, at policy amendment (including adding an insured party or a beneficiary), at claim submission, at claim payment, and whenever OFAC updates its sanctions lists, plus any other point where the insurer is exposed to sanctions risk.
Read that last trigger carefully. Every list update is a screening event. Not every renewal, not every quarter, every time the list itself changes. That is no longer a periodic batch job you run when convenient; it is a delta you have to chase the moment OFAC publishes.
When a premium becomes a blocked transaction overnight
Here is where the inception-only habit turns into a reportable failure. If a policyholder or beneficiary becomes the subject of the SDN List, or sits in a sanctioned jurisdiction, OFAC's guidance is unambiguous about what you must do next:
- Block the policy.
- Report the blocking to OFAC within
10 business days. - Place any unearned premium, and any premium received after the blocking date, into a blocked account rather than refunding or processing it.
If you only screened at bind, you do not know the block is required, so you keep collecting and applying premium against a designated party. Every installment after the designation date is a violation you are actively creating, and "we screened them at onboarding" does not cover it. The clock on those 10 days starts when you should have known, not when you happen to notice.
Building event-driven and list-delta-driven re-screening into the policy lifecycle
The fix is to make screening fire off the lifecycle and off the list, not off the calendar. Wire a re-screen to each event OFAC named: renewal, amendment, beneficiary change, claim submission, claim payment. Separately, subscribe to list changes so that when OFAC publishes a designation, you rescreen the affected book of in-force policies against the delta the same day, not at the next review cycle. Both paths have to write to the same case file, with the raw match response kept as evidence, so when an examiner asks why a live policy was or was not blocked, the answer is already on record.
InsureGuardAI is built for exactly this shape of problem. Each customer workspace runs continuous re-screening against the in-force book, triggered by both policy-lifecycle events and OFAC list updates, follows ownership through the corporate layers to the actual beneficial owner, and records why every fuzzy match was cleared so the case file answers the regulator's question before they finish asking it. If you want to see what continuous, event-driven screening looks like on a real book of policies, start here.