What Should a Screening Vendor Do When It Cannot Complete a Check?

What should a screening vendor do when it cannot complete a check?

An honest screening system reports a check it could not complete as pending or unverifiable, never as clean, and it logs the reason. Under FATF Recommendation 10, customer due diligence that cannot be completed is a trigger to pause the relationship, not to proceed. Any vendor that silently converts an incomplete check against the OFAC SDN List, the EU consolidated list, or UK OFSI into a green checkmark is not covering your risk. It is manufacturing the appearance of coverage it never delivered.

That single design decision, how a tool reports what it could not verify, is the most reliable integrity test a compliance officer can run inside a vendor demo. This article gives you the exact question to ask and explains why the answer separates real risk coverage from a false-negative machine.

Why 'clean' and 'could not screen' are two different states

Every screening result belongs to one of three states, and the distinction matters more than the vendor UX usually admits.

1. Screened and cleared. The system ran the check against a named list, matched nothing, and can show you the list, the version, and the timestamp.
2. Screened and flagged. The system found a potential match and surfaced it for adjudication.
3. Could not screen. The system attempted a check but could not complete it. The counterparty data was incomplete, a list feed was stale, an identifier failed to resolve, or an upstream source timed out.

The failure mode that costs compliance teams is when state three quietly collapses into state one. A record shows green. The officer sees a cleared counterparty. What actually happened is that the tool could not verify the beneficial owner, could not resolve the vessel identity, or could not confirm the current SDN version, and reported success anyway.

This is the definition of a false negative in a screening context. It is not that the tool missed a match that was there to find. It is that the tool told you it looked when it did not finish looking.

The one question that exposes false-negative posture

In the demo, ask this, and ask it plainly:

"When your system cannot verify a step, what status does the record show?"

The correct answer is some version of: pending or flagged, with the reason logged. The record should tell you which check failed and why, so a human can decide whether to complete the check manually, request more data, or hold the onboarding.

The wrong answers are subtler than an outright "it shows clean." Watch for:

• "It defaults to pass if there is no adverse hit." This treats absence of a completed check as absence of risk. Those are not the same thing.
• "It shows clean but you can drill into the log." If the headline status is green, your first-line analyst working a queue under time pressure will act on green.
• "That basically never happens." It happens constantly. Feeds go stale, identifiers are ambiguous, and mandate chains arrive with missing parties. A vendor that claims incomplete checks are rare either has thin coverage or is not measuring the gap.

OilFlow's design principle on this point is deliberate and worth stating as the benchmark: a check that cannot be completed is surfaced as pending, never absorbed into a clean result. You do not need to buy our product to apply the principle. You need to hold every vendor you evaluate to it.

Ask for list coverage in writing, because it is auditable

Sanctions and regulatory lists are public fact, which makes them the easiest part of any vendor claim to verify. Request the named lists and the refresh cadence in writing. At minimum, coverage should include:

• OFAC SDN List (US Treasury Office of Foreign Assets Control specially designated nationals)
• EU consolidated sanctions list
• UK OFSI consolidated list
• UN Security Council consolidated list

Then ask the follow-up that most vendors dislike: how often is each feed refreshed, and what status does a record show if a feed is stale at the moment of screening? A tool that screens against yesterday's SDN version and reports clean is running a check it cannot honestly complete. In oil and gas, where a counterparty can be designated between the LOI and the DLC MT700, refresh cadence is not a technical footnote. It is the difference between a live screen and a screenshot of a screen.

Get the list names and cadence in the contract or the statement of work, not the sales deck.

Why this matters more when cargo flows move fast

Screening gaps do not stay theoretical. They compound under commercial pressure. With Brent around $72.13 and the Brent-Dubai EFS near $2.00 per barrel keeping arbitrage windows tight, cargoes get re-routed and counterparties get swapped in on short notice. A trading desk under a closing arb window will onboard a new intermediary in hours, not weeks.

That is exactly the moment a false-negative screen does the most damage. The mandate chain changes, a new party enters between the original seller and the end buyer, and the tool cannot resolve the new entity's beneficial ownership in time. If it reports pending, the MLRO has a decision to make and a paper trail to make it on. If it reports clean, the deal proceeds and the gap is invisible until a regulator finds it.

Dark fleet activity, layered EN590 gasoil transactions, and shell intermediaries inserted into the layer cake all exploit the same weakness: the assumption that a green result means a completed check. Fast markets widen that gap. Honest reporting of incomplete checks is what keeps it visible.

How this maps to FATF Recommendation 10

The pending-not-clean principle is not a vendor preference. It reflects the logic of FATF Recommendation 10, which frames customer due diligence as a set of steps that must be completed, and directs firms not to establish or continue a relationship where CDD cannot be performed. The regulatory expectation is that an inability to verify is itself a risk signal that requires action.

A screening tool that reports incomplete checks as clean inverts that logic. It tells the firm that CDD succeeded when the underlying steps did not complete, removing the very signal that Rec 10 requires the firm to act on. When an examiner reconstructs a file after the fact, the question is rarely "did the tool have the right lists." It is "did the firm act on what it could not verify." A system that never recorded the gap leaves the firm with no defensible answer.

What compliance teams should do

• Run the one question in every demo. Ask what status a record shows when a check cannot be verified. Correct answer: pending or flagged, with the reason logged. Treat any default-to-pass behavior as disqualifying.
• Get list coverage in writing. Name OFAC SDN, EU consolidated, UK OFSI, and UN lists explicitly, and require the refresh cadence in the contract, not the pitch.
• Confirm three distinct states. Screened-and-cleared, screened-and-flagged, and could-not-screen must be separate statuses in the record. If two of them collapse into one green result, you are buying a false-negative machine.
• Test the stale-feed case. Ask what the system reports if a sanctions feed has not refreshed. The honest answer surfaces the staleness rather than screening against an old version silently.
• Tie it to your Rec 10 procedure. Make sure your policy treats a pending screen as a trigger to pause and escalate, so the tool's honest reporting connects to a documented human decision.

The integrity of a screening vendor is not visible in the results it shows you when everything works. It is visible in what it does when it cannot finish the job. Ask that question first.

If you want to see the pending-not-clean principle applied to petroleum counterparty screening, request an OilFlow Intelligence demo or subscribe to the fraud-intelligence briefing for more buyer-side typology guides.