A Pre-Funding Business Verification Framework for Alternative Lenders

Executive Summary: A useful pre-funding verification framework does more than list checks. It defines what each check can establish, separates recoverable exceptions from potentially adverse records, and tells the team what happens next. The lender keeps control of policy and the funding decision. Cobalt supplies source data for selected controls. That distinction matters when a team is trying to maintain deal velocity. A state-source timeout, a TIN name mismatch, a possible sanctions match, an unsupported search, and a returned filing are five different operational events. Treating all five as one generic risk result makes the queue simpler to name but harder to manage. This guide gives risk, underwriting, operations, and engineering teams one control map they can use before funding: `Applicant question -> source -> returned evidence -> result class -> next path -> owner -> evidence retained`

What Must the Framework Decide Before Funding?

Start with the decision the workflow must support, not the number of data sources it can call. For every control, the team should agree on seven fields:

• Applicant question. What assertion are you testing, such as legal entity name, formation state, submitted EIN, or possible sanctions identity?

• Source. Which state registry, government matching service, official list, or court source is being queried?

• Returned evidence. Which input, result, timestamp, request identifier, and source detail will be available?

• Result class. Is the response a confirmed source fact, correctable mismatch, ambiguous match, technical failure, unsupported search, or potentially adverse record?

• Next path. Can the deal continue, or does it need correction, retry, another source, or human review?

• Owner. Which team owns the rule, exception, disposition, and later policy change?

• Evidence retained. What must remain in the lender's system of record after the case is resolved?

The submitted application is an assertion. A source response is evidence about one narrow question. The lender's policy determines what follows. Keeping those three layers separate prevents a data response from silently becoming a credit decision.

A failed request is not a failed business. A possible match is not a confirmed identity. A returned record is not a complete underwriting conclusion.

Six Result Classes Keep Unlike Exceptions Separate

The most important design choice is the result vocabulary. If every non-clean response becomes `review`, the lender loses the reason the deal left the straight-through path. Use distinct classes even if several classes eventually land in the same queue.

Cobalt's public SOS response guide illustrates why the technical class must remain separate. A `202` incomplete response means the search is still running and should be polled with its `retryId`; an empty complete result and a failed request are different states.^[1]

This separation also improves reporting. Operations can measure technical exceptions without mixing them with underwriting reviews. Risk can examine potentially adverse records without counting source outages as applicant issues. Engineering can see where inputs, callbacks, or retry handling need work.

Each Verification Control Must Answer One Narrow Question

The framework should state what each source can and cannot establish. This is where a checklist becomes an operating control.

Secretary of State Search

Question: What did the named state's entity source return for this business name or registration identifier?

Cobalt's single-state lookup requires a business name or state registration ID plus the state and API key.^[2] Its public coverage guide describes SOS access across all 50 states and D.C., while field availability depends on what each state makes available.^[3]

Retain the submitted name and state, returned legal name, status, formation details, request ID, and source URL or screenshot URL when requested and available. Route no match, close alternatives, incomplete responses, and unavailable sources according to their actual class.

An SOS result does not prove beneficial ownership, repayment capacity, or that an active entity is a good credit. Officer fields, when returned, do not become verified ownership merely because they appear in a registry response.

For a deeper look at using entity and filing data together, see Cobalt's guide to SOS and UCC verification before funding.

TIN and EIN Verification

Question: Does the submitted business name and TIN combination match the returned IRS result?

The IRS describes TIN Matching as a service that validates name and TIN combinations before information returns are filed.^[4] Cobalt's public documentation identifies structured IRS result codes, including invalid input, unissued TIN, mismatch, and several match types.^[5]

A mismatch belongs in correction or review, not an automatic fraud conclusion. IRS name-control guidance explains that the control is derived from the taxpayer name and that the submitted naming form can affect the match.^[6]

Retain the exact submitted pair, returned code and reason, service status, and check time. TIN verification validates a submitted pair. It does not discover an EIN, establish ownership, or determine creditworthiness.

See Cobalt's related explanation of why EIN verification belongs before funding.

UCC Search

Question: Which financing statements did the supported state search return for the exact debtor name used?

A UCC financing statement gives notice that a creditor has or may have a security interest in a debtor's personal property. Amendments can terminate, continue, assign, or change a statement.^[7] State indexes can also depend on the exact debtor name supplied, and official records can include disputed or wrongfully filed information.^[8]

Retain the searched name, jurisdiction, filing number, filing date, debtor, secured party, collateral text, and amendments where returned. Alternate names, disputed filings, and unclear collateral need an exception path.

