Business Name Autocomplete for Lenders: Select an Entity Before You Search Its SOS Record

Executive Summary: Business name autocomplete is not an address-form convenience. In a lending application, it is the control that determines which legal entity every later status, fraud, credit, and compliance check will examine. Cobalt Business Search Suggestions lets an applicant or operator choose a candidate, then sends that candidate's SOS ID and state to a separate Secretary of State search for the source record; the lender owns the match rules, fallbacks, and decision.

Why Is a Typed Business Name a Weak Starting Point for Verification?

What can one name field hide?

An applicant-facing name field can contain an abbreviated legal name, a trade name, an old name, or a name shared by more than one entity in different states. The IRS separates the legal entity name from the trade name on Form SS-4 and directs the legal name to match the charter or organizing document.^[1] Its EIN guidance similarly tells applicants to form the entity through the state before applying and to use the name shown on the registration documents.^[2] Its corporate-name-control guidance also illustrates why a name and EIN relationship cannot be treated as arbitrary text matching.^[3] The SBA likewise distinguishes a legal entity name, DBA, trademark, and domain name as different forms of business identity.^[4]

That distinction matters before a search begins, because a wrong answer here is not an interface annoyance. If the team accepts the first similar result, it connects the file to the wrong entity, and everything after that point inherits the error. The underwriter reads a registration that belongs to a different business. The fraud and credit controls run against a company the applicant does not operate. Funds can be advanced against a record that was never matched to the borrower. Months later, when someone asks which business was verified and on what basis, the answer has to be rebuilt from records that were never designed to hold it. A better workflow asks one narrower question first: which candidate should enter the verification path?

Keep the submitted name, choice, and result separate

Do not overwrite the application with the selected candidate and leave only one final name. Retain five related records:

• Submitted name. The exact value supplied by the applicant, broker, or upstream system.

• Candidate selection. The candidates shown, the entity selected, and who or what selected it.

• Source record. The full SOS request and result tied to the selected identifier and state.

• Exception. The reason an unclear, no-match, or conflicting case left the normal path.

• Decision. The lender's policy result, owner, and supporting evidence.

The differences among those records reveal whether a mismatch came from a DBA, an operator correction, a mapping rule, or a similarly named entity. One final business-name field hides that history.

A suggestion is a possible entity to investigate. It is not a verified entity, a legal conclusion, or an approval rule.

What Does Business Search Suggestions Actually Do?

When should a team call the endpoint?

Cobalt's documented Suggest endpoint is GET /v1/search/suggest. It accepts a searchQuery after at least three characters, can be narrowed with an optional two-letter state, and returns up to 10 candidates by default. The documented maximum is 25.^[5] The same public documentation describes what the endpoint searches: Cobalt's own business database, which is large but does not hold every business in every state, so a candidate list is a starting point rather than a coverage guarantee.^[5]

For a lender, that makes Suggest a useful entry point when the system has a name but not a confident SOS identifier. It does not change the need to retrieve and assess the full record.

Each candidate carries a name, an identifier, a state, and at most one address

The current documentation describes each candidate as a business name, an sosId, the state of registration, and at most one address. That address is selected by a fixed order, physical first, then mailing, then registered agent, and carries a type field naming which one it is. It is omitted when the record has no address on file, which the documentation notes is the case for some states and some records. The documented next step is to take the selected candidate's sosId and state into the normal SOS Search for the full record.^[5]

That handoff is the product boundary the implementation should preserve. A candidate helps the user choose an input for the source-record request. The SOS search is still where the workflow requests the fuller jurisdictional record.

What does it not do?

Cobalt's current documentation calls Suggest a name finder rather than a full record request. It explains that an empty result is normal and that the system should offer a fallback rather than assume the business does not exist.^[5] The coverage boundary is part of the reason an empty list happens: the documentation states that a business may be missing because it was very recently registered or because that state's coverage is still being filled.^[5]

