Executive Summary: A no-match result describes the search that was submitted, including its name, entity type, selected sources and matching threshold. Cobalt's screening request exposes those controls.[1] Preserve the effective query scope with the response so the reviewer can determine whether the intended screen was actually performed.
What does a zero-match response establish?
It establishes that the returned result contains no matches for that submitted screen. It does not independently prove that every relevant name, party, list or sanctions question was evaluated.
Cobalt's documented response includes the screened name, matchCount and matched entries.[2] Keep those response facts linked to the request parameters. A count without its scope is difficult for a later reviewer to interpret.
Which question should the reviewer ask first?
Ask whether the actual query matches the screen the policy required. Was the intended business name submitted? Was the correct entity type selected? Were the required sources included? Was the configured threshold the one the authorized policy specified?
These are evidence checks, not a recommendation to loosen or tighten a threshold until a preferred result appears. If the configuration is wrong, preserve the original result and run a corrected screen through the approved process.
Does no match mean sanctions clearance?
Do not give the result that broader label by default. OFAC's guidance on entities owned by blocked persons explains that ownership can create blocking consequences beyond the immediate name-matching question.[3]
The screening result is an input to the organization's sanctions process. This article addresses query traceability, not a complete determination that a transaction is legally permitted.
Which request fields define the screen?
Cobalt's current request table includes searchQuery, searchType, sources and score, with optional location information.[4] Record what the application actually sent and distinguish explicit values from omitted parameters that relied on defaults.
The documented entity types include organization, person, vessel and aircraft; leaving the type unspecified searches across the listed types.[5] A business screen should use the type selection required by the policy rather than an accidental value inherited from another form.
How should source selection be recorded?
Preserve the submitted source identifiers and the policy version that selected them. The current documentation lists multiple sanctions and watchlist sources and says a blank selection uses all available sources.[6]
“All available” should not be stored as if it were a permanently fixed or universally complete list. Confirm the effective scope relevant to the integration and retain the applicable documentation or provider clarification. Do not claim a global coverage guarantee merely because several source names appear in the reference.
What about location fields?
Retain them with the submitted screen when used. If an incorrect location value narrowed or otherwise affected the intended query, the original result should remain tied to that value. A later correction is another screen, not a reason to edit the earlier request history.
Confirm actual field behavior in the current provider contract before implementing matching assumptions. A familiar parameter name does not establish how a particular screening service uses it.
How should the team interpret the matching threshold?
Cobalt's request documentation describes a fuzzy-matching score parameter, its supported range and default.[7] That is a vendor configuration detail, not a government endorsement of a particular threshold or a probability that the screened party is safe.
OFAC states that users of its own Sanctions List Search must determine their thresholds based on their risk assessments and compliance practices; it does not recommend one universal score.[8] Keep that government guidance separate from a vendor's default.
Should a reviewer change the score after no matches?
Follow the organization's approved screening policy. If a configuration error is found, record it and perform the corrected screen. Do not experiment with thresholds on a live application simply to produce a desired outcome.
When evaluating a threshold policy, use a controlled test set and document expected behavior. That is a separate policy and implementation exercise, not an analyst's improvised response to one borrower file.
Can scores be compared across tools?
Do not assume the same number has identical meaning across providers. OFAC describes its own search score in terms of name similarity and its tool's matching logic.[9] A vendor may use different fields or algorithms.
Record the provider and configuration that produced the result. A score should not be detached from that context and presented as a universal risk rating.
What should the evidence record contain?
Create a record that lets another reviewer reconstruct the intended and actual screen without exposing sensitive details unnecessarily. Keep the raw request and response in their authorized store and provide a readable summary of the relevant scope.
A practical checklist includes:
• API configuration. The documented request uses searchQuery, searchType, sources and score; preserve their submitted values.[10]
• Subject reference. Identify the business or person being screened and the relevant application revision.
• Submitted name. Preserve the actual query, including any separately screened names required by policy.
• Entity type. Record the selected type or the documented default behavior used.
• Source selection. Retain explicit source identifiers and any confirmed effective default scope.
• Threshold and filters. Record the actual matching configuration and location fields used.
• Result and disposition. Preserve the response, observation time, policy version and reviewer action separately.
What does a review-ready record look like?
The following is illustrative customer-side evidence metadata, not a Cobalt payload or a recommended screening configuration.
{
"screen_reference": "synthetic-screen-01",
"application_revision": "synthetic-revision-03",
"request_snapshot_reference": "restricted-request-record",
"effective_scope_confirmed": true,
"policy_version": "approved-screening-policy-version",
"returned_match_count": 0,
"review_state": "evaluate_no_match_within_recorded_scope"
}The final state intentionally does not say “sanctions cleared.” It tells the reviewer what evidence is available and which policy context must govern the next action.
What if the effective scope cannot be reconstructed?
Record the gap and identify the specific missing configuration evidence. If the original request is unavailable, do not infer its parameters from today's application defaults. A new screen may be required, but it should remain a new observation with its own time and configuration.
How should an analyst resolve an incorrectly scoped search?
Preserve the original screen and describe the error. Identify the corrected subject or parameters, the authority for the correction and the new request. Link both observations to the application so the review history explains why the second screen was needed.
For example, a hypothetical business application could have been screened with the wrong entity type inherited from a person-screening workflow. The correct response is to repair the mapping, run the intended screen and retain the earlier result as evidence of the erroneous query. This is an illustrative scenario, not an observed Cobalt incident.
What should the analyst avoid saying?
Avoid “the provider missed the business” when the request did not reflect the intended scope. Equally, avoid blaming the query without evidence of a configuration problem. Inspect what was actually submitted and returned.
Cobalt's documented response identifies the screened name and match count.[11] Use that information with the retained request to establish the facts before assigning a cause.
What if the corrected query returns a potential match?
Move to the appropriate match-review process. OFAC's match guidance directs users to identify the list involved, compare the party type and evaluate the available identifying information.[12]
Do not collapse a potential match into a confirmed prohibited party. Preserve the source entry, supporting details and responsible reviewer's determination under the applicable process.
How should this fit the lender's broader evidence workflow?
A no-match screen is one evidence item. Keep it linked to the correct subject and application, while retaining separate requirements for identity, authority, ownership or transaction review where applicable.
The OFAC screening audit guide provides broader recordkeeping context. This article's narrower purpose is to make the query scope behind a zero-match result reconstructable.
What does ownership add to the question?
OFAC's 50 Percent Rule addresses entities directly or indirectly owned in the aggregate at the relevant threshold by blocked persons.[13] A name-only result should not be used as a substitute for any ownership-related inquiry the organization's process requires.
This does not claim that Cobalt automatically resolves ownership structures or provides a complete sanctions determination. Confirm any separate capability and its limits before including it in the workflow.
What if the same business appears for two customers?
Keep each customer's private application, submitted scope and disposition separately authorized. A shared business name does not establish that one customer's screening record can be disclosed to another.
Our multi-tenant screening guide discusses that platform context. Scope traceability still matters within each authorized record, even when the underlying public subject is the same.
A no-match result becomes useful evidence when the reviewer can see exactly which screen produced it.
Which tests should catch scope mistakes before deployment?
Build a controlled set of synthetic inputs and expected request configurations. Test an organization screen, an unintended person type, an omitted source selection, an explicit source list, a missing threshold value and a changed location field.
Use fixture responses to confirm that the application preserves request scope even when the returned match count is zero. These tests should not require live screening of real borrowers merely to verify your own serialization and recordkeeping.
What should the acceptance tests assert?
Assert the exact outbound parameters, their policy source, the retained response and the analyst-facing summary. A test should fail if the application cannot distinguish an explicit setting from a default, or if it labels zero matches as universal clearance.
Test configuration changes across time. A historical screen should retain the settings that produced it even after the application adopts a different approved policy. Do not regenerate old evidence summaries using today's defaults.
How should the team validate vendor-specific behavior?
Use the current request contract and a provider-supported test approach. Cobalt's public parameter table uses score; confirm actual integration details directly if another example uses different terminology.[14] Do not introduce an undocumented parameter based on a copied sample comment.
Keep test findings tied to the provider and version or documentation date. A result from one tool should not be treated as proof that another tool interprets names, sources and thresholds identically.
What should you establish in a Cobalt evaluation?
Bring the scope your screening policy requires and a permitted test plan. Ask to inspect the actual request, documented source options, response fields and handling of omitted parameters. Confirm what evidence can be retained to explain a no-match result later.
OFAC's own search guidance explains that its tool searches named sanctions lists and that its search behavior and scores have defined meanings.[15] Use the same discipline with a commercial API: identify the scope rather than treating the product label as the entire answer.
Schedule a Cobalt demo with that test plan. The practical outcome is a screen whose subject, configuration and result are traceable, with the broader sanctions decision left to the organization's authorized process.
.jpg){kind=small}
.png)