A filing does not by itself prove a current balance, payoff status, lien priority, or loan stacking. Cobalt's public coverage guide currently describes UCC availability in 11 states, so the workflow also needs an unsupported-search route rather than assuming nationwide coverage.^[3]

OFAC Screening

Question: Did the name search return potential matches from the sanctions lists searched?

OFAC's public search uses fuzzy logic and returns potential matches across the SDN and consolidated non-SDN lists.^[9] OFAC also warns that a similar name can be a false positive when other identifying information does not match the listed party.^[10] Cobalt states that its OFAC data originates from U.S. Treasury sanctions sources.^[11]

Retain the submitted name and entity type, potential-match details, list information, comparison identifiers, and reviewer disposition. A match score is not a final identity determination. The lender must define the review and escalation policy appropriate to its operation and obligations.

Court-Record Search

Question: What cases or judgments did the supported source return for this name and jurisdiction?

Cobalt's documented court coverage is limited to New York State and Miami-Dade County.^[3] New York's court system says its online sources do not include every court and directs users to courts or county clerks for records when needed.^[12] Miami-Dade provides a public route for civil, family, and probate case information, with a separate process for certified copies.^[13]

Retain the searched name, jurisdiction, case identifier, filing date, parties, and disposition where returned. An ambiguous party, active matter, incomplete online record, or unsupported jurisdiction needs review or another source.

A filing does not prove liability, misconduct, financial distress, or inability to repay. The result must be interpreted in its procedural and identity context.

Multi-State Verification

Question: Which state sources returned possible entity registrations when the state is unknown?

Cobalt's public lookup guidance describes Full Verification across all 50 states and D.C.^[2] The approved product record shows that this is an asynchronous, multi-step operation. Treat per-state completion, unavailable sources, multiple candidates, and partial results as explicit response states rather than one instant pass or fail.

Retain the input, search identifier, per-state status, returned candidates, and final disposition. When the formation state is already known, the team should decide whether a single-state check answers the question more directly.

A Worked Deal Shows Why Result Classification Comes First

Consider a fictional equipment-finance application from North Harbor Service Group LLC. The name is invented for this example. The workflow receives four responses:

1. The SOS search returns a sufficiently identified entity record and request

ID.

1. TIN verification returns a name mismatch.

2. OFAC screening returns a possible similar-name match.

3. A UCC search returns one financing statement for the searched debtor name.

One `review` flag is not enough. The framework should route each response by meaning:

The SOS record does not clear the other controls. The TIN mismatch does not cancel the state record. The possible OFAC match does not become a confirmed identity. The UCC filing does not prove stacking. Each result keeps its own meaning until the lender applies policy.

What Should the Lender Retain in Its System of Record?

The case file should let another qualified person reconstruct what the team asked, what the source returned, why the result took its path, and who resolved it. A practical minimum is:

{
  "applicationInput": {},
  "control": "named check",
  "source": "identified source or jurisdiction",
  "requestId": "provider request identifier",
  "checkedAt": "customer-recorded timestamp",
  "rawResult": {},
  "resultClass": "confirmed | mismatch | ambiguous | technical | unsupported | adverse",
  "nextPath": "continue | correct | retry | alternate-source | human-review",
  "owner": "team or role",
  "disposition": "documented customer decision",
  "sourceProof": "stored artifact or source reference when available"
}

This is a conceptual case-record model, not a Cobalt API response schema. Each lender should adapt fields, access controls, and retention periods to its own systems and requirements.

If the provider returns a screenshot URL or other hosted artifact, the lender should still define how evidence is stored in its own system. A hosted link is not a substitute for customer-owned retention, and this framework does not set a universal retention period or promise that an artifact will be accepted by every examiner.

Where Does Cobalt Fit, and Where Does Its Role End?

Cobalt can provide the source-evidence layer for selected controls: SOS records, TIN match results, supported UCC data, potential OFAC matches, limited court-record results, multi-state entity results, async status handling, and request or source evidence where documented.

The lender still owns:

• the checks required for its products and jurisdictions;

• the data it collects from the applicant;

• the thresholds for normal and exception paths;

• the people authorized to resolve ambiguous or potentially adverse results;

• the credit, pricing, and funding rules;

• the retained case file and retention policy; and

• the final disposition.

That boundary is useful during implementation. Risk defines what each result means. Operations defines who works each exception. Engineering preserves response states and evidence. Cobalt supplies selected verification results without becoming the lender's scoring model or decisioning engine.

To review how the evidence layer can fit your existing pre-funding workflow, talk with Cobalt Intelligence about your states, checks, response paths, and evidence requirements.