Filing Date Verification for Time-in-Business Rules in Alternative Lending

Executive Summary: A lender may calculate time in business from an application answer, a website claim, or a state filing date even though those dates describe different events. The practical question for VP Risk; Underwriting Director is how to calculate and document a time-in-business rule when formation, registration, effective, operating, and application dates differ. A defensible workflow keeps the submitted identity, source record, normalized fields, and lender decision separate.

Why Does This SOS Decision Fail in Production?

What gets collapsed too early?

Teams often overwrite the application with the first plausible registry result, convert varied state terms into one status, and save only the fields visible to the reviewer. That makes the file fast to scan but hard to reproduce. Cobalt's automation guide shows how one API route can standardize state lookups, while the state source remains the underlying authority.^[2]

What idea should govern the design?

Use the state filing date as a sourced input with a named jurisdiction and field meaning, then let lender policy define the clock, exceptions, and decision instead of presenting the API date as universal business age. The system should be able to show what the applicant submitted, what the state returned, how the platform normalized it, and which customer rule produced the disposition.

The source record answers a state-registry question. The lender still owns the identity join, policy, exception, and credit action.

What Does the Secretary of State Source Actually Support?

Which product fields are relevant?

SOS responses can include a filing date or date of formation where the state publishes it, together with legal title, jurisdiction, status, entity type, identifier, and source URL. Cobalt's current field reference explains that state availability varies and that the same normalized schema may be populated differently across jurisdictions.^[3]

Which conclusions stay outside the source?

A filing date can represent formation, registration, conversion, or a foreign qualification depending on the jurisdiction. It does not prove when operations, revenue, ownership, or the current business activity began. Delaware, for example, says its free entity search returns formation date and agent information but does not itself provide entity status; status is a separate service.^[10] A workflow must not assume every state's search exposes the same legal meaning.

Which Date Should Start the Lender's Clock?

Why can one entity have several valid dates?

A company can have an original formation date, a later foreign-registration date, an amendment effective date, a conversion date, a DBA registration date, and a claimed operating start date. California defines its registration date as the date a domestic or foreign entity registered in California, or converted to a California entity.^[8] Florida separately displays a date filed and, when applicable, an effective date.^[9] For a foreign entity, a registration date can be later than formation in the home jurisdiction.

What should policy define explicitly?

• Eligible date field. Name the source and jurisdiction meaning accepted by the product.

• Calculation date. Specify application, approval, or funding date.

• Minimum period. Keep the threshold in lender policy, not in API code.

• Foreign registration. Decide whether to retrieve the home-jurisdiction formation record.

• Conversion or merger. Define the continuity evidence required.

• Missing date. State the fallback evidence and authorized reviewer.

• Recent formation. Name the action, evidence, and override authority.

How Should the Calculation Be Stored?

What makes the result reproducible?

Store the raw date, field name, jurisdiction, source URL, retrieval timestamp, calculation date, calculation method, derived duration, policy version, and disposition. Keep the applicant's claimed start date separately so analysts can see whether the two dates conflict.

source date + jurisdiction meaning
  -> policy-selected start date
  -> calculation date
  -> completed months or years
  -> pass, review, or exception under lender policy

Which cases should never auto-pass?

Route missing dates, foreign-registration dates mistaken for formation, future or malformed values, a recent conversion without continuity evidence, and large differences between application and state dates. The API supplies a source value; the lender owns whether that value satisfies a time-in-business rule.

What Step-by-Step Workflow Should the Lender Use?

Which actions happen before a decision?

• Capture the applicant's claimed operating date. Record the source, owner, and disposition required at this step.

• Retrieve the state record and exact filing-date field. Record the source, owner, and disposition required at this step.

• Identify formation versus foreign registration. Record the source, owner, and disposition required at this step.

• Preserve jurisdiction and source definition. Record the source, owner, and disposition required at this step.

