Can You Search Secretary of State Records by a Person Name? Finding an Owner's Businesses

Executive Summary: Searching Secretary of State records by a person name returns the business filings a state has indexed under that name, which is narrower than the list of businesses the person owns. Some states expose an officer or agent name search, others search only by business name, and no state or federal registry verifies that two matching names belong to the same individual. This guide explains what a person-name search returns, which states can answer it, how Cobalt Intelligence's Secretary of State API runs it and expands from a hit, and which confirmation rules an underwriting or fraud review lead must own before a match changes a decision.

What Does a Person-Name Search of Secretary of State Records Actually Return?

Which names appear on a state business record?

A state business record carries a small set of people. Delaware law, for example, requires every entity to maintain a registered agent in the state, and Delaware's corporate annual report lists the names and addresses of all directors and of the officer who signs it.^[1] Whether LLC members or managers appear at all depends on the state's forms.

Cobalt's help center separates the two roles its results carry: the agent is the registered agent for service of process, and officers are the executives or key people listed in filings when the state makes them available.^[2] Those names are public by design; Minnesota tells filers on its search page that information provided when filing a business entity is public data that may be viewable online, including all individual names and addresses.^[3]

A person-name search is therefore a search of these listed roles: the people a state chose to record and index, and nobody else.

Why is a hit a name match rather than an identity match?

A filing office records a name string, not a verified person. There is no date of birth or government identifier, and no standard for checking that the "J. Rivera" on one filing is the "Jose Rivera" on another. Cobalt's guidance for its own officer data is direct: states follow no universal identity-vetting standard, so officer records are public registry information rather than validated identity proof, and beneficial ownership data is generally not in these registries at all.^[4]

A last-name search in a large state therefore mixes unrelated people, and a first-and-last-name search still cannot separate two people who share both.

What does the reverse search not include?

Owners who never appear on a filing cannot be found by name. Delaware's LLC statute requires a certificate of formation to set forth the company name and the registered office and agent, plus any other matters the members choose to include, and member names are not on that list.^[5] Delaware's own FAQ draws the line:

Current officers and directors for Delaware corporations can be found on the most recent annual report. Alternative entities are not required to list members and/or managers.^[1]

There is also no federal owner index to fall back on. On August 11, 2026, FinCEN issued a final rule, effective August 14, 2026, making permanent the exemption of U.S. companies from beneficial ownership information reporting.^[6] It finalized the March 26, 2025 interim final rule that had narrowed the definition of a reporting company to entities formed under foreign law and registered to do business in a U.S. state or Tribal jurisdiction.^[7] A lender is left with state records, and state records list roles, not ownership.

Which States Let You Search Business Filings by an Officer or Owner Name?

What do supporting states expose?

Some states index people's names and let the public search them. Louisiana's commercial search has an "Officer Name or Agent Name" search type with first-name and last-name fields, and its hints say to use the full first and last name, or the last name and at least a first initial, to limit results.^[8] Alabama's records system lists a combined officer, agent, or incorporator search as one of its business entity search options, next to entity name and entity number.^[9]

Each indexes something slightly different: Louisiana combines officers and agents in one search, and Alabama adds the incorporator. A hit means the name appears in one of those roles on a filing in that state, nothing more.

What do non-supporting states do instead?

Other states index only the entity on their public search forms. Delaware's free web search takes an entity name or file number and returns the entity name, file number, formation date, and registered agent details, without entity status.^[1] New Jersey's Division of Revenue page is a business entity name search, run by name, keyword, or entity ID.^[10] Minnesota's search takes a business name or a file number even though the filed data is public.^[3]

Without a person index on the form, a manual reviewer reads filings one entity at a time.

What does Cobalt publish about state support?

Cobalt's help center answers "Yes, in some states": person or owner name lookups are supported wherever the Secretary of State makes that data available.^[11] The help center also links a downloadable spreadsheet of the fields each state returns, such as registered agent or officer information.^[12] That spreadsheet gives a broader answer on person search: it marks searchByPerson for 50 of the 52 jurisdictions it lists, all 50 states, leaving the District of Columbia and Puerto Rico unmarked.^[13] It does not say which marked states are answered from the state's own person index and which from the database fallback described below, and it marks Delaware, New Jersey, and Minnesota, whose public forms above search by business name or entity number.

A lending-software prospect asked Cobalt whether, given an owner's name, it could find all the LLCs registered under that person, and whether search by individual is limited to about 10 or 12 states or reaches more than 30. The spreadsheet is the closest published answer, and the pilot below turns it into a tested one.

