Where Does the SOS Registration Check Fit in a Lender's KYB Stack?

Executive Summary: Most KYB stacks were assembled one vendor at a time. A sanctions screen was added because an examiner asked about it, a tax identification check was added after a fraud loss, bank data arrived with the application flow, and the Secretary of State lookup got wired in wherever there was room in the queue. The result works, in the sense that every check eventually runs. What it does not do is run in an order that makes each step cheaper and more accurate than it would be alone. Sequencing is the part of the stack nobody buys and everybody owns, and it is worth more than the marginal difference between two vendors on the same list.

Why does the order of KYB checks change the outcome and not just the runtime?

Because three of the checks in a standard stack take an input that only an earlier check can produce correctly.

A KYB stack is usually drawn as a set of parallel boxes: entity, tax identification, sanctions, liens, bank data. Drawn that way it looks like an ordering problem with no wrong answers, so teams optimize for latency and fire everything at once. That works until you look at what each box actually consumes. A lien search consumes the registered legal name. A sanctions screen consumes officer and agent names. A tax identification match consumes a legal name and a number that must agree with each other. Every one of those inputs comes off the state registration record, and every one of them degrades if you take it from the application form instead.

Supervisory expectations point the same direction without prescribing an order. Banks must maintain risk-based procedures for ongoing customer due diligence that include "understanding the nature and purpose of customer relationships for the purpose of developing a customer risk profile."^[1] A risk profile assembled from checks that each guessed at their own inputs is a profile of the application, not of the business.

The second reason is cost. Checks in a KYB stack differ in price by more than an order of magnitude, and they differ in how conclusively they can reject a file. Running the cheap, high-rejection check before the expensive, low-rejection one is not an optimization detail. It is most of the difference in cost per funded deal between two lenders using identical vendors.

• Existence questions are cheap and terminal. If the entity is not on file in the state where it claims to operate, nothing downstream matters.

• Identity questions are cheap and conditional. A tax identification mismatch usually means a data problem rather than a decline.

• Sanctions questions are cheap to run and expensive to get wrong. The asymmetry is legal rather than operational.

• Lien questions are moderate and interpretive. Their answer changes position, not eligibility.

• Bank and document work is the most expensive input in the stack. It is also the step that consumes applicant patience.

That ordering, from terminal and cheap to expensive and interpretive, is the whole argument. The market-level view of which tools fill each slot is covered in the KYB API comparison for lending risk assessment, and this article assumes the tools are already chosen.

What makes the Secretary of State check the anchor rather than one step among several?

It is the only check that establishes the entity exists as a legal person, and it is the source of the strings every later check needs.

Federal rules define the object of business due diligence by pointing at the state registry. A legal entity customer means "a corporation, limited liability company, or other entity that is created by the filing of a public document with a Secretary of State or similar office."^[2] The entity is constituted by the filing. Verifying the filing is therefore not one signal among five, it is the check that determines whether there is a business to run the other four against.

Four outputs from that step feed everything after it:

• The exact registered legal name. Not the trade name on the application, and not the name on the bank statement.

• The current registration status. Active, inactive, dissolved, or a state-specific variant with a normalized equivalent.

• The formation date. The input to any time-in-business rule, and the reason a very new entity behaves differently everywhere downstream.

• The officer, agent, and address set. The names your sanctions screen and your fraud rules will consume.

What a single entity lookup does and does not settle is broken down field by field in the sibling post on what an entity validation API validates. The comparison of providers occupying this slot is in the Secretary of State API guide.

Does the anchor position hold for very new entities?

Partly, and the exception is worth naming rather than papering over.

No API returns a record the state has not published. Oregon's Corporation Division estimates one to three business days to process online business registry filings.^[3] An entity formed on Monday can be legitimately absent from a Tuesday lookup, which means a no-result on a recently formed applicant is a timing fact rather than a fraud signal. For that population the sequence needs a documented hold-and-recheck path instead of a decline, which is worked through in the guide to verifying newly formed LLCs at onboarding.

How should the tax identification step consume what the SOS check produced?

By matching against the registered legal name rather than the applicant-supplied one, and by treating a mismatch as a routing decision.

The tax identification check answers a different question from the registration check. Registration proves a filing exists in a state. A tax identification match proves a number and a name agree in federal records. Those can disagree honestly. An entity registers under one legal name and obtains its employer identification number under an earlier or slightly different one, since the online application issues a number to whoever names a responsible party and can be used immediately for most business needs.^[4] The IRS matching service exists to catch exactly this class of disagreement, allowing filers to "validate TIN and name combinations prior to submission of the information return."^[5]

