How do you test a sanctions screening vendor for false negatives? Ask how it reports checks it could not complete

Ask the vendor to show you a screen where a check failed, and watch what the report says. Honest tooling labels an unreachable corporate registry, an unresolved beneficial-owner chain, or a name with three competing transliterations as pending or unverified, and names the specific check that did not complete. Dishonest tooling collapses "did not find a match" into "there is no match" and returns a green result, which is a manufactured false negative: the audit trail now records a positive assurance against OFAC SDN, the EU consolidated list, UK OFSI, or the UN Security Council consolidated list that the vendor never actually obtained. That gap does not stay with the vendor. It transfers to the MLRO who signs the file.

Why this question matters more in the current flow environment

Counterparty and vessel histories are being rewritten faster than static list refreshes can absorb them. Intermittent disruption around the Strait of Hormuz has pushed cargoes onto substitute routes, and a Brent-Dubai EFS around $2.00/bbl has kept arbitrage economics in motion rather than settled, which means ownership structures, charterers, and managers behind a given hull change hands inside the window between one screening run and the next. For dating only, the August 7, 2026 marks were Brent $83.55, WTI $78.18, Dubai $81.55. The point is not the price. The point is that when flows redirect this often, the interval between a list snapshot and the transaction in front of you is exactly where dark fleet re-registrations and freshly interposed intermediaries live. A screening tool that cannot tell you which of its checks are stale or incomplete is not giving you a control. It is giving you a timestamp on somebody else's optimism.

Every screen has steps it cannot complete. The only variable is disclosure

This is not a criticism of screening technology. It is a structural fact.

A corporate registry in a jurisdiction with no machine-readable filings will time out. A beneficial-owner chain running through nominee shareholders in an opaque jurisdiction will terminate before you reach a natural person. A trading name rendered from Arabic, Farsi, or Cyrillic will produce multiple defensible Latin spellings, and a fuzzy match at one threshold is a miss at another. A vessel's registered manager may have changed between the last list publication and the fixture in front of you.

FATF Recommendation 10 requires customer due diligence measures that include identifying the beneficial owner and taking reasonable measures to verify that identity. It does not require certainty. It requires that you know what you verified and what you did not. OFAC's 50 Percent Rule compounds the problem, because aggregated indirect ownership means a counterparty that appears clean on a direct-name check can still be blocked property if two or more designated persons hold interests that sum to fifty percent or more across a layer cake of holding companies. A tool that cannot complete the ownership walk has not cleared the 50 Percent Rule. It has declined to test it. Those are different outcomes, and only one of them is honest to report as a pass.

The collapse from "did not find" to "not there"

The defect is semantic before it is technical. A query returns zero rows. Zero rows means one of two things: the entity is absent from the list, or the query never reached the list in a usable state. Both produce the same empty result set. The difference exists only in the metadata, and only if someone chose to preserve it.

When a vendor's report layer discards that metadata, every failed lookup becomes indistinguishable from a genuine negative. The compliance file then contains a clean screen, the mandate chain proceeds, and the transaction documentation stacks up behind it. By the time an LOI is answered with an ICPO and a DLC MT700 is being drafted against a cargo of EN590, the clearance gap is buried under four documents that all reference the same unearned green result. Nobody re-opens it, because nothing in the file suggests it needs re-opening. That is what a manufactured false negative buys you: not a wrong answer you can catch, but a wrong answer that looks exactly like a right one.

Question one: "Show me a screen where a check failed"

Do not ask whether the tool handles failures. Every vendor says yes. Ask to see the artifact.

A good answer produces a report on screen that identifies the failed step by name, states what was attempted, and carries a status that is visibly not "clear." You should be able to read which registry timed out, which ownership branch terminated unresolved, or which name variant could not be disambiguated.