It also lists two matching limits: DBA and trade-name matching is not available, and there is no typo tolerance in the suggestion step. Every typed word must match the start of a word in the registered name, and typo handling belongs to the full search that runs after the selection.^[5]

Do not use the response as proof of legal existence, beneficial ownership, eligibility, fraud, or creditworthiness. A candidate list cannot tell a lender that an entity is a shell, that the same principals are stacking applications across several files, or that a business identity was assembled rather than operated. Those questions belong to other controls. What the selection step does for a fraud team is narrower and still worth having: it fixes which entity all of those controls are aimed at, and it records that choice. Cobalt supplies data. The lender's policy, exception route, and downstream evidence determine what follows.

How Should a Lender Design the Candidate-Selection Step?

Which fields should a reviewer see before selecting?

Show the candidate name, state, returned sosId, and the returned address with its type when one is present. Some candidates arrive with no address, so the display must not treat a missing address as a defect in the candidate. Avoid a dropdown that shows only a name. A reviewer comparing two similar names needs enough context to make a deliberate selection, and the system needs enough context to create a traceable next request.

The display should make source context visible without announcing a conclusion. For example, a reviewer can see that two candidates share a name but differ by state or address, select one, and move to the full search. If neither is credible, the system should retain the submitted text and send the case to its exception path.

When should state narrowing be used?

If the application or integration already has a reliable state value, pass it to Suggest. It can reduce the candidate list without turning that state into a verification result. If the state is unavailable or disputed, do not manufacture one merely to make the menu shorter. Let the reviewer choose from the documented candidates or use the fallback workflow.

What should the request look like?

The request itself is short:

GET /v1/search/suggest?searchQuery=Acme%20Supply&state=OH&limit=10
x-api-key: YOUR_API_KEY

The request produces candidates, not the final SOS record. After a selection, pass the returned identifier and state to the full SOS Search according to the current API documentation.^[5]

What did the Florida demo actually show?

The demo makes the handoff concrete. The operator selects Florida, types pizza and pasta, inspects the candidates, and chooses Villa Pizza & Pasta Inc. in Boca Raton. The form copies available suggestion data into its own fields, then starts a separate Florida SOS search in the background. When that record returns, the form maps the filing date into its business start date field and displays the source screenshot while the applicant can continue completing the application.

The order matters more than the animation. Suggest supplies the candidate. The full SOS search supplies the record. Address and start-date prefill, the background call, and the form itself are choices made in the demonstration application, not a ready-made interface included with the endpoint. Cobalt supplies the two endpoints; the lender builds, owns, and logs the experience around them.^[5]

A same-name collision shows the underwriting payoff

In another Cobalt demonstration, a national query for ff pizza returned same-name LLC candidates in Illinois and Pennsylvania. If the application belongs to the Pennsylvania entity but the interface silently chooses the first Illinois result, the full search can work exactly as designed and still return the wrong company's status, filing date, agents, and officers. Every later shell-company, stacking, and credit check then starts from the wrong entity.

The control is simple: show state and address context, require or justify the selection, preserve the candidates that were not chosen, and compare the full record with the application. Suggest does not detect fraud. It prevents a name-resolution shortcut from aiming the lender's fraud controls at the wrong business.

After a Candidate Is Chosen, the Evidence Path Starts

Which evidence should move forward?

Keep the submitted name, selected candidate, returned SOS ID, returned state, selection time, and full SOS search result as related evidence. Do not overwrite the submitted name with the candidate name. The difference can matter when an application contains a DBA, an incomplete name, or a similar but unrelated entity.

The federal customer identification program rule for banks requires risk-based verification procedures and lists documents that show the existence of an entity, such as certified articles of incorporation or a government-issued business license.^[6] This is a bank rule, not a universal checklist for every alternative lender. The operational lesson is narrower: identify which source evidence supports a given workflow step and retain enough detail for someone else to understand it.

What does the underwriter get after the handoff?

The selected identifier should drive the record request, but it should not silently decide the file. The separate SOS search is where underwriting evidence appears. The demo shows a filing date and source screenshot. A full response can also return registration status and other fields available from that jurisdiction, including registered-agent or officer data. Field availability varies, so an integration should never make every downstream field mandatory or treat a missing field as a negative finding. Cobalt's Secretary of State API fields reference explains the field-level distinctions.^[7]

Formation or filing date can inform a time-in-business review, but it is not proof that operations began on that date. Status can trigger a lender-owned review rule, but autocomplete did not establish the status. In the demo, liveData=true and a screenshot request belong to the full search, not the suggestion call. Retain the search mode, retrieval time, source result, and screenshot with the decision record.

Where do customer rules begin?

Customer rules begin after data is returned. The lender decides whether a result requires manual review, an evidence request, an official state-portal check, or another verification source. The data source should not be represented as a decision engine.

How Should No-Match and Similar-Name Cases Be Routed?

Why is a no-match result not a rejection signal?

Suggest searches a database for candidate names. A zero-candidate result is an absence of suggestions, not a finding that the business is nonexistent. Cobalt's public documentation tells integrators to let the user proceed, for example by typing the name manually, when nothing comes back, because the database does not hold every business in every state.^[5]

Treating no match as an automatic decline would create a policy rule out of an interface result. Keep the next action explicit and attributable instead.

Which exception routes should be defined before launch?

• No candidates. Preserve the submitted name, allow manual entry or the normal search path, and record why the selection step was bypassed.

• Several plausible candidates. Require a reviewer to choose, request clarification, or route the file for a defined check rather than selecting the first result.

• Candidate differs from application data. Preserve both values and apply the lender's discrepancy rule.

• DBA or trade-name submission. Use a distinct name-resolution route. Current Suggest documentation says DBA and trade-name matching is not available.^[5]

• State conflict. Do not force a state filter. Escalate the conflict or run the appropriate broader search under documented policy.

• No expected entity record. A sole proprietor or another business type may not have the state entity record this step expects. Route the file to the alternate evidence your policy accepts instead of forcing a false match.

• Formation state differs from operating state. Do not assume the business address is the state of formation. Preserve both values and use the jurisdiction that belongs to the selected record.

• Source or integration failure. Make the failure visible to an owner. Do not turn it into a no-match result.

The goal is not a perfectly straight-through flow. It is a controlled flow that can handle ordinary ambiguity without hiding it.

Keep the Selection Traceable

Which events should be recorded?

Record six events against the application: suggestion requested, candidates returned, candidate selected, full SOS search requested, source record returned, and exception opened or closed. This is the same discipline used in a Secretary of State alert workflow: retain source context, normalized fields, interpretation, and disposition as distinct records.^[8]

submitted business name
  -> request suggestions after the minimum input threshold
  -> show candidate context without a verification label
  -> select candidate or open exception route
  -> request full SOS record with selected identifier and state
  -> apply lender-owned comparison and review policy
  -> retain source result, action, and owner

Label the selector as applicant-selected, operator-selected, or system-selected, and keep the raw candidate payload. Define who owns each exception before launch: the applicant for a correctable entry, underwriting for an identity conflict, or engineering for a source failure. No result should disappear into an ambiguous not found status.

Where the Selection Step Fits Against the Alternatives

Manual portal search and an internal build are the real alternatives

A team can send an unstructured name directly to a record search, ask staff to search state portals manually, or build an internal name-resolution layer. Each approach can work, but each moves the same control somewhere else:

• Raw name to record search. Fast to wire, but it removes the selection event and leaves no record of which same-name entity the query resolved.

• Manual state-portal search. Keeps a person in the loop, but assumes the state is already known and leaves the candidates considered in reviewer notes.