Sequencing matters here for a mechanical reason. If you run the tax identification check first, you match against whatever the applicant typed. If you run it after the registration lookup, you can match against the state's own string and, when that fails, retry with the applicant string and record which one succeeded. Two attempts with known provenance produce a usable answer. One attempt with unknown provenance produces a support ticket.

The mechanics of this check, the response codes, and the batch pattern for portfolios are owned by two existing articles: the EIN verification API lender guide and the walkthrough for bulk verifying ten thousand EINs via API. What belongs in a sequencing discussion is narrower: this step is second because it needs the first step's name, and its failure is usually a data condition rather than a decline.

Where does sanctions screening belong, and what does it need from the earlier steps?

Immediately after the entity and its people are known, and before any money movement is set up.

The screening step is unusual because its position is driven by legal exposure rather than by cost. Civil liability under the statute behind most sanctions programs does not require intent. A civil penalty may be imposed "in an amount not to exceed the greater of $250,000 or an amount that is twice the amount of the transaction that is the basis of the violation," while the criminal provision applies only to a person who "willfully commits" the underlying act.^[6] The civil maximum is inflation adjusted annually, standing at $377,700 for violations under that authority as of the adjustment published January 15, 2025.^[7] A screening step that runs late is a screening step that can produce a hit after you have already created an obligation.

There is an operational consequence to a hit that also argues for early placement. A U.S. person holding blocked property must file with the Office of Foreign Assets Control, and "reports shall be filed within 10 business days from the date that property becomes blocked."^[8] A clock measured in business days is easier to meet when the hit surfaces during underwriting than when it surfaces during funding.

What the screen consumes is the point. Screening the applicant business name alone tests one string. Screening the officer and registered agent names returned by the state record tests the people, which is where the exposure usually sits. That input does not exist before the registration lookup runs. The three-signal cross-check itself, including how the results are reconciled when they disagree, is documented in the existing article on the OFAC, EIN, and SOS triple verification pattern.

The practical test of a KYB sequence is what it produces on the file that gets declined. If a decline leaves behind only a vendor score, the sequence was built for throughput. If it leaves behind a dated record of which check failed and on what evidence, the sequence was built for review.

Why must the lien search wait for a confirmed registered legal name?

Because the statute governing lien filings ties the debtor name to the state registration record, and a search under the wrong name can return nothing while liens exist.

This is the strongest sequencing argument in the stack and the least discussed. A financing statement is sufficient only if it "provides the name of the debtor," names the secured party, and "indicates the collateral covered by the financing statement."^[9] For a registered organization, the required name is the one "stated to be the registered organization's name on the public organic record most recently filed with or issued or enacted by the registered organization's jurisdiction of organization."^[10] The public organic record is the state filing. The lien index is keyed to the same string the Secretary of State holds.

The rule about errors closes the loop. A financing statement that fails to provide the debtor name correctly "is seriously misleading," except where "a search of the records of the filing office under the debtor's correct name, using the filing office's standard search logic, if any, would disclose" it.^[11] Read from the searcher's side, that means the correct registered name is the query that the filing office's index is designed to answer. Search under a trade name or a slightly wrong suffix and a clean result is not evidence of an unencumbered borrower. It is evidence that you asked the index a question it was not built to answer.

That is also why the lien check is worth running as an extension of the registration call rather than as a separate integration keyed to an application field. A single request can carry the lien flag alongside the entity search:

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

The combined call keeps the debtor name and the search that depends on it in one place, with one request identifier tying them together.

When should bank data and document collection run, and why last?

Last, because they are the most expensive inputs in the stack and the only ones that spend applicant patience.

By the time the first four checks have run, the file has an entity, a status, a tax identification result, a screening result, and a lien picture. Everything expensive that follows is now being spent on a file that has already survived the checks capable of ending it. That is the entire economic argument for the order, and it holds for statement collection, document requests, manual review time, and any pass-through fees.

Pass-through fees make the point concrete. Most states charge nothing for a status lookup. Delaware charges $10 for a current status that can be printed, and $20 for a version adding the last five filings, franchise tax assessment, total authorized shares, and tax due, with neither option producing a certificate of good standing.^[12] Those are state fees passed through at cost by any provider. New Jersey status data is likewise restricted by statute with a fee attached. When a step in your sequence carries a state charge, its position in the order becomes a budget line rather than an engineering preference.