• Apply the lender's policy clock. Record the source, owner, and disposition required at this step.

• Route recent, missing, or conflicting dates to exception review. Record the source, owner, and disposition required at this step.

• Store the calculation and policy version. Record the source, owner, and disposition required at this step.

This sequence should run under a versioned policy. The API can retrieve and normalize data, but only the customer system knows the application, account, exposure, product requirements, and authorized exception.

When should the route stop for review?

Stop when the jurisdiction is unknown, the record cannot be uniquely resolved, a required field is unavailable, the raw state value conflicts with the normalized result, the source is unavailable, or the evidence does not connect the record to the proposed borrower. A no-result search can justify another query or stronger evidence; it cannot justify inventing the missing join.

How Should Engineering Separate Source and Decision Data?

What records should remain distinct?

Use one immutable source-response record, one selected-entity link, one normalized current-state view, and one customer disposition. Keep the request ID and source URL so an analyst can trace the displayed field back to the retrieval. Preserve alternatives when they affected the selection.

The current Cobalt buying checklist recommends testing ordinary and edge cases across representative states before vendor selection.^[4] Include long-running states, no results, multiple candidates, paid-state behavior, fields absent by jurisdiction, and any temporary evidence link.

How should freshness be represented?

Store the check timestamp and whether the request used live or cached data. Cobalt's freshness guide distinguishes real-time source retrieval from cached registry data.^[5] A cached result can support screening, but a final decision should follow the lender's documented freshness requirement. Do not label cached data current without the check mode and date.

submitted data
  -> source query and raw response
  -> selected entity and normalized view
  -> customer rule and exception evidence
  -> lender-owned disposition

How Should State Differences Be Handled?

Why does a national schema still need jurisdiction context?

California defines registration date, jurisdiction, status, agent, and addresses on its search page and cautions about foreign-entity status.^[8] Florida exposes different search routes and detail fields.^[9] A consistent API schema reduces engineering work, but it should not erase the source field, jurisdiction, or unavailable value.

Cobalt's state-coverage checklist recommends evaluating the fields a buyer needs in each state rather than relying only on a coverage count.^[6] That is the right procurement test for this workflow.

What should happen when a field is missing?

Represent it as unavailable from the source, not empty evidence of a negative fact. Route any field that is mandatory for the lender's decision to a documented fallback or exception. Do not infer an officer, formation date, status, or address from a different source without recording the new source.

Which Controls Should Operations Measure?

What reveals a broken process?

Track unresolved candidates, no-result rate by state and input channel, reviewer overrides, source-unavailable events, missing required fields, stale cached decisions, temporary evidence not archived, and dispositions without source IDs. Segment the results by jurisdiction and rule version.

What should not be claimed from these measures?

Operational counts can show where identity resolution or evidence handling fails. They do not prove fraud detection, default reduction, approval lift, legal compliance, or customer ROI without separate evidence. Keep those outcome claims out of the article and out of the decision rule.

How Does Cobalt Fit Without Owning the Decision?

Which alternatives should buyers compare?

Teams can use state portals manually, build state-specific connectors, or buy a commercial KYB source. Compare them on live and cached modes, source traceability, field availability, alternative handling, response behavior, temporary evidence, and how much state-specific maintenance remains with the customer.

Cobalt provides a normalized SOS retrieval path across all 50 states and D.C. under the current product authority. The lender provides the application context, entity selection, exception policy, storage controls, and decision. That division is the honest answer to how to calculate and document a time-in-business rule when formation, registration, effective, operating, and application dates differ.

What is the next useful test?

Test one clean entity and at least four exception cases tied to this topic. Confirm that the system preserves the submitted value, raw response, selected record, source context, rule version, and human disposition. Then test that a later source or mapping change does not rewrite the historical evidence.

To test the current API behavior with your own field and exception requirements, schedule a Cobalt Intelligence demo. Bring representative states, clean cases, and the exceptions your team sees today.