How Does a Sanctions Screening Vendor Report a Check It Could Not Complete?

An honest sanctions screening system reports an incomplete or unverifiable check as pending, flagged for human review, never as a clean pass. Under OFAC's Framework for Compliance Commitments and FATF Recommendation 10 on customer due diligence, the obligation to verify sits with the covered party, not the software. A tool that folds an unreachable data source or an unresolved name into a green "clear" result is not reducing your risk. It is manufacturing false confidence and quietly transferring liability onto your desk.

That single reporting behavior, how the system handles what it could not check, is the most diagnostic question a compliance officer can ask in procurement. It matters more than list count, more than match-rate claims, more than any dashboard.

The failure mode that survives every demo

Most screening demos are built to show you the same thing: a name goes in, a match comes out, a case gets adjudicated. That is the happy path. It is also the least informative part of the evaluation, because every vendor's happy path looks competent.

The dangerous failure mode is not a missed match. A missed match is at least visible in principle. It is discoverable in testing, in QA sampling, in a regulator's look-back. The dangerous failure mode is the silent one: a check that could not be completed, rendered as if it had been completed cleanly.

Consider what has to be true for a screen to legitimately return "clear." The relevant lists were reachable. The query executed. The name resolved with enough confidence to distinguish it from near-neighbors. The list data was current. If any one of those conditions failed and the system still returned green, you have a record that looks like diligence but is not diligence. It is worse than an empty file, because an empty file prompts a human to act. A false "clear" tells the human to move on.

This is where the regulatory reality bites. OFAC's sanctions compliance program expectations treat screening as evidentiary, part of a documented control environment that a covered party must be able to reconstruct and defend. The EU consolidated list, the UK OFSI consolidated list, and the UN Security Council consolidated list operate on the same premise: the screen is a record of what you checked and what you found. A record that cannot distinguish "we checked and found nothing" from "we could not check" is not a defensible control. It is a liability you paid for.

The test: ask the vendor to break itself

Here is the repeatable buyer test. In any demo, ask the vendor to walk you through three specific scenarios, live, on their own system:

1. A data source was unreachable. A list endpoint times out, an upstream feed is down, or a sanctioned-entity database returns an error. What does the case record show?
2. A name was ambiguous. The subject shares a name with an SDN-listed individual but the identifying data (date of birth, passport, address) is insufficient to confirm or rule out a match. What does the system do with the unresolved candidate?
3. A list could not be queried at all. One of your required consolidated lists was not covered, not licensed, or not loaded for that transaction. Is the absence visible?

Watch the output, not the narration. An honest system produces a distinct pending or needs review state in each case and routes it to a human. A dishonest or naive system swallows the failure and shows you a pass.

The underlying principle is simple and it is the whole article: a screening system must distinguish not sanctioned from not verifiable. Those are different findings. Conflating them is the original sin of screening. "Not sanctioned" is an assertion supported by a completed check. "Not verifiable" is an open question that a human must close. A vendor that cannot show you both states, cleanly separated in the record, cannot support your compliance program.

OilFlow Intelligence is built around exactly this distinction. Where a step cannot be completed, whether a source is unreachable, a name is ambiguous, or a list cannot be queried, the result surfaces as pending and is flagged for human review. It is never folded into a clear result. That is the posture you should require of any vendor, ours included: prove the pending state exists, then test it.

Why this matters most when lists move fastest

Sanctions lists are not static reference data. They change, sometimes daily, and they change fastest during geopolitical stress. Iran and Hormuz headline volatility, with Brent around $72.44 and WTI around $69.03 as of writing, is precisely the environment in which designations, vessel additions, and dark-fleet identifiers move quickly. When list data is stale and a system reports "clear" against yesterday's list without flagging the staleness, the silent false negative is not a theoretical edge case. It is the most likely way a newly designated counterparty clears your screen.

This is where the layer-cake mechanics of sanctions evasion meet screening design. Evaders rely on the gap between a designation and its propagation through screening infrastructure. A system that reports pending on stale or unqueryable data closes that gap by forcing a look. A system that reports clear leaves it wide open.

List coverage is the second question, not the first

Once you have confirmed the pending posture, coverage becomes a meaningful secondary check. Ask which consolidated lists are queried and confirm they include, at minimum:

• OFAC SDN and OFAC's other sanctions lists
• The EU consolidated list
• The UK OFSI consolidated list
• The UN Security Council consolidated list
• Relevant sectoral and sanctions-adjacent sources for your exposure

Then ask the harder coverage question: how is staleness handled? When was each list last refreshed for the transaction in front of you? If a refresh failed, does the case reflect that as a pending or degraded state, or does it silently screen against old data and report clear? Coverage without freshness handling is a list count, not a control. The order matters: pending posture first, coverage second. A vendor that queries every list in the world and reports unverifiable checks as clear is more dangerous than a vendor that queries fewer lists honestly.

The documentation you must be able to demand

A screening record has to preserve three distinct states, and you should be able to pull each one from the audit trail on demand:

• Clear: the check completed, against current data, and found nothing.
• Hit: the check completed and surfaced a match requiring adjudication.
• Pending: the check could not be completed, for a stated reason, and is awaiting human review.

If the audit trail collapses pending into clear, you cannot reconstruct what was actually verified, and neither can a regulator or an examiner conducting a look-back. The mandate chain behind a transaction, the LOI, ICPO, and the DLC MT700 that move a physical oil deal, generates counterparties at every hop. Each hop is a screening event. Each event must leave a record that says, unambiguously, whether it was checked, matched, or left open. That is the evidentiary standard OFAC's program expectations and FATF Recommendation 10 are built around, and it is the standard your documentation must meet.

What compliance teams should do

• Run the three-scenario test in every demo. Unreachable source, ambiguous name, unqueryable list. Watch for a pending state, not a pass. Do this before discussing price or list count.
• Require the vendor to prove the pending state exists on their live system, not describe it on a slide.
• Confirm staleness handling. Ask when each consolidated list was last refreshed and what happens when a refresh fails.
• Verify the audit trail preserves clear, hit, and pending as distinct states, and that your MLRO can reconstruct any single screening event.
• Treat any vendor that cannot separate "not sanctioned" from "not verifiable" as a liability, regardless of coverage breadth.

The right question in procurement is not how many lists you cover. It is how you report a check you could not complete. If the answer is anything other than pending, flagged for human review, the tool is shifting risk onto you while looking like it is removing it.

To see how a pending-first screening posture works against live sanctions data, book a demo with OilFlow Intelligence or subscribe to the fraud-intelligence briefing for ongoing typology coverage.