A related number measures something else. Cobalt's own measurement on September 11, 2026 searched three large national companies by name against its live API in all 50 states and the District of Columbia: 153 probes, each with a 180-second ceiling. It covered one day and three well-formed names, so it shows what a state can return rather than what it never returns, and it is not a service expectation. Officer records came back in 32 jurisdictions on at least one probe and in no probe for the other 19. That measures whether a business-name lookup returns officers, not whether a state accepts a person-name query.

How Do Lenders Run a Person-Name Search Today Without an API?

What does the manual portal route cost in coverage?

The manual route is the state portals themselves, each with its own vocabulary, match rules, and friction. Alabama opens each search option in a new browser window.^[9] Louisiana's search sits behind reCAPTCHA.^[8]

The coverage cost is not the minutes per search but that the process rarely records the negative case. "Not found in Delaware" and "Delaware cannot be searched this way" can look identical in a review note, and they mean different things for the file.

What do aggregators and KYB platforms add?

Know-your-business platforms and public-records aggregators can save the portal work. Where one answers from its own index of state filings, that index is only as current as its last refresh, so a miss can mean the person is not there or that the index has not caught up. One prospect told Cobalt that its operations team trusts a hit and manually investigates a miss.

For any indexed source, a hit is a lead to verify against the state, and a miss is a prompt to check the state directly, not a clean result.

Where do UCC and court indexes fit?

Court dockets are indexed by party name and UCC filings by debtor name. Neither is a business-entity record, but both can link a person to obligations and entities a business-registry search cannot see. The workflow for searching court records by a business officer or owner covers name normalization and identity confirmation on that side.

None of these routes replaces the state registry, which is where the name was filed and the source an aggregator's index is built from. What an API changes is not the source but the process: the search, the fallback when a state cannot answer, and the record of what each state could and could not say become one repeatable call instead of a browser session.

How Does the Cobalt SOS API Search by a Person's Name?

Which parameters start a person search?

Cobalt's public API reference describes its Secretary of State search as a lookup by business name, entity ID, or a person's name, with a state parameter also required. A person search sends searchByPersonFirstName, searchByPersonLastName, or both, and the state can be a lowerCamelCase name or an abbreviation.^[14] The help center refers to the person route as the searchByPerson parameter and notes that an address cannot start a search; street, city, and ZIP act only as filters on results when the state returns those fields.^[15]

liveData defaults to true, which requests live data from the state rather than Cobalt's cache.^[14] Screenshots of the state page can be included with a lookup and show the timestamp and source URL.^[16] When a state takes longer than about 20 seconds, Cobalt returns an Incomplete status with a retryId to poll, or posts the finished result to a callbackUrl you supplied.^[17]

What happens in a state that does not support it?

The API does not silently return an empty list. When a person search is attempted in a state that does not support it, Cobalt attempts a search through its own database, and if nothing is found it returns the message "No business found in database. This state does not support search by person."^[11] A result in such a state therefore comes from Cobalt's database rather than a live person search of the state.

That message is the most useful line in the workflow, because it separates the two negative cases the manual process merges. An empty result where the state supports the search says the state returned no entity under that name; the fallback message says the state could not be asked and Cobalt's database had nothing either. Store them as different outcomes: the first is evidence about the person, the second is evidence about coverage.

Three more documented outcomes must not be logged as a live hit or a clean miss:^[14]

• Cached result on a live request. With liveData true, the API can return results plus a top-level message, sent only when recent data exists and the live lookup failed or the state was down for maintenance. They are Cobalt's recent data, not a live read.

• No exact match. The no-match message points to alternativeResults, a list that may be empty and whose entries can carry personName and personTitle. Each entry is a candidate to review, not a hit.

• Failed. An error, or a state down for maintenance, can instead return status Failed, with or without results from Cobalt's database. It is neither a hit nor a miss: rerun later and treat any database results as leads.

What does the response and your record look like?

The example below is illustrative: a lender-owned record wrapping one person-name search. Inside matches, the API fields use the flat result names in Cobalt's public API reference; roleOfSearchedName, identityConfirmed, and identityEvidence are fields the lender adds, and every value is a placeholder.^[14]

