What Does an Entity Validation API Actually Validate?

Executive Summary: An entity validation API validates five things about a business: that it exists in an official state registry, what status that registry currently assigns it, whether it carries the compliance obligations that keep it in good standing, who its registered agent is, and which officers the state has on file. Everything else a vendor sells you under the label "entity validation" is either derived from those five fields or is coming from a different data source entirely. For a lender deciding whether to fund an applicant this afternoon, knowing exactly where that line sits is the difference between an audit trail that holds up and a decision built on a vendor's marketing copy. This matters more than it did two years ago. 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.^[1] The same survey found synthetic identity fraud (61 percent), bust-out fraud (56 percent), and application stacking (55 percent) named as the fastest-growing types. All three depend on an applicant entity that looks real enough to pass a shallow check. Entity validation is the layer that decides how shallow that check is. This post walks the response field by field. What each field proves, what it does not prove, and what to do when the state does not return it.

What Does "Validation" Actually Mean in an Entity Validation API?

Validation, in this context, means comparing an applicant's self-reported business details against the record held by the government body that created the entity. It is a reconciliation, not a judgment. The API tells you what the Secretary of State says. It does not tell you whether the business is creditworthy, currently operating, or honest.

Which Regulation Frames the Requirement?

Federal customer identification rules already assume you will do this. Under 31 CFR 1020.220, banks verifying a customer that is not an individual may rely on documentary methods, specifically:

"documents showing the existence of the entity, such as certified articles of incorporation, a government-issued business license, a partnership agreement, or trust instrument."^[2]

An entity validation API is the programmatic version of pulling that document. The separate customer due diligence rule at 31 CFR 1010.230 then requires covered institutions to identify and verify beneficial owners, defined as each individual owning 25 percent or more of the equity interests, plus a single individual with significant responsibility to control, manage, or direct the entity.^[3] Registry officer data touches the second prong. It does not satisfy the first, and no honest vendor will tell you otherwise.

What Is Out of Scope by Definition?

The registry does not hold revenue, bank balances, payment history, or trade lines. It does not know whether the entity has stopped operating. A dissolved entity and a healthy one that missed an annual report can produce identical-looking status strings in some states, which is why the interpretation layer discussed later in this post carries so much weight.

How Does an Entity Validation API Confirm a Business Legally Exists?

Existence is the first field and the simplest one to reason about. Either the state has a record matching the name or entity identifier you submitted, or it does not.

What Does the Existence Check Return?

A search against Cobalt's Secretary of State API returns a `results` array when a match is found, and a `nameAvailable` flag indicating whether the name is still available for registration in that state. An available name is a signal that no entity of that name exists in state records. The response also carries `possibleAlternatives`, up to ten close matches, for cases where the exact match is uncertain.

Here is the request shape:

curl --location 'https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Corp&state=delaware&liveData=true&screenshot=true' \
--header 'x-api-key: Your_API_Key' \
--header 'Accept: application/json'

Why Is "No Results" Not the Same as "Does Not Exist"?

This is where most integrations get sloppy. A null result has at least four ordinary explanations before fraud becomes the leading theory:

• Name variation. The applicant wrote "Acme Logistics LLC" and the state holds "ACME LOGISTICS, L.L.C." Abbreviation and punctuation differences are the single most common cause of a false negative.

• Wrong state. The entity was formed elsewhere and is only qualified to do business where you searched. A foreign corporation is one "incorporated or registered under the laws of one state or foreign country" that does business in another.^[4]

• Recent filing. New entities take time to appear. Oregon's business registry page states its filings were "received as of 8/6/2026" and lists a one to three business day processing window for online Business Registry filings.^[5] A business formed on Monday may be invisible on Tuesday.

• Identifier mismatch. Searching by `sosId` is more precise than name search when the applicant supplied one.

• Address filtering. Adding `street`, `city`, or `zip` narrows results in high-volume states, and an over-narrow filter can suppress a valid match.

Treat a null as a routing decision, not a decline. Send it to the alternatives list, then to a person.

What Is the Difference Between Registration Status and Good Standing?

Status is what the registry says today. Standing is whether the entity has met the recurring obligations that let it keep that status. They are related and they are not the same field, and conflating them produces the two worst outcomes in verification: declining a healthy borrower over a late annual report, or funding an entity whose authority the state has already pulled.

Cobalt's SOS API returns a `status` value plus a normalized status standardized across all 50 states. For the state-by-state meaning of individual status strings, Cobalt's per-state definition pages already carry that work, including the Alabama business entity status definitions reference. This post will not restate them.