There is a second reason this step goes last, and it is behavioral rather than financial. Document requests and bank connection prompts are the points in an application where a legitimate borrower stalls and a fraudulent one adapts. Asking for them at the top of the funnel means asking every applicant, including the ones the state registry would have closed out in a second, and every unnecessary request adds a place for a good file to go cold. Asking for them at the bottom means the request lands on an applicant who has already cleared the checks that could have ended the file, which changes both the conversion arithmetic and the quality of the population you are spending review time on.

The freshness question that decides whether you run the cached or live version of the entity check first is treated separately in the comparison of real-time SOS data against cached registry data. For sequencing purposes the useful pattern is the cheap pass first: a cached lookup returns in under a second and is enough to reject an entity that does not exist anywhere, while a live lookup takes 10 to 180 seconds depending on the state and is what the funding decision should rest on.

How do you route failures between steps instead of stopping the file?

By deciding in advance which failures are terminal, which are conditional, and which are timing, and by writing that routing down before it becomes tribal knowledge.

Most stacks handle success well and handle ambiguity by escalating to a human, which is the same as having no routing. Four failure classes cover nearly all of it.

• No result from the registration lookup. Rarely a decline on its own. The realistic causes are name variation such as LLC against L.L.C., registration in a different state, a filing too recent to appear, or a name search where an entity identifier search would resolve. When the state of registration is genuinely unknown, an all-state search is the right instrument rather than fifty guesses.

• A moderate confidence match. Every result carries a confidence score from 0.0 to 1.0. Scores of 0.8 and above are commonly auto-accepted, 0.5 to 0.79 routed to review, and below 0.5 treated as a different entity. The response also carries up to ten close matches in an alternatives array, which is the review queue's actual working material.

• A slow state. Past roughly thirty seconds the response carries a retry identifier rather than results, and the integration either polls that identifier or supplies a callback URL. Oregon can take up to five minutes on a live lookup. This is a fixed property of the state system, so it belongs in the design rather than in an incident log.

• A tax identification mismatch after both name attempts. Conditional. Route to document collection rather than to decline, since the underlying cause is often a legitimate name change.

• A screening hit. Terminal for automation. It stops the sequence and starts a documented review, with the blocked-property reporting clock in mind.

The routing table is worth writing as a table rather than as policy prose, with one row per failure class naming the next action, the owner, and the maximum time a file may sit in that state. Without the time column the conditional classes quietly become terminal, since a file that waits for a document nobody chased is a decline that nobody recorded as one. Reviewing the table quarterly against what actually happened to files in each class is the cheapest audit in the stack, and it usually surfaces one class that operations has been resolving by habit in a way the written sequence never described.

Two limitations belong in the routing table honestly. Officer data availability varies by state, because the API returns what the state publishes and some states publish no officers, which means the sanctions step will have thinner input in those jurisdictions than in others. And screenshot URLs are valid for download for a limited window of three to thirty days, so any evidence step that stores the link rather than the image has stored something with an expiry date. Testing both conditions before signing is covered in the sibling checklist on testing an SOS API before buying.

Where does each check's evidence land in the audit file?

In a record tied to the decision date, with the source and the request identifier attached to each artifact, because the obligation being satisfied is procedural.

Covered institutions "are required to establish and maintain written procedures that are reasonably designed to identify and verify beneficial owners of legal entity customers."^[2] Reasonably designed procedures are demonstrated through retained artifacts rather than through a policy document. Lenders inside the scope of the small business lending rule under Regulation B carry separate collection and recordkeeping obligations on covered applications, with compliance dates extended by interim final rules issued June 25, 2024 and June 18, 2025.^[13] Vendor selection itself is examinable, since due diligence before entering a third-party relationship is "an important part of sound risk management" and its scope "should be commensurate with the level of risk and complexity of the third-party relationship."^[14] The agencies published a companion resource for smaller institutions in May 2024 organized around the same lifecycle stages.^[15]

Timestamped screenshots earn their place in the first row. When requested, the response returns a URL to a screenshot of the state page watermarked with the date and time of verification, with no vendor branding on the image. That is the artifact that stays true after the entity's status changes, which is precisely when someone will ask what you knew.

The honest closing observation is that no published benchmark tells you what fraud-catch rate this ordering buys, and any vendor quoting one across lenders is quoting a number from someone else's portfolio mix. What the sequence does produce is measurable inside your own book: the share of declines resolved before the expensive steps ran, the share of lien searches executed under a state-confirmed name rather than an applicant-supplied one, and the share of files where a screening hit arrived before rather than after an obligation existed. Those three numbers describe a KYB stack more accurately than the vendor list does, and unlike the vendor list, they are yours to change this quarter without a procurement cycle.