{
  "personSearchRecord": "psr-2026-000412",
  "query": {
    "searchByPersonFirstName": "ALEX",
    "searchByPersonLastName": "SAMPLE",
    "state": "louisiana",
    "liveData": true
  },
  "providerStatus": "Complete",
  "providerMessage": null,
  "stateSupportsPersonSearch": true,
  "matches": [
    {
      "title": "SAMPLE HOLDINGS LLC",
      "sosId": "00000000K",
      "status": "ACTIVE",
      "normalizedStatus": "Active",
      "filingDate": "2024-02-09",
      "entityType": "Limited Liability Company",
      "stateOfSosRegistration": "LA",
      "agentName": "ALEX SAMPLE",
      "officers": [
        { "name": "ALEX SAMPLE", "title": "MANAGER" }
      ],
      "physicalAddressCity": "BATON ROUGE",
      "physicalAddressState": "LA",
      "roleOfSearchedName": "officer_and_agent",
      "identityConfirmed": false,
      "identityEvidence": []
    }
  ],
  "reviewerDisposition": null
}

The wrapper fields and the last three fields in each match are yours, not Cobalt's: roleOfSearchedName records the role the name held on the record, identityConfirmed stays false until a second identifier ties the record to the applicant, and stateSupportsPersonSearch records which negative case applies when matches is empty. providerMessage stays null when Cobalt sends no message and stores any message it does send verbatim, including the fallback.

How Do You Cover Many States for One Person?

When does Full Verification's person search apply?

When you do not know where to look, Cobalt's Full Verification request fans one search across all 50 states and the District of Columbia and returns the registrations found in one consolidated response.^[18] Cobalt's public API reference documents the person route: initVerification requires either a businessName or a personsName, which takes a first name, a last name, or both. It returns a searchGuid for checking progress, and with a callback URL it sends the results once every available state has run.^[19] The Full Verification API guide covers the three-step flow and the callback pattern; because the slowest state sets the pace, run it in the background rather than as a blocking step.

Record what each state returned, as you would for single-state searches, and test a personsName request with a name you can verify before building it into a production path.

When does findRelatedBusinesses expand from a hit?

Once one entity is confirmed, Cobalt's findRelatedBusinesses parameter asks what else the person is on. The API reference describes it: added to an SOS search, it extracts the agent and officer names from the result, searches Cobalt's full database across all states for other entities where those names appear, and returns them in a relatedBusinesses field.^[14] The Find Related Businesses guide for CTOs adds the detail: results split into byOfficer and byAgent lists, each entry carries a true or false addressMatch indicator against the original result's address, matching runs two passes, exact and then normalized with middle initials and suffixes removed, and corporations listed as registered agents are filtered out so a national agent service does not link unrelated companies.

Two properties matter for a person-driven workflow. First, the expansion queries Cobalt's own database rather than the live state sites, so it adds one to two seconds at the top end and reflects what Cobalt has already collected rather than a fresh pull from every state. Second, it links entities through shared people, not through corporate parent-subsidiary structure, because a name is the join. Cobalt's help center gives one instruction for agent-based links that applies to every related-business result:

Use as corroboration, not sole proof.^[20]

How should the three calls be sequenced?

The order that produces the cleanest evidence is person search first, expansion second, fan-out last.

1. Run the single-state person search in each state where the applicant claims to operate and store the result or the fallback message for each.

2. For each hit that a second identifier confirms, rerun the entity with findRelatedBusinesses set to true, and store the byOfficer and byAgent lists with their address match flags. The API reference lists sosId as a search input,^[14] but the field spreadsheet marks searchBySosId only for Florida and Mississippi,^[13] so rerun by sosId only in a state where you have confirmed ID search works, and by business name elsewhere.

3. When the application names no state, or the confirmed hits suggest formations elsewhere, start a Full Verification with the person's name and let it run in the background while the rest of the file proceeds.

How Should Underwriting Treat a Person-Name Match?

What confirms that two records are the same person?

A name is never enough, so the rule set needs a second identifier before any match is treated as the applicant. The strongest confirmations available inside the records are an address that matches the application or a confirmed entity, a registered agent shared with a confirmed entity, an officer title consistent with the applicant's stated role, and a formation date consistent with the applicant's history.

Suffixes deserve their own rule. The normalized pass in Find Related Businesses strips middle initials and suffixes such as Jr., Sr., II, and III down to first and last name, so a Jr. and a Sr. who share a first and last name reduce to the same string. That is right for recall and wrong for a father and son who run separate companies at the same address. When a suffix appears on either record, route the match to review rather than confirming it automatically.

Which patterns deserve a review queue?

Once identity is confirmed, the pattern across the person's entities is the signal. These patterns deserve a named queue:

• Cluster of recent formations. Several entities under the confirmed name with filing dates inside the last 12 months, especially across states, before any has an operating history.

• Prior dissolved entities. Inactive, dissolved, or revoked statuses under the same name, which the normalizedStatus field lets you count without a per-state status table.

