How Should a Screening Tool Report a Check It Could Not Complete?

An honest screening tool reports an unverifiable step as pending and forces a human decision. It never collapses "I could not check this" into "clean." This distinction maps directly to FATF Recommendation 10, which requires customer due diligence to be completed before a relationship proceeds, not merely attempted. A tool that returns a green result on a check it never finished is not screening. It is manufacturing false negatives that survive audit until the OFAC SDN hit you missed surfaces somewhere downstream.

Most procurement processes never ask this question. Buyers test screening vendors on the hits they catch. They watch a demo where the system flags a designated vessel, a sanctioned trading house, a name on the EU consolidated list, and they conclude the tool works. The catch rate is the wrong test. The integrity of a screen is measured by how it behaves when it cannot reach a list, cannot resolve an entity, or cannot parse a counterparty document. That behavior is the single most revealing indicator of a vendor's false-negative posture, and it is the question to put in front of every vendor before you sign.

Why "Clean" and "Could Not Verify" Are Not the Same Result

A screening run is a sequence of discrete checks. Each name, vessel, address, and beneficial owner is tested against a set of lists: the OFAC SDN List, the EU consolidated list, the UK OFSI list, UN Security Council designations, and the sectoral and vessel-level lists that matter in crude trade. In an ideal run, every check completes and returns a clear result.

Real runs are messier. A list endpoint times out. A name arrives in a transliteration the matcher cannot resolve. A beneficial owner is buried two layers up a mandate chain and never gets passed to the screening engine at all. Each of these is an incomplete check. The honest output is "pending" or "unable to verify," with a flag for human review.

The failure mode is silent collapse. A weak tool treats the absence of a hit as the presence of clearance. No match found becomes clean, regardless of whether the underlying list was ever queried. That logic is structurally identical to declaring a counterparty unsanctioned because your internet connection dropped. The result reads green. The check never happened.

This is the mechanism by which false negatives enter a compliance file. They do not arrive as wrong answers. They arrive as confident answers to questions that were never actually asked.

Where the Gap Hides in a Crude Trade

The risk is not theoretical, and it concentrates exactly where margins are thin and counterparty chains are long. With Brent around $73.70 and a narrow Brent-Dubai EFS near $2.00, Atlantic-into-Asia arbitrage stays tight but workable. Marginal barrels move, and they move through layered intermediaries: the named seller, the mandate behind the seller, the vessel operator, the technical manager, the beneficial owner registered in a third jurisdiction.

Every layer is a screening surface. Every surface is a place a check can quietly fail. A dark fleet vessel may screen clean on its current IMO-linked name while its prior identity sits on a sanctions list the tool could not reconcile. A trading entity may pass while the beneficial owner one tier up the mandate chain is a designation the engine never received as an input.

This is the layer cake problem in operational form. Each tier looks acceptable in isolation. The risk lives in the seams between checks, and the seams are precisely where an incomplete-but-reported-clean result does the most damage. A tool that surfaces "pending" on the layer it could not resolve hands you a decision. A tool that reports the same layer as clean removes the decision and the evidence that one was ever needed.

The One Test to Run in Every Demo

Here is the test. In the next vendor demo, ask:

"Show me a check the system could not complete. How does it appear in the output?"

Then watch carefully. The honest tool will show you a distinct state. Pending. Unverified. Manual review required. It will be visually and logically separate from a cleared result, and it will carry a reason: list unreachable, entity unresolved, document unparsed. It will not let the run close as fully cleared while that state is open.

The weak tool will struggle to produce the scenario at all, because its data model has no separate state for incomplete. Or it will show you that the unverifiable check rolls into the overall green result. If "I could not check this" renders as anything that looks like clearance, you have your answer. Walk.

This is not a trick question. It is a request to see the failure path, and any vendor confident in its false-negative posture will welcome it. Vendors who only ever demonstrate the happy path, the clean catch on a known designation, are showing you the easy half of the problem.

List Coverage Is a Procurement Requirement, Not a Feature

The pending-versus-clean question assumes the tool is reaching the right lists in the first place. Confirm coverage explicitly and in writing. At minimum, a screening tool serving crude counterparty risk should query the OFAC SDN List, the EU consolidated list, the UK OFSI list, and UN Security Council designations, with sectoral and vessel-level lists relevant to oil trade.

Then ask the operational questions that turn coverage into integrity:

• How often is each list refreshed, and what happens to a screening result issued against a stale list?
• When a list source is unreachable at run time, does the tool report that check as pending, or does it proceed and report clean?
• Are vessel prior-name and IMO history reconciled, or only the current registered name?
• Is the beneficial owner up the mandate chain screened as an input, or only the named counterparty?

Coverage on a slide is a claim. Coverage that degrades gracefully, reporting honestly when a source fails, is a design principle. The difference is what separates a screen you can defend in an audit from one that passes until it does not.

What an Honest Reporting Model Looks Like

The design principle is straightforward. Every check resolves to one of three states, never two. Clear means the check completed and returned no match. Hit means the check completed and returned a match for review. Pending means the check did not complete, for a stated reason, and requires a human decision before the run can be treated as closed.

This is the posture OilFlow is built around: unverifiable steps surface as pending, with the reason attached, so the human in the loop sees exactly what the machine could and could not confirm. The point is not that the tool is always certain. No screen is. The point is that the tool is never falsely certain. Honest uncertainty preserves the decision for the MLRO and the analyst. False certainty removes it and leaves no trace that it existed.

What Compliance Teams Should Do

• Run the failure-path test in every demo. Ask the vendor to show you a check the system could not complete, and look at how it renders in the output. If unverifiable reads as clean, end the evaluation.
• Require three states, not two. Confirm the data model distinguishes clear, hit, and pending. A tool with only pass and fail has nowhere to put an incomplete check except into pass.
• Get list coverage in writing. OFAC SDN, EU consolidated, UK OFSI, UN Security Council, plus relevant sectoral and vessel-level lists. Then ask what happens when a source is unreachable at run time.
• Screen the mandate chain, not just the named party. Confirm beneficial owners and vessel prior identities are passed to the engine as inputs, since that is where the layer cake hides.
• Tie the answer to FATF Recommendation 10. Due diligence must be completed before a relationship proceeds. A tool that closes a run with open, unverified checks is not meeting that standard, whatever the green result says.

The catch rate tells you how a vendor performs on the questions it can answer. The pending-versus-clean test tells you what it does with the questions it cannot. Only one of those predicts the false negative that lands on your desk.

To see how pending-versus-clean reporting works on a live counterparty chain, request a demo or subscribe to the OilFlow Intelligence newsletter for the next typology breakdown.