Executive Summary: A borrower in New York is recorded as past due on a biennial statement. A borrower in California is suspended. A borrower in Florida is administratively dissolved. A borrower in Texas is forfeited. Four registries, four words, and in three of those four cases the underlying condition is the same: the business missed a recurring filing or payment and the state applied its standard penalty. If your underwriting system reads those four strings as four different risks, it is producing four different decisions from one fact pattern. That is the real problem with reading registration status at portfolio scale. The API call is the easy part. The hard part is the interpretation layer sitting behind it, the code that decides what a state's word means, how severe it is, and which queue the file belongs in. Get that layer wrong and the error is systematic rather than occasional: every borrower in a given state is misrouted the same way, every time, until someone notices. The pressure to get it right went up. In a Celent survey of 115 U.S. financial institutions published May 7, 2026, 93 percent of lenders said fraud contributes to their credit losses and 82 percent reported that fraud losses increased year over year, with synthetic identity fraud at 61 percent, bust-out fraud at 56 percent, and application stacking at 55 percent named as the fastest-growing types.[1] Registration status is one of the cheapest controls against all three, and it only works if the reading is consistent. This post is about that reading. Not what each state's status label means in isolation, which Cobalt's per-state definition pages already cover, but how to normalize fifty vocabularies into a small set of conditions, route each condition by severity, model the unknowns honestly, and keep the mapping correct as states change their language.
Why Do Two States Use Different Words for the Same Registration Problem?
State registries were built independently under separate statutes, and the language follows the statute rather than any shared convention. Nothing forces Florida and Texas to describe a delinquent filer with the same word, and they do not.
Which Words Actually Appear in the Registries?
Pull the primary sources and the divergence is immediate. The following are the state's own descriptions, not vendor paraphrases:
• New York uses "past due" and applies it to the record, not the entity. A corporation or LLC that fails to file its biennial statement "will be reflected in the New York Department of State's records as past due in the filing of its Biennial Statement," and any certificate of status will carry that notation.[2]
• California pairs suspension with forfeiture and routes both through a tax agency. Failure to file the required Statement of Information "may result in penalties being assessed by the Franchise Tax Board and suspension or forfeiture."[3]
• Florida calls it administrative dissolution and specifies the deadline down to the hour. Grounds include failure to "deliver its annual report to the department by 5:00 p.m. Eastern Time on the third Friday in September of each year," failure to pay a fee or penalty, and failure to appoint and maintain a registered agent.[4]
• Texas splits the vocabulary by cause. When an entity "fails to file a franchise tax report and/or pay franchise taxes, the secretary of state forfeits it under the Texas Tax Code," which is a separate track from involuntary termination for a missed periodic report.[5]
• Washington sets its grounds in days. Administrative dissolution follows when an entity does not pay a required fee, does not deliver an annual report "not later than one hundred twenty days after it is due," has no registered agent "for thirty consecutive days," or its stated period of duration expired.[6]
• Nebraska groups dissolution and revocation together. The listed causes are failure to file an annual or biennial report, failure to maintain a registered agent, or expiration of corporate existence.[7]
• Delaware escalates to the Governor. Under Title 8, a corporation that neglects or refuses for one year to pay franchise tax reaches the point where "the Governor shall forthwith issue a proclamation declaring that the charters of these corporations are repealed."[8]
Seven states, seven vocabularies, and every one of those conditions traces back to a missed filing, a missed payment, or a lapsed agent.
"A corporation or LLC that fails to file its Biennial Statement will be reflected in the New York Department of State's records as past due in the filing of its Biennial Statement."
That New York sentence is worth sitting with, because it shows the second axis of divergence.[2] New York marks the filing as past due while the entity itself remains active. Florida dissolves the entity. Those are different legal states wearing similar-sounding labels, and a mapping that treats "past due" and "dissolved" as one bucket is as wrong as one that treats them as unrelated.
Why Does a Status Allowlist Break in Production?
The common first implementation is an allowlist: proceed on "Active" and "Good Standing," stop on everything else. It breaks for three reasons.
It breaks on unmapped strings. Registries add, retire, and reword status values, and an unmapped value falls to whichever branch the code defaults to. If the default is proceed, a dissolved entity funds. If the default is stop, a healthy borrower in a state with unusual phrasing gets declined for a vocabulary mismatch.
It breaks on abbreviations. Alabama, Delaware, Illinois, and Wisconsin all publish status codes that read as opaque tokens to anyone outside that state's filing office. Cobalt already maintains per-state definition references for exactly this reason, including Alabama entity status definitions, Delaware entity status definitions, Illinois entity status definitions, and Wisconsin entity status definitions. Illinois INACT-UA, to take the most-asked example, is an inactive designation whose specific cause is explained on the INACT-UA reference page rather than restated here.
It breaks on severity. An allowlist is binary, and registration problems are not. Between "current on everything" and "the state repealed the charter" there are at least three intermediate conditions that deserve different handling, and a two-value output cannot express them.
What Underlying Conditions Should Every State Status Map To?
The fix is a normalization layer with a small, closed set of conditions. Every raw state string maps to exactly one of them, and your decision logic reads only the normalized value. Six conditions cover the registry set.
| Normalized condition | What the record supports | Representative state language |
|---|---|---|
| Current | All recurring obligations met as of the registry's last update | Active, Good Standing |
| Filing delinquency | A periodic report is late, entity existence intact | New York past due on a biennial statement[2] |
| Agent failure | No registered agent on file, a countdown to dissolution in most states | Washington after thirty consecutive days without an agent[6] |
| Tax failure | A revenue agency has acted, and a liability sits ahead of your position | California suspension or forfeiture[3], Texas franchise tax forfeiture[5] |
| Terminated | The state ended or repealed the entity's authority | Florida administrative dissolution[4], Delaware charter repealed by proclamation[8] |
| Unknown | The registry returned nothing usable, for reasons covered later in this post | No match, restricted data, timeout |
Which Conditions Are Genuinely Distinct?
Filing delinquency and tax failure look similar on a screen and behave differently in a credit file. A late annual report costs a filing fee and a signature. A tax forfeiture means a state revenue agency has an unsatisfied claim, and that claim did not disappear because the borrower found you.
Terminated is also less final than it sounds, which is the single most common misreading. Florida is explicit that an administratively dissolved LLC "continues in existence but may only carry on activities necessary to wind up" its operations, and that dissolution "does not terminate the authority of its registered agent for service of process."[4] The entity still exists. Its authority to conduct ordinary business does not. Cobalt's North Carolina administrative dissolution reference answers the same question for that state, and North Carolina's own reinstatement guidance describes administrative dissolution as what "occurs when a North Carolina business entity has failed to perform any of a number of duties described in statute."[9]
What Does Normalization Give You, and What Does It Not?
Cobalt's Secretary of State API returns both the raw `status` string the state published and a normalized status standardized across all 50 states plus the District of Columbia. That covers the mechanical half of the work: your code stops maintaining fifty parsers.
It does not cover the judgment half. A normalized label still has to be assigned a severity and a route by someone who understands your credit box, and that assignment is yours rather than the vendor's. Two limitations belong in the same breath. Officer data availability varies by state, so a mapping that reads officer presence as a health signal will penalize applicants in states that do not publish it. And a normalized value is a mapping, which means the raw string has to be retained alongside it so that a disputed decision can be traced back to what the state actually said.
How Should Each Normalized Condition Route Inside an Underwriting Flow?
Severity routing is where the interpretation layer earns its keep. The goal is a small number of destinations, each with a written rule, so that two underwriters reading the same response reach the same place.
| Condition | Route | Rule |
|---|---|---|
| Current | Proceed | No registry-driven hold. Recheck at closing on anything above your dollar threshold. |
| Filing delinquency | Proceed with condition | Fund against evidence the report is filed. Hold the file open until the record reads current. |
| Agent failure | Manual review | Confirm whether a replacement was filed. An unreplaced lapse is a dissolution clock, and in Washington it runs at thirty days.[6] |
| Tax failure | Manual review with a priority question | Establish the size and position of the tax claim before pricing. |
| Terminated | Decline as presented | The signer may not be authorized on behalf of an entity whose authority the state has ended. Reinstatement changes this, as the next section covers. |
| Unknown | Route to a person, never to a decision | Treat as missing data. A null is an instruction to look harder. |
What Should Drive the Routing, the Label or the Date?
The date. Every condition above has a clock attached, and the clock changes the answer more than the label does. Texas treats an involuntarily terminated entity as having continued in existence without interruption "only if it is reinstated before the third anniversary of the date of its involuntary termination."[5] A Texas termination dated eight months ago and one dated four years ago carry the same status string and completely different continuity risk.
Two production habits follow. Date the state event rather than the lookup, because the statutory clocks run from the filing or forfeiture and not from the moment your system noticed. And store the event date as a first-class field, because a routing rule that cannot see it will collapse both Texas cases into one queue.
How Many Distinct Routes Should the System Actually Have?
Fewer than you think. Six normalized conditions collapsing into four routes is sufficient for most alternative lending flows: proceed, proceed with condition, manual review, decline. Adding a fifth route usually means someone wanted to express a pricing adjustment inside a verification system, and pricing belongs in the credit model with the rest of the risk inputs.
Why Does Reinstatement Relate Back, and What Does That Do to a Decline?
This is the part most verification logic gets wrong, and it is worth building around explicitly.
What Does "Relates Back" Mean for a Decision You Already Made?
In many states, reinstatement is retroactive. Florida provides that "the reinstatement relates back to and takes effect as of the effective date of the administrative dissolution."[10] Washington uses nearly identical language, adding that the entity "resumes carrying on its activities and affairs as if the administrative dissolution had never occurred," subject to an exception for "the rights of a person arising out of an act or omission in reliance on the dissolution before the person knew or had reason to know of the reinstatement."[11]
Read that reliance clause carefully, because it is the one place where your documentation of the lookup does legal work. If you declined or repriced based on a dissolution you verified at the time, the statute preserves rights arising from that reliance. If you cannot show what the registry said and when, you are relying on a memory.
How Should You Time the Recheck?
Relation-back means a stale terminated status can be wrong in the borrower's favor, so the recheck is not a formality. Three rules cover it:
• Recheck at closing on anything routed to manual review or decline. A reinstatement filed during your review window moves the file to a different route.
• Recheck before any adverse action notice goes out. Sending one on a condition the state has already cured is an avoidable dispute.
• Recheck before a renewal or a line increase, not on a fixed calendar. Registry facts change on filing cycles, and North Carolina requires an applicant to satisfy all grounds and file any delinquent annual reports before reinstatement is granted, which takes time you can observe.[9]
The recheck itself is a point-in-time call. Cobalt's guide to automating filing status updates via API covers the scheduling patterns for that pattern in more depth.
How Do You Model an Unknown Without Turning It Into a Decline?
Unknown is a real condition and deserves the same design attention as the others. Collapsing it into "fail" is the most common source of false declines in registry-driven verification.
When Is "Not Found" a Data Gap Rather Than a Risk Signal?
At least four ordinary explanations come before fraud. The applicant wrote the name differently from the way the state holds it. The entity was formed in another state and is only qualified where you searched, and a foreign corporation is one "incorporated or registered under the laws of one state or foreign country" that does business in another.[12] The filing is too recent to appear, and Oregon's registry page states its filings were "received as of 8/6/2026" with a one to three business day window for online Business Registry filings.[13] Or the search used a name where an entity identifier would have been exact.
Two states add their own version of unknown for reasons that have nothing to do with the borrower. Delaware status checks require a paid state request, priced by Delaware at $10 for current status and $20 for status with tax and filing history, passed through at cost rather than added as a Cobalt charge.[14] New Jersey status data is restricted by statute with a small fee attached. A pipeline that silently skips paid states will show those borrowers as unknown forever, and nobody will notice because the code did not error.
What Does the Response Tell You About Its Own Reliability?
Cobalt's SOS API returns a confidence score from 0.0 to 1.0 on every result, with the practical bands being high confidence at 0.8 and above for auto-accept, 0.5 to 0.79 for human review, and below 0.5 as probably a different entity. It also returns `possibleAlternatives`, up to ten close matches, which is what a reviewer needs to resolve a near-miss without opening a state website. Reading the confidence score before reading the status is the correct order, because a status string attached to a 0.4-confidence match is a fact about the wrong company.
Response time is the other reliability signal. Most states return in ten to thirty seconds, and Oregon live lookups can take up to five minutes, which means a synchronous integration will time out on the slowest states and record an unknown that is purely an artifact of your own timeout setting. Pass a `callbackUrl` or poll with the `retryId` from the initial response instead.
What Does the Interpretation Layer Look Like in Code?
The request is unremarkable. Everything interesting happens to the response.
curl --location 'https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Corp&state=texas&liveData=true&screenshot=true' \
--header 'x-api-key: Your_API_Key' \
--header 'Accept: application/json'A live result carries the state's own vocabulary in `status`, alongside the fields that let you date the event and prove the read:
{
"status": "complete",
"statusCode": 200,
"requestId": "abc123-def456",
"results": [
{
"title": "ACME CORPORATION",
"filingDate": "2015-03-15",
"stateOfFormation": "Delaware",
"status": "Active",
"entityType": "Corporation",
"sosUrl": "https://icis.corp.delaware.gov/ecorp/...",
"screenshotUrl": "https://screenshots.cobaltintelligence.com/..."
}
],
"possibleAlternatives": []
}Which Fields Should the Mapping Read?
The mapping function should take the whole result object rather than the status string alone. It needs `status` for the raw label, the normalized status for the condition, `state` for the jurisdiction-specific rule set, `filingDate` and `stateOfFormation` to separate a domestic record from a foreign qualification, and the confidence score to decide whether the record is about the applicant at all. Field-by-field definitions live in Cobalt's Secretary of State API fields reference.
Its output should be a small structure rather than a single value: the normalized condition, the severity tier, the route, the raw string it came from, and the reason. Underwriters who can see the reason stop escalating tickets to engineering, and auditors who can see the raw string stop asking for screenshots of screenshots.
How Do You Keep the Mapping Correct as States Change Their Language?
A status mapping is code with a shelf life. States reword labels, add codes, and change the events that trigger them, and nothing notifies you.
What Belongs in the Monitoring?
Alarm on the unmapped case. Any raw status string that does not resolve to one of the six conditions should raise an alert and route the file to a person, never fall through to a default branch. The count of unmapped strings per week is the health metric for the whole layer, and a mapping that has produced zero unmapped values in a year is more likely broken than perfect.
Review the mapping on a schedule tied to filing seasons rather than to your sprint cadence, since that is when new delinquency labels appear in volume. Florida's third-Friday-in-September annual report deadline is a good anchor for one of those reviews.[4]
What Should You Log for the Audit File?
Log the raw status, the normalized condition, the severity tier, the route taken, the `requestId`, the `sosUrl`, and the `screenshotUrl` if you requested one. The federal customer identification rules already assume you can produce the underlying evidence, allowing verification through "documents showing the existence of the entity, such as certified articles of incorporation, a government-issued business license, a partnership agreement, or trust instrument," and requiring banks to retain the identifying information "for five years after the date the account is closed."[15]
One limitation to design around: Cobalt's screenshot URLs stay valid for a limited window of roughly three to thirty days, so the download-and-store step belongs inside the integration rather than in a manual process someone remembers to run. A five-year retention obligation and a thirty-day URL do not reconcile themselves.
Where Does Cross-State Status Interpretation Sit in the Verification Stack?
Wolters Kluwer, CSC, and Cogency Global sell registered agent and compliance services that produce filings and documents. Middesk and similar onboarding platforms bundle registry data into a decision product with their own interpretation already applied. Dun and Bradstreet and the traditional bureaus sell a historical view assembled from many sources. Each of those is a legitimate answer to a different question, and the question that separates them is whether you want the interpretation to happen inside your system or someone else's.
If it happens inside yours, you need direct access to the underlying registry data with the raw values intact. That is the model Cobalt sells: all 50 states plus the District of Columbia, live from official state sources when `liveData=true`, one credit per lookup, with a monthly-refresh cached mode for pre-screening volume. For the full provider landscape, including how the direct-access and platform models differ in practice, start with the top Secretary of State API solutions for verifying businesses.
The adjacent reading is worth doing in order. How to verify business registration status via API covers running the check itself, and what an entity validation API actually validates covers what each returned field can and cannot prove. This post assumes both and sits one layer above them.
The conclusion is narrower than it looks. Cross-state status reading is not a data problem, since the registries publish what they publish and an aggregating API can retrieve it reliably. It is a semantics problem, and semantics problems are solved by writing the mapping down, alarming on the cases it does not cover, and keeping the raw value next to the interpreted one so that every decision can be re-derived from what the state said rather than from what your code concluded.
.jpg){kind=small}
.png)