What Triggers a Loss of Standing?

The statutory grounds are narrower than most underwriters assume, and they are mostly administrative. Nebraska's Secretary of State lists dissolution for "failure to file an annual/biennial report with our office, maintain a registered agent, or the corporate existence has expired."^[6] North Carolina frames administrative dissolution as what "occurs when a North Carolina business entity has failed to perform any of a number of duties described in statute," and requires an applicant to "correct all reasons that led to the dissolution/revocation or else prove to the Secretary that the grounds do not exist."^[7]

Tax delinquency is a parallel track with its own vocabulary. In Texas, "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," and an involuntarily terminated entity is treated as having continued in existence without interruption "only if it is reinstated before the third anniversary of the date of its involuntary termination."^[8] The Comptroller drives that process through named notices: Form 05-211 Notice of Intent to Forfeit Right to Transact Business, Form 05-212 Notice of Forfeiture of Right to Transact Business, and Form 05-213 Notice of Forfeiture of Registration.^[9]

California attaches the same consequence to a missed information filing. Failure to file the required Statement of Information "may result in penalties being assessed by the Franchise Tax Board and suspension or forfeiture."^[10]

How Should a Lender Score a Standing Failure?

The practical read: administrative dissolution is usually curable and often signals disorganization rather than fraud. A three-year-stale forfeiture in Texas is a different animal, because the continuity of the entity itself is now in question. Score them separately.

Separately means different routing rather than different commentary. The three failure shapes described above map onto three distinct decisions.

Two habits make the table survive production. Date the forfeiture rather than the lookup, because the three-year clock runs from the involuntary termination and not from the day your system noticed it. Then re-run the check at closing on anything routed to manual review, because a reinstatement filed during your review window moves the borrower into a different row and a different decision.

For a working cross-state interpretation table, see how to read registration statuses across states via API.

Why Does the Registered Agent Field Matter to an Underwriter?

The registered agent is the most underused field in the whole response, and it is the one most likely to catch a shell.

What Does the State Require?

Delaware law is representative. Under Title 8, "Every corporation shall have and maintain in this State a registered office," and "Every corporation shall have and maintain in this State a registered agent," which may be the corporation itself, an individual resident, a domestic corporation, or a qualifying foreign corporation.^[11] The agent exists to accept service of process. That obligation is what makes the field reliable: an entity that wants to stay registered has to keep it current.

What Signals Live in the Agent Data?

Cobalt's response returns `registeredAgent` as a name and address pair. Read it for these patterns:

• Commercial agent versus individual. A national commercial agent is neutral information. An individual agent at a residential address on a seven-figure request is worth a question.

• Agent address equal to physical address. Common and legitimate for small operators, but it removes one of your independent address data points.

• Recent agent changes. Agent changes are filed events with their own fee line. Delaware's fee schedule revised August 1, 2026 lists Change of Agent/Office at $50.00 for domestic corporations.^[12] A change immediately before an application is a timing question, not an accusation.

• Agent resignation. A resigned agent with no replacement is a countdown to administrative dissolution in states that list agent maintenance as a ground.^[6]

• Shared agent across applicants. The same non-commercial agent appearing across several applications in a short window is a stacking-adjacent pattern.

That last pattern is what Cobalt's Find Related Businesses beta addresses. Adding `findRelatedBusinesses=true` to a search returns a `relatedBusinesses` object with `byOfficer` and `byAgent` arrays, each entry carrying an address-match indicator. It is in beta, it adds one to two seconds at the top end, and its behavior may change. Treat its output as a review trigger, not a decision input.

What Do the Officer Fields Tell You, and Where Do They Stop?

The `officers` array returns names, titles, and addresses of officers and directors where the state publishes them. This is the field most often oversold.

What Can You Legitimately Conclude?

You can confirm that the person signing the application appears in the state record in a role consistent with signing authority. You can flag the opposite: an applicant claiming to be the owner who appears nowhere in the state's officer list. That is a real and useful control, and it maps to the control prong of the CDD rule, the "single individual with significant responsibility to control, manage, or direct" the entity.^[3]

What Can You Not Conclude?

You cannot conclude ownership. Registry officer data is not a beneficial ownership register, and the 25-percent equity prong of the CDD rule is not answerable from it.^[3] The federal beneficial ownership picture also narrowed rather than widened: the New York LLC Transparency Act took effect January 1, 2026, but its reporting scope reaches only LLCs formed outside the United States and registered to do business in New York, and the resulting database is nonpublic, accessible to law enforcement and government agencies rather than to lenders.^[13] A state transparency statute does not become an underwriting data source just because it exists.