• Address divergence. Related entities where the address match indicator is false and the states differ, which separates a holding structure at one location from unrelated activity.

• Agent-only links. Entities that appear only in the byAgent list, where the person serves as registered agent but holds no listed office, which is a weak link on its own.

• Undisclosed entities. Confirmed entities that the applicant did not list on the application, which is a disclosure question before it is a fraud question.

• Coverage gaps in the file. States where the fallback message was returned, so that a reviewer can see which parts of the map were never searchable.

The queue names are the lender's. Cobalt returns the statuses, dates, roles, and address flags; the thresholds and the routing belong to the underwriting policy.

What must the rule engine never assume?

Three assumptions break person-name workflows. A name match is not an identity match, so no rule should decline on a name alone. An empty result is not a clean result, because the person may hold interests in states with no person index or in entities that never list members. And the data source does not make the decision. Cobalt returns registry data and normalized fields; the lender builds the rules, sets the thresholds, and owns the outcome.

What Limits Must an Operator Plan Around?

Which coverage limits are documented?

Person-name support depends on the state, and neither the help center's "some states" nor the spreadsheet's 50 marks tells you whether a given name will return results in a given state.^[13] Officer records depend on the state too: Delaware returned none on any of its three probes in Cobalt's September 11, 2026 measurement, and the spreadsheet does not mark officers for Delaware. Cobalt's help center also notes that some states, especially Delaware, expose only the registered agent's address, so an address in a Delaware result may be the agent's office rather than the company's location.^[21]

Nor does Cobalt document that a person search returns every match, which was the lending-software prospect's first question. Its help center says that when a state lists hundreds of results, Cobalt returns structured details for only a top slice, typically about 10 businesses, and without an address only what appears immediately after the name search.^[22] The API reference applies the street, city, and zip filters only to the top 10 results of a business-name searchQuery.^[14] Neither source says whether person searches share that limit, so treat a common-surname result as a partial list until Cobalt confirms otherwise.

Which timing and evidence limits apply?

Timing follows the state. Cobalt's help center puts cached lookups at one to three seconds, live lookups in fast states at roughly 7 to 15 seconds, and slower states at up to two minutes.^[23] Of the 153 probes in Cobalt's September 11, 2026 measurement, 110 returned a live record, 3 returned a cached record while Nevada's site was down for maintenance, 19 completed with no exact match, and 21 did not finish inside the 180-second ceiling. The 110 live records took 1.51 to 170.27 seconds, with a median of 15.01 seconds. Those were business-name searches, but the lesson carries: multi-state person searches need the retryId or callback pattern rather than a blocking request.

The API reference describes the screenshot link as short-lived and not yet available in all states, so check the spreadsheet for your states and download each screenshot into your own system of record.^[14] Find Related Businesses launched in beta on February 25, 2026, and its behavior may change.

What should you ask Cobalt before rollout?

Three checks settle most of the design. Open the field spreadsheet and note which of your target states are marked for officer records and for person search.^[13] Run a person search in each target state with a name you can verify, and record which states return results and which return the fallback message. Then ask Cobalt how a marked state is answered, from the state's own index or from Cobalt's database, because that decides what a miss there says about the state record. Ask, too, whether person searches share the top-slice limit above.

How Do You Pilot a Person-Name Search in Two Weeks?

What should the test set include?

A pilot that proves the workflow needs names you already know the answers for. Pull 30 to 50 principals from funded and declined files, weighted toward the states that carry your volume, and include at least five with common surnames, five with suffixes, and five you know hold entities in more than one state. Run the single-state person search for each name in each claimed state, then the expansion on confirmed hits, then Full Verification on the multi-state subset.

What should the evidence record store?

Store the query, the state, the provider status and message, the raw matches, the role of the searched name on each match, the second identifier used to confirm identity, the related-business lists with their address flags, and the reviewer's disposition. Keep provider fields and lender-derived fields in separate layers so a reviewer can tell what the state said from what your rule concluded. The Top 34 questions about the Secretary of State API cover the request and response mechanics, and Cobalt's earlier note on officer information availability by state explains why the officers array is present for some records and absent for others.

What decision does the pilot produce?

The pilot answers three questions with numbers: in which of your states a person search returns results, what share of hits a second identifier confirms, and how often the expansion surfaces an entity the applicant did not disclose. Those three numbers decide whether person-name search becomes a standard intake step, a review-only tool, or a check reserved for specific states. To map the three calls and the evidence record into your intake and review flow, schedule a workflow review with Cobalt.