How to Design a Dependency-Aware Pre-Screening Waterfall

Executive Summary: The best pre-screening waterfall does not simply run the fastest or least expensive check first. It runs each check only after its identity and coverage dependencies are satisfied, parallelizes independent work, and never turns missing evidence into a clean result. Cobalt's products use different identifiers, sources, jurisdictions, and delivery modes. A safe order therefore begins with the subject, not the endpoint list.

What Must Be Established Before Screening?

Resolve whether the subject is a person, legal business entity, or relationship between both. For a business, preserve the legal name, DBA, state, entity ID, tax identifier, owners or guarantors, and intended financing recipient as separate fields.

A check cannot be better than the identity and jurisdiction submitted to it.

Which Dependencies Matter?

TIN and EIN validation

Requires a traceable legal business name and supplied tax ID. It validates the pair but does not discover the EIN or approve the customer.^[1]

OFAC screening

Requires the correct person or organization subject and customer-owned review policy. The score is similarity, not a sanctions determination.^[2]

UCC search

Requires debtor identity, jurisdiction, and confirmed coverage. A no-result response outside those bounds cannot mean no lien.

Court search

Requires party identity, jurisdiction, coverage, and procedural review. A complaint is not a finding.

Credit analysis

Begins after the workflow knows which subject and evidence it is evaluating. Verification does not replace ability-to-repay or credit policy.

What Is a Safe High-Level Sequence?

classify subject
  -> resolve legal entity and jurisdiction
  -> run independent identity and screening checks
  -> branch by coverage and availability
  -> collect async results
  -> resolve exceptions
  -> credit analysis
  -> authorized outcome

Independent checks can run in parallel after their inputs are ready. The system should not wait unnecessarily, but speed cannot erase dependencies.

How Should SOS Freshness Be Chosen?

Cached and live state results serve different freshness needs. The lender should define when a recent prior record is sufficient and when a live source check is required, then preserve which route was used.

California publishes jurisdiction-specific business status definitions.^[3] A normalized internal category should retain the original source value and timestamp.

How Should Coverage Branches Work?

Every check should return both an evidence state and a coverage state:

• Supported and result found.

• Supported and no result returned.

• Unsupported.

• Source unavailable.

• Identity unresolved.

• Result requires review.

Unsupported and unavailable are not negative findings. They route to a fallback, retry, or hold.

How Should Sync and Async Products Coexist?

Create a workflow state for each requested check and a parent case that waits only for required terminal states. Cobalt's current documentation includes synchronous and asynchronous products, including callback-based court, contractor, and Full Verification routes.^[4]

Store requests before sending them, deduplicate callbacks, reject unknown events, and prevent stale results from overwriting newer ones.

What Should the Decision Table Contain?

For every check, define:

1. Required inputs.

2. Upstream dependency.

3. Coverage rule.

4. Delivery mode.

5. Continue, stop, hold, or review states.

6. Retained evidence.

7. Fallback.

8. Owner and closure rule.

Avoid a universal product bundle. Different lending products, jurisdictions, subjects, and policies can require different waterfalls.

Which Failure Modes Matter Most?

• Running an EIN check against a DBA before resolving the legal name.

• Screening the wrong entity or individual.

• Reading unsupported UCC coverage as no lien.

• Treating no court result as no litigation nationwide.

• Approving around source unavailability.

• Starting the credit model before the financing recipient is resolved.

• Allowing duplicate callbacks to repeat policy actions.

What Should the Audit Trail Preserve?

• Subject and identity version.

• Dependency graph version.

• Every request, input, source, and timestamp.

• Coverage and availability state.

• Raw evidence reference.

• Fallback or exception disposition.

• Policy and model versions.

• Authorized outcome.

What Should Teams Monitor?

• Checks started without satisfied dependencies.

• Unsupported and unavailable routes.

• Async requests exceeding internal age rules.

• Evidence arriving after a decision.

• Fallback volume by jurisdiction.

• Duplicate callbacks.

• Overrides and reopened cases.

• Decisions made with unresolved required checks.

What Is the Practical Waterfall Design?

Start with legal-subject classification, encode product dependencies, parallelize only independent checks, preserve coverage and availability states, close exceptions, then pass approved evidence into credit analysis.

Cobalt supplies documented verification and screening results. The lender owns the graph, fallbacks, policy, models, exceptions, and decisions.

Ready to test a clean path, unavailable source, unsupported jurisdiction, and identity mismatch? Schedule a Cobalt Intelligence demo and bring the checks and stop conditions in your current waterfall.