Stated limitation: officer data availability varies by state. Some states publish officer and director information and others do not. Cobalt returns whatever the state makes available and does not synthesize the gap. If your risk model treats a missing officer array as a negative signal, you will systematically penalize applicants in non-disclosing states. Model the absence as unknown, not as absent.

How Should You Handle Fields the State Does Not Return?

Field-level coverage varies more than entity-level coverage. Nearly every state will tell you an entity exists. Fewer will tell you who runs it.

What Is the Practical Design Pattern?

Build your decision logic against a required core and an optional periphery. The core that is reliably present across the registry set is legal name, status, entity type, filing date, and state of formation. Registered agent is close behind. Officers, addresses, and document-level detail sit in the optional tier.

Two mechanisms in the SOS API help here. The confidence score, returned from 0.0 to 1.0, gives you a routing threshold rather than a binary: high scores auto-accept, mid-range scores go to review, low scores are probably a different entity. The `possibleAlternatives` array gives a reviewer the shortlist instead of sending them to a state website.

What About Slow and Restricted States?

Response time is a coverage question in disguise. Most states return in ten to thirty seconds. Oregon can take up to five minutes on a live lookup. Delaware status checks require a paid state request that is passed through at cost, which is a state-imposed fee rather than a Cobalt charge, and New Jersey status data is restricted by statute with a small fee attached. Design for it: pass a `callbackUrl` and let the result come to you, or poll with the `retryId` from the initial response. The mechanics of that are covered in async webhook architecture for long-running SOS lookups, which this post will not restate.

What Does a Validated Entity Response Look Like in Practice?

Everything above resolves into one JSON object. Reading it in order is the fastest way to see which of the five validations actually landed.

{
  "status": "complete",
  "statusCode": 200,
  "requestId": "abc123-def456",
  "nameAvailable": true,
  "results": [
    {
      "title": "ACME CORPORATION",
      "filingDate": "2015-03-15",
      "stateOfFormation": "Delaware",
      "status": "Active",
      "entityType": "Corporation",
      "registeredAgent": {
        "name": "CT Corporation System",
        "address": "1209 Orange St, Wilmington, DE 19801"
      },
      "officers": [
        {
          "name": "John Smith",
          "title": "CEO",
          "address": "123 Business Ave, New York, NY 10001"
        }
      ],
      "physicalAddress": "456 Corporate Blvd, Suite 100, New York, NY 10001",
      "sosUrl": "https://icis.corp.delaware.gov/ecorp/...",
      "screenshotUrl": "https://screenshots.cobaltintelligence.com/..."
    }
  ],
  "possibleAlternatives": []
}

Which Fields Carry the Audit Weight?

`sosUrl` points to the state's own record, which is what a regulator or a litigation hold will ask for. `screenshotUrl` returns a timestamped image of the state page at the moment of verification, and `requestId` ties the whole response to a log line. Stated limitation: screenshot URLs are valid for a limited window of roughly three to thirty days, so the download and store step belongs in your integration, not in a manual process someone remembers to run.

Before choosing between exact-identifier retrieval and fuzzy name matching for this call, the tradeoffs are worked through in company lookup API versus company search API.

Where Does Entity Validation Fit in the Rest of the Stack?

Wolters Kluwer, CSC, and Cogency Global sell registered agent and compliance services that produce documents; Middesk and similar platforms bundle registry data into a broader onboarding product. The distinction that matters when you are choosing is whether you are buying documents, a decision, or the underlying data at the point in your flow where you need it. Cobalt sells the third. The SOS API covers all 50 states plus the District of Columbia, pulls live from official state sources when `liveData=true`, and bills one credit per lookup, with a monthly-refresh cached mode for pre-screening.

What Should Sit Before and After It?

Entity validation answers "is this a real, currently-registered business, and does the person in front of me appear in its record." It does not answer identity, tax identifier, lien position, or ability to repay. Sequence it early, before you spend money on document processing, and pair it with the checks that answer the other questions. The stack ordering is laid out in the best KYB APIs for lending risk assessment, and the tax identifier side is covered in the EIN verification API lender guide.

For the full landscape of providers pulling this data, including how the direct-access and platform models differ, start with the top Secretary of State API solutions for verifying businesses. For the operational how-to on running the check itself, see how to verify business registration status via API.

The honest summary: an entity validation API validates registry facts with high reliability and everything else with none. Build the decision around that boundary and the field is worth what you pay for it.