How to Evaluate Business Verification Vendors by Their Limitations

Executive Summary: The most useful vendor document is not the feature list. It is the map of where the data stops and the buyer's policy must begin. Coverage, source availability, identifiers, freshness, completeness, and delivery mode determine how a result can safely enter a lending workflow. An honest limitation is not merely procurement fine print. It should become a production test, routing rule, fallback, owner, and monitoring signal.

Why Do Limitations Change the Net Product Claim?

The FTC says advertising claims must be truthful, non-deceptive, and supported, and that the overall net impression matters.^[1] A broad claim can mislead when a material coverage or interpretation limit is hidden.

For buyers, the lesson is practical: evaluate the exact assertion the result supports, not the headline category.

A limitation is production information. If it cannot be routed and tested, it has not been operationalized.

Which Dimensions Should Every Evaluation Cover?

1. Source authority and retrieval time.

2. Jurisdiction and record-type coverage.

3. Required identity keys.

4. Match ambiguity and alternatives.

5. Sync or async delivery.

6. Freshness and outage handling.

7. Evidence retention and reproducibility.

8. Data completeness and field variance.

9. Screening versus decisioning boundary.

10. Customer-owned policy and fallbacks.

How Do Product Categories Differ?

TIN and EIN validation

The result validates a submitted name and tax-ID pair. It does not discover an EIN, identify owners, or make a credit decision. Source unavailability must remain distinct from match and mismatch.

SOS and multi-state verification

State fields, status meanings, identifiers, and availability vary. Full Verification can organize state results, but it does not make every source uniform.

UCC data

Coverage is limited, filing sources vary, and not every tax or federal lien source is included. A no-result response cannot become no lien without coverage proof.

Court records

Current Cobalt coverage is New York State and Miami-Dade County, delivered asynchronously. A filing is not a finding, and electronic access can be incomplete.

Contractor licenses

Current confirmed coverage is California, Florida, New York through NYC DOB, and Texas. A license number is required, delivery is asynchronous, and disciplinary fields depend on the authority.

OFAC screening

Cobalt screens U.S. Treasury lists. Results are point-in-time candidates, not global sanctions coverage or a decision. The customer owns threshold, review, and re-screen policy.

Cobalt's public documentation provides current request, response, and coverage details that should be checked during implementation.^[2]

What Questions Should Procurement Ask?

• What authoritative sources are used?

• What exact jurisdictions and record types are covered today?

• Which fields vary or may be absent?

• How are no match, unsupported, and unavailable separated?

• Which identifiers produce the strongest search?

• How are alternatives and ambiguous candidates returned?

• What evidence can reproduce a result?

• How are changes and incidents communicated?

• Which fallbacks remain customer-owned?

• Which decisions must the customer make?

Avoid questions that can be answered only with yes. Ask for testable states and artifacts.

How Should a Proof of Concept Be Designed?

Use a limitation-first test pack:

1. Clean exact match.

2. DBA or name variant.

3. Multiple candidates.

4. Unsupported jurisdiction.

5. Source unavailable.

6. Recent filing or changed record.

7. Missing optional field.

8. Duplicate async callback.

9. Result requiring a manual fallback.

10. Evidence reproduction after the initial run.

Record the result, route, artifact, and owner for each case. An HTTP success or polished dashboard does not complete the test.

How Should Limitations Become Workflow Rules?

documented limitation
  -> detection condition
  -> system state
  -> owner and next action
  -> fallback
  -> closure evidence

For example, unsupported UCC coverage routes to an authoritative filing-office search. Court source unavailability routes to a bounded retry or hold. An OFAC candidate routes to compliance review under the customer's threshold policy.

What Should the Contract and Runbook Preserve?

• Current coverage matrix.

• Source and schema change process.

• Incident and escalation route.

• Evidence and retention obligations.

• Security responsibilities.

• Customer-owned fallbacks.

• Decisioning boundary.

• Revalidation schedule.

The buyer should confirm these items against live documentation, not rely only on a sales summary.

What Should Teams Monitor After Launch?

• Unsupported requests by product and jurisdiction.

• Source-unavailable events and age.

• Optional fields missing.

• Ambiguous candidates.

• Manual-fallback volume.

• Results that could not be reproduced.

• Coverage or schema changes.

• Decisions made while evidence was incomplete.

What Is the Practical Vendor Test?

List every material limitation, turn each one into a test and route, assign the retained responsibility, then validate the workflow with clean, ambiguous, unsupported, and unavailable cases.

Cobalt publishes product-specific boundaries and supplies source data. The customer owns its policy, fallbacks, review, legal interpretation, and final decisions.

Ready to run a limitation-first evaluation rather than a feature demo? Schedule a Cobalt Intelligence demo and bring the failure cases your current workflow cannot explain.