A weak answer describes the failure handling verbally, reroutes to a dashboard of aggregate coverage percentages, or shows you a red alert for a confirmed match while never showing you the middle state. If the demo has only two colours, the tool has only two colours, and the amber cases are being sorted into one of the other two without your knowledge.

Question two: "Which lists did you query, and when was each one refreshed?"

List coverage is usually presented as a logo wall. Push past it. Ask for per-list provenance on a single screen: OFAC SDN, the EU consolidated list, UK OFSI, the UN Security Council consolidated list, and any vessel or PEP-adjacent sources the vendor claims. For each, you want the source, the refresh timestamp, and the query outcome.

The answer you are testing for is whether the tool distinguishes "queried this list successfully at this time" from "this list is in our catalogue." A vendor that can only report at the catalogue level cannot tell you whether a specific screen actually touched OFSI, and neither can you when the regulator asks.

Follow up on transliteration explicitly. Ask what the tool does when a name resolves three ways. The correct answer names the variants and flags the ambiguity. The incorrect answer picks the highest-scoring variant and reports a clear.

Question three: "What does my auditor see two years from now?"

A screening result is not a screening record. Ask what is retained, in what form, and whether the pending states persist in the archived file or are overwritten when a later run completes.

This matters because remediation is normal. A check that was pending on Monday may resolve on Thursday. What you cannot have is a system that retroactively rewrites Monday as clean, because the transaction decision was made on Monday's information. Your file needs to show what you knew when you decided, including what you did not know, and what you did about the gap. That is the difference between a defensible control and a reconstruction.

How pending-state reporting should be structured

OilFlow Intelligence builds screening output around the principle that an incomplete check is a reportable state, not a rounding error. Each check carries its own status rather than contributing to a single composite verdict, so a report can show list queries completed against OFAC SDN and the EU consolidated list while simultaneously showing an ownership walk suspended at an unresolved layer, with the specific branch named. Pending items are enumerated with the reason they are pending, which converts a vague uncertainty into an assignable task for the analyst or the MLRO.

The design intent is narrow and worth stating plainly: the tool should never be the party that decides an unverifiable step is acceptable. That decision belongs to the compliance officer whose signature ends up on the file, and it can only be made if the tool declines to hide the gap.

Red flags in the vendor's answer

• The demo dataset never produces a failed check. Real screening produces them constantly.
• Coverage is discussed only as list counts, never as per-query provenance and refresh times.
• "Pending" exists in the interface but does not appear in the exported or archived report.
• The vendor describes ownership resolution as complete without reference to aggregation under the 50 Percent Rule.
• Asked about false negatives, the vendor answers with a false-positive reduction statistic. These are opposite problems, and conflating them is a tell.

What compliance teams should do

1. Script the three questions into your vendor evaluation. Show me a failed check. Show me per-list query provenance with refresh times. Show me the archived record two years out. Record the answers verbatim in the procurement file.
2. Require pending states to survive export. If unverified steps disappear from the PDF, the CSV, or the case archive, the control exists in the interface only and not in the evidence.
3. Test transliteration and ownership depth with your own difficult names. Use counterparties from your actual book, not the vendor's sample data, and include at least one structure that runs through an opaque jurisdiction.
4. Align the output to FATF Recommendation 10 language. Your policy commits you to reasonable measures to verify beneficial ownership. Your tooling should tell you, per case, whether those measures completed.
5. Define what happens when a check stays pending. Escalation threshold, who signs, what additional evidence is required, and whether the mandate chain pauses. A pending state with no attached procedure is only marginally better than a false clear.
6. Re-screen on flow-driven triggers, not just calendar cycles. Route changes, manager changes, and re-registrations are the events that outrun static lists.

A screening tool's honesty is measured by how it labels what it could not verify. Ask the question in the demo, before the answer becomes your signature.

OilFlow Intelligence is a pre-revenue fraud-intelligence research desk. To see how pending-state reporting is structured in practice, request a walkthrough, or subscribe to the desk's briefings for new typology work as it publishes.