• Internal name-resolution layer. Gives the team full control, along with responsibility for the candidate index, matching rules, refresh process, coverage gaps, trade names, and typos.

Teams that already hold a reliable SOS ID may not need Suggest. Teams that start with a business name need an explicit selection branch, whichever route supplies it.

How should Cobalt be introduced without a product jump?

The problem is not simply that a form field is inconvenient. It is that a typed name can enter an operational decision path without a visible bridge to the entity record the team intends to review. Cobalt Business Search Suggestions provides the candidate-selection API, while Cobalt SOS Search provides the separate record request. The lender owns the integration, the exception process, and every decision made from the returned data.

For teams evaluating broader entity workflows, Cobalt's guide to automating Secretary of State business lookups outlines where a source-record request fits in a higher-volume process.^[9]

What Should a Team Test Before Turning It On?

Which seven cases reveal the real design?

Test at least these seven routes before a production release:

• Ordinary legal-name case. Confirm that the selected candidate carries the expected ID and state into the full SOS search.

• Similar-name case. Confirm that the interface gives enough context to distinguish candidates and does not preselect one as verified.

• Trade-name case. Confirm that the workflow does not promise a DBA match and opens its defined fallback.

• No-candidate case. Confirm that the user can continue without a false absence conclusion.

• State-conflict case. Confirm that the team can route a disputed or missing state without silently inventing a filter.

• No-registration case. Confirm that a file can move to alternate evidence when no state entity record is expected.

• Formation-versus-operation case. Confirm that an operating address does not silently replace the selected entity's registration state.

Which measures are worth reviewing?

Do not use one clean demo as a match-rate claim. Current public documentation does not publish a Suggest match-rate percentage, and it states that the database does not contain every business in every state.^[5] Test the actual applicant mix and review the results by state and name type:

• Suggestion availability. What share of submitted names produces at least one candidate, and how does that change for legal names, DBAs, and recently formed entities?

• Selection quality. How often does a reviewer or later SOS result reverse the first selection?

• Friction. How often do applicants use manual entry, abandon the form, or require operator help after the suggestion step?

• Source completion. How often does the selected ID produce the expected full record, and which fields are absent by jurisdiction?

• Decision traceability. Can a reviewer reconstruct the submitted name, candidates shown, selector, full search mode, source timestamp, and final disposition?

These measures show whether the workflow is being used, where it breaks, and whether the selection step adds friction. They do not prove a credit, fraud, approval, or conversion outcome without a separate analysis.

How should a rollout be contained?

Start with an observable release slice, such as one intake route, one operating team, or one state-filtered use case. Validate the selected-candidate-to-SOS-search handoff and the exception queues before expanding the feature to every entry point. This is a product and operations check, not a performance promise.

Review the logs with the people who handle mismatches. Look for cases where a similar name was selected, a submitted trade name did not resolve, a state filter was wrong, or an operator bypassed the suggestion list. The review should improve labels, controls, and routes. It should not retroactively redefine a candidate response as proof that the final entity selection was correct.

What should the buying team bring to the demo?

Bring one ordinary application and the cases most likely to break the flow. That gives product, risk, and engineering a concrete way to review the candidate display, the full-search handoff, and the fallback rather than judging a polished happy path.

• Your intake path. Who types the name, who may select a candidate, and which fields can be prefilled?

• Your state and entity mix. Which jurisdictions, DBAs, sole proprietors, foreign registrations, and recently formed businesses appear most often?

• Your required evidence. Which status, filing-date, agent, officer, source-link, or screenshot fields feed policy or manual review?

• Your fallback. What happens when no candidate appears, the state conflicts, or the full search returns incomplete data?

• Your integration questions. Confirm authentication, request sequencing, asynchronous full-search handling, logging, current account eligibility, and commercial terms with Cobalt.

Read the current TypeAhead API documentation, then see the workflow in a Cobalt demo. Bring those normal and ugly cases so the conversation tests the feature against the way your team actually funds.