Executive Summary: Broker-submitted applications often reach alternative lending funders as files rather than form entries, so no one selects the legal entity at intake and the backend inherits whatever the broker typed. This guide shows underwriting operations and integration leads how to build Secretary of State verification into that intake: which parsed fields can drive a lookup, which state to search, how to run the request asynchronously, how to resolve matches with rules instead of a dropdown, and what the returned record should trigger. Cobalt supplies the state record; the funder owns the thresholds and the decision.
Why Is a Broker-Submitted Application Harder to Verify Than a Portal Application?
What arrives in a broker packet, and who typed it?
A broker packet is a bundle of files: a signed application plus bank statements, and deBanked reported in 2023 that the industry treats the most recent four months of statements as a baseline.[1] A January 2026 press release carried by deBanked describes broker workloads of fifty or more submissions a day, sent to funders by portal, email, or API, however each funder requires.[2]
The name, address, state, and EIN on the application were typed by the broker or copied from the merchant's paperwork, so the parser receives strings, not identifiers. The broker is also a distinct party: Virginia, for example, requires every sales-based financing provider and sales-based financing broker to register with its State Corporation Commission.[3]
Why does the missing form remove the selection step?
In a portal, the person typing the business name picks from candidate entities before any record is pulled, the design the Business Name Autocomplete for Lenders guide covers. Cobalt's public API reference describes the suggest endpoint behind Business Search Suggestions in those terms: a partial name as typed, a short list for the interface to render, and an sosId per suggestion for the full search.[4] A parsed file already holds the whole name and nobody is present to pick.
Without a form, the selection step moves rather than disappears: the backend selects the entity with rules, a reviewer selects it from a queue, or the file is funded against an unselected name.
What does the funder actually need from the state record?
The exact legal name first. UCC 9-503(a)(1), as published by Cornell's Legal Information Institute, sets the test for a registered organization:[5]
A financing statement sufficiently provides the name of the debtor: (1) except as otherwise provided in paragraph (3), if the debtor is a registered organization ... only if the financing statement provides the name that is stated to be the registered organization’s name on the public organic record ...
That record is the one most recently filed with or issued by the organization's jurisdiction of organization,[5] and a financing statement that fails the test is seriously misleading unless a search under the correct name, using the filing office's standard search logic, would still find it.[6] A funder that files UCC-1s against merchants needs the state's spelling, not the broker's.
Then status, the filing date that anchors time in business, and the agent, addresses, and officers where the state publishes them, all fields Cobalt's help center lists for an SOS search.[7]
Which Fields From the Parsed File Can Drive a Secretary of State Lookup?
Can the EIN find the state record?
No. Cobalt's help center says Secretary of State registries generally do not expose EINs, Florida is the only state that publishes them, and an EIN is used only for TIN verification against IRS records, which returns a match result without state registration detail.[8] Look up the state record first, then run the TIN check on the legal name the state returned, because Cobalt sends the business name to the IRS exactly as provided.[9] Treat the result as a data-quality check that may prompt fixing an entry or requesting a W-9, and ask compliance about its permitted uses.
When should the file's entity number become a sosId search?
Cobalt's sosId is the official registration number assigned by the state, unique within that jurisdiction.[10] Cobalt's sources disagree on where searching by it works. The public API reference documents sosId as a general search input,[11] and a help-center answer on batch uploads says a state plus registration ID scopes the lookup to that record without looking for similar entities.[12] Cobalt's Fields Available by State spreadsheet, however, marks its searchBySosId row for only Florida and Mississippi.[13]
So search by sosId plus state only in a state where the funder has confirmed ID search works, such as one the spreadsheet marks, and only when the parser read the number reliably from formation documents or a good-standing certificate in the packet. Compare the returned legal name with the application before accepting it, and if the number returns nothing, fall back to a name search. Elsewhere, search the cleaned name and check the returned sosId against the number.
How should the backend clean the broker's business name?
Cobalt normalizes every query, stripping invisible characters, converting smart quotes and dashes, collapsing whitespace, and lowercasing. When a search finds nothing and abbreviations seem involved, it may rerun "First Natl Bank" as "FIRST NATIONAL BANK", possibly at a lower confidenceLevel than an exact match.[14] Its waterfall tries an exact match, strips punctuation and suffixes, and returns scored alternatives.[15]
Funder-side cleanup still matters. Cobalt's guidance for tight states is to strip location add-ons, punctuation, and suffixes, then filter alternatives by city or ZIP,[16] though its help center also advises keeping a suffix you trust.[17] A broker's typing is not that source, so "EXAMPLE DELI 2 INC - BRONX" loses the borough and suffix before the search, and the borough is sent as the city, with any ZIP the file has, as Cobalt's New York guidance advises.[18]
Cobalt's API reference calls street, city, and zip AND search parameters on the name search's top 10 results, checked against the physical, then mailing, then agent address.[11] Its help center, however, says address filters are no longer hard filters: results still return,[19] biased toward candidates that align on city and ZIP and marked addressMatch true or false.[20] Either way, the rules below read addressMatch before accepting a candidate.
How Should the Backend Decide Which State to Search?
What if the file names one state, or none?
When the application carries only the business address state, treat it as the broker's or merchant's assertion: search it first and record its source. A formation document in the packet outranks it. A business formed elsewhere can also be registered where it operates,[21] and a returned stateOfFormation that differs from the state searched gives the file its formation state.
When no usable state exists, or the name finds nothing above the review floor in the address state, Cobalt's multi-state endpoint checks all 50 states plus D.C. in one query.[22] Spend that call only on a sound name, meaning the packet gives the legal entity name, not only a DBA. A DBA-only application becomes a find-the-entity task instead, because widening the search does not repair a doubtful name. The How to Automate Secretary of State Business Lookups guide explains how data availability varies by state.
Where should formation state versus registration state be recorded?
As two fields. The registration state is the jurisdiction whose registry answered; the state of formation differs when the entity is foreign-registered. Cobalt's own measurement on September 11, 2026 searched three large national companies by name in the 50 states and D.C., 153 probes with a 180-second ceiling each. It covers one day and three well-formed names, shows what a state can return rather than what it never returns, and is not a service expectation. In it, the registration-state field came back from all 51 jurisdictions and the state-of-formation field from 37. One "state" column cannot tell a domestic entity from a foreign registration.
What Does an Asynchronous Backend Lookup Look Like Without a User Waiting?
Why does the request return Incomplete with a retryId?
When a state takes longer than about 20 seconds, Cobalt's help center says the API returns a status of Incomplete, an HTTP 202, and a retryId, and that the search is still processing, not failed.[23] The public API reference puts the threshold at longer than 30 seconds.[11] Either way, a 202 is a normal job state.
How long the wait runs is where Cobalt's published figures and its measurement differ. The help center says slower states such as Oregon and Delaware may require up to 5 minutes,[24] and its batch guidance says Delaware can take 1 to 2 minutes per record.[25] In the September 11 measurement, Delaware returned in 13 to 20 seconds and Oregon's one returned record in about 30, while 21 of the 153 probes did not finish inside 180 seconds. Neither is a guarantee. Design to the published five minutes and treat the measurement as one day's evidence that it is not the typical case: flag a job overdue only after that, and tune alerting on observed times.
When is callbackUrl the better fit than polling?
With polling, the backend saves the retryId and calls until the data is ready, resending screenshot=true with each retry if it wants the screenshot.[11] With a callbackUrl, Cobalt immediately returns a requestId and no results, then POSTs the finished results with the same requestId.[23] Cobalt recommends the callback for batch or high-volume use,[26] and its large-batch guidance adds that callbacks keep long-running states from tying up HTTP threads and that queues need backoff and idempotency.[27] The trigger that parsed the file should enqueue the lookup, persist the requestId, and move on. The Async Webhook Architecture for Long-Running Secretary of State Lookups guide covers callback signing, replay protection, and callbacks that never arrive.
How should the backend key each lookup to the parsed record?
Every lookup needs an identity that survives retries. Stripe's API documentation describes the standard pattern: an idempotency key lets a client safely repeat a request after a connection error without performing the operation twice.[28] Generate one per file, state, and mode, and refuse duplicates. The row below is an illustrative, customer-owned job record, not part of Cobalt's API schema.
{
"verificationJobId": "vj-2026-09-24-000418",
"intakeFileId": "broker-packet-77c1",
"brokerInputName": "EXAMPLE DELI 2 INC - BRONX",
"searchInput": {
"searchQuery": "example deli 2",
"state": "ny",
"city": "Bronx",
"liveData": false
},
"idempotencyKey": "broker-packet-77c1:sos:ny:cached:v1",
"providerRequestId": null,
"providerRetryId": null,
"phase": "cached-prescreen",
"decision": "pending",
"createdAt": "2026-09-24T13:05:00Z"
}The row stores the requestId from the first response. When the callback arrives with it, the handler finds the row, advances the phase, and sets the decision by the funder's rules, never by the payload alone.
How Should Cached and Live Modes Be Sequenced for File-Based Intake?
What does a cached pre-screen tell you, and what does it not?
Results are live by default; sending liveData=false forces cache-only behavior.[29] The cache holds tens of millions of records, roughly 70 to 80 percent of U.S. businesses, generally refreshed about monthly, so it may lag recent state updates.[30] Cached records do not auto-expire; each carries createdAt and updatedAt for judging freshness.[31]
For a broker file, the cached call answers one narrow question in 1 to 3 seconds, often under one, by Cobalt's published figures:[32] does a plausible record exist under this cleaned name in this state? Cobalt's help center says many clients check the cache first and fall back to live when nothing is found,[33] the pattern the Verification Waterfall Design guide covers.
When must the live lookup run?
Before any funding decision, and whenever a cached record's updatedAt is older than your policy allows. Cobalt retrieves live results directly from state websites or official state APIs,[34] and live lookups enable timestamped screenshots of the source page.[35] The cached pass sorts and pre-fills; the live pass verifies. Record which pass produced each field so nobody treats a cached value as a same-day observation.
What throughput limits matter at hundreds of files a day?
A parser that fans out every file on arrival invites throttling. Cobalt's endpoint returns HTTP 429 on extreme spikes, hundreds or thousands of requests in a second, while normal bursts of 5 to 50 or more are queued and processed steadily.[36] Give the queue a concurrency limit and a per-state time budget so slow-state files do not starve fast-state files, and meter submissions instead of releasing the morning's broker emails as one burst.
How Should the Backend Resolve Matches Without a Human Choosing From a List?
What do confidenceLevel and addressMatch let a rule do?
In Cobalt's public API reference, the result record includes a confidenceLevel and an addressMatch boolean, while entries in possibleAlternatives, or in alternativeResults when no exact name match exists, list a confidenceLevel plus street, city, ZIP, and state.[11] The help center puts scores on a 0.0 to 1.0 scale and describes alternatives as carrying addressMatch flags too,[37] but the reference's alternative entries do not list that field, so compare an alternative's city and ZIP with the file directly. The help center's example is "Boom City Brewing Company" returning "Boom City Brewing Company LLC" at 0.86 because the suffix was missing.[37]
Cobalt's typical guidance is 0.80 and above to auto-accept, 0.60 to 0.79 to review, and below 0.60 usually reject unless other signals such as address are strong.[38] Adding the flag, high confidence with addressMatch true auto-accepts, high confidence with addressMatch false needs city or ZIP verified, mid confidence with addressMatch true goes to review, and low confidence goes to reject or manual review.[39] Cobalt calls these rules of thumb; the funder owns the thresholds and logs the version used with each decision.
How should the alternatives list be used in a queue instead of a dropdown?
In a backend, the alternatives list becomes a review task, not a dropdown. Cobalt returns up to roughly ten alternatives, with fuller details such as entity status, filing number, and date only when the request includes an address.[40] Filter them by city or ZIP after they return, then apply the funder's own thresholds, as Cobalt's waterfall suggests.[16] The rules are short enough to write down:
• Single candidate, high confidence, addressMatch true. Accept, advance to the live pass, and attach the cached fields as pre-fill only.
• Single candidate, high confidence, addressMatch false or absent. Hold, verify city and ZIP against the bank statements or the application, then accept or route to review.
• Multiple candidates above the review floor. Open a review task with the alternatives, the raw and cleaned names, and the parsed address; do not auto-select the top score.
• Only candidates below the review floor. Compare their city and ZIP with the file and send a strong address match to review; otherwise run a multi-state search if the name is sound and the state doubtful, before opening a find-the-entity task.
• Entity number present in the packet. Search by sosId and state where ID search is confirmed for the state, otherwise by name, checking the returned sosId against the number; treat a returned name that differs from the application as a review item, not a decline.
• Cached miss with no alternatives. Run the live single-state search before concluding anything; a cache miss does not prove the entity does not exist at the state.[41]
Each rule writes its inputs and outcome to the job record, and reviewers see the same payload.
A resolved match is not an approval; the record should trigger the funder's written policy. A status the state reports as dissolved, inactive, or not in good standing stops automatic processing for an exception review. A normalizedFilingDate that puts the business under the time-in-business floor sends the file to underwriting beside the application's stated start date; since Cobalt's help center says most states return the original registration or formation date, check stateOfFormation before reading that date as the business's age.[42] The same answer says New Jersey and Delaware do not return registration dates and Delaware omits status fields,[42] and the spreadsheet leaves normalizedFilingDate unmarked for both states and normalizedStatus unmarked for Delaware.[13] Cobalt's September 11 measurement returned a filing date in both states; two Delaware records carried the status "Franchise tax is in good standing", normalized to Active, and the third normalized to "No status found", so a Delaware Active can reflect franchise-tax standing. Write both rules to send a missing filing date, or a missing or unrecognized status, to review instead of passing it. An officer list that omits the guarantor opens a review task, not a decline, and an empty list is missing data, not a mismatch: in the September 11 measurement, 32 of 51 jurisdictions returned officers on at least one probe and 19 did not. The Dependency-Aware Pre-Screening Waterfall guide orders the checks that depend on the resolved entity.
What should happen on no results?
Treat it as a signal, not a verdict: Cobalt's guidance is that if a manual search also fails, the supplied name or registration may be inaccurate or unregistered.[43] Keep outages apart. Cobalt keeps a large cache as a fallback when a state site is slow or down,[44] and its status reference lists a partial success that returns recent cached data when a live search fails.[45] The API reference documents two Failed responses with status code 500, one carrying results from Cobalt's database and one carrying none, each with an error or maintenance message.[11] So read the optional top-level message and check for records before treating any response as a clean result or a clean failure. Records that arrive with such a message are unverified database matches, not a live verification, and none of these responses is a no-result. A true no-result opens a task with the raw and cleaned names, the state tried, and the address, so a person can find the entity or ask the broker for formation documents.
What Should the Loan File Keep From Each Lookup?
Which fields belong in the loan file, and how are the names kept apart?
The state record's legal name, registration state, status, filing dates, addresses, registered agent, officers when available, and the timestamped screenshot with its source URL.[7] The screenshot needs screenshot=true; the API reference says it is not yet available in all states,[11] the help center says it is available from every state,[46] and the spreadsheet marks screenshotUrl for all 52 jurisdictions it lists,[13] so check your states there before requiring it. Document links are time-limited[47] and the screenshot is a short-lived URL,[11] so download each artifact on receipt and store it with the job record and its requestId.
Cobalt's help center says the response distinguishes the legal business name, any assumed or DBA names, and a "Search Input Hit" field showing the string that triggered the match.[48] In the API reference, assumed names arrive in an assumedBusinessNames array, and a searchResultTitle field appears when the state's search results list a different name from the details page, as with a DBA.[11] DBA data comes back only where a state publishes it,[49] and a fictitious name can outrank the actual entity on raw string similarity.[50] Cobalt's batch guidance is to keep the validated legal name actually used in its own column, apart from the raw input.[51] The file therefore keeps three names: the broker's input, the search string sent, and the state's registered name, which contracts and UCC filings use for the 9-503 reason quoted above.
What should the log record?
Enough to reconstruct the decision without reopening the packet. OWASP's logging cheat sheet says logs must record when, where, who, and what for each event.[52] Here that means the job ID, phase, request and retry identifiers, idempotency key, rule version, thresholds in force, outcome, and any reviewer. OWASP also lists access tokens, bank account data, and sensitive personal data among what should usually be removed or masked, so the API key, bank statements, application PDF, and guarantor details stay out of the logs.
Where Does Cobalt Fit in a No-Form Workflow, and What Stays With the Funder?
The lookups above do not require a direct integration, and the options differ in who retypes the name:
1. By hand. An underwriter retypes the name from the broker's PDF into the state portal, the step that introduces the spelling the state will not match.
2. Batch upload. Cobalt's tool needs no integration and returns a downloadable CSV with structured results, including entity data and screenshots.[53]
3. A lending platform's embedded lookups. Limited to the checks the platform has built in.
4. Secondary-source business databases. Different in origin: Cobalt says it never purchases or resells aggregator data.[34]
5. A direct API call. The option that fits a trigger, because the trigger is already code.
Which Cobalt calls apply to a no-form workflow?
The Secretary of State search is one GET request to the v1 search endpoint. It takes a searchQuery, an sosId, or a person's name, plus a state, with optional liveData, screenshot, callbackUrl, retryId, and test parameters.[11] The help center says person search works in some states,[54] while the spreadsheet marks it for 50 of its 52 jurisdictions, all but D.C. and Puerto Rico.[13] Cobalt's platform pattern is to call the API when a profile is created or updated and store the payload plus the screenshot URL for audit, with webhooks recommended for slow states.[55] Here, "profile created" means "packet parsed": the trigger cleans the name, picks the state and mode, keys the job, sends the request with a callbackUrl, and stores the requestId; the callback handler writes the payload, runs the rules, and advances the file or opens a review task.
Which Cobalt features do not apply, and what stays with the funder?
Business Search Suggestions stays at the form, for the reason given at the start. Cobalt is a data source, not a decisioning engine: it returns the record, confidence score, alternatives, and artifacts, and the funder writes the thresholds, review routing, and decline policy. The limits carry into production: officers only where a state publishes them, state-by-state response times, a cache that can lag, and expiring artifact links. This route is a proposed pattern, not a measured deployment; nothing here claims a backend workflow is faster or converts better than a form.
What should the integration review cover?
Cobalt's sandbox mode returns dummy responses for test parameters, so a team can validate requests and integration flow before live use.[56] Exercise the whole loop: a parsed file, a cached pre-screen, a live request that returns Incomplete, a callback, a review task, and a stored artifact. The Top 34 Questions About Secretary of State API hub answers the general integration questions. If your vendor-risk process requires it, request Cobalt's current security documentation during the review. To walk through this pattern against your own intake trigger, schedule a workflow and integration review with Cobalt.
.jpg){kind=small}
.png)