Executive Summary: This 1west manual verification case study is an operational teardown of how a high-volume small business financing marketplace moved Secretary of State checks off a human processing queue and into an automated business verification step inside its application flow.[1] The goal here is not to retell the story. It is to extract the before-state workflow, the integration change, and the after-state workflow into a repeatable playbook other lenders and brokers can copy.[2] One honest note up front on the numbers. Cobalt's published 1West case study reports a heavy reduction in manual verification work and a Secretary of State match rate above 90 percent, and this teardown keeps every concrete metric tied to what the case study and product documentation actually state.[1] The case study does not publish a single headline reduction percentage, so a lender repeating this playbook should measure its own before-and-after manual-touch rate. Results depend on each lender's workflow, file mix, and state coverage.
What did 1West's verification workflow look like before automation?
How was Secretary of State data checked manually?
Before automating, 1West checked Secretary of State data by hand.[1] A processing team opened individual state filing portals, searched the business name, and read back the registered entity record. State registration through a Secretary of State office is what makes a business a distinct legal entity, so that record is the anchor for verified ownership, address, and time in business.[4] Every file that needed a clean entity record needed a human to go find one.
The manual step did real underwriting work. It confirmed the business start date, matched the owner on the application to the owner on the state record, and checked that addresses lined up. Those are the first questions a junior underwriter asks, and a mismatch is an early fraud and incompleteness signal.[1]
Where did the manual queue break down at scale?
The problem was volume, not capability. 1West runs roughly 20,000 to 22,000 leads a month and over 5,000 full loan submissions through its platform, so a per-file manual lookup does not hold up.[1] Online lenders have absorbed a rising share of small business credit applications, which puts even more pressure on intake throughput.[6]
When you are clearing 20 or 30 files a month, manual incomplete resolution feels manageable. When you are clearing thousands of submissions a month, keeping incompletes to a minimum is what keeps the assembly line moving.
That observation, paraphrased from the dynamics described in Cobalt's 1West case study, is the core of the before-state pain. The manual queue produced predictable failure modes:
• Bottlenecks under load. The processing team got jammed and could not run the check on every file.[1]
• No real-time clearance. Manual lookups added minutes to hours per file, which delays submission to funding partners.[1]
• Data-entry error. Hand-keyed entity records introduce transcription mistakes, and even small name discrepancies break downstream lien and identity matching.[9]
• Incompletes and re-signs. A wrong start date can force the applicant to re-sign the application, restarting part of the flow.[1]
• Throughput tied to headcount. Scaling the check meant adding bodies, not adding capacity.[1]
The takeaway for any operations leader is that a manual SOS step does not fail loudly. It fails quietly by capping how many files clear per day.
Why is the Secretary of State check the right step to automate first?
What does SOS data verify in a lending file?
Secretary of State data verifies the identity backbone of a business application: legal name, registered ownership, business address, and time in business.[1] For a marketplace or broker, this is the cheapest high-value check in the stack, because it runs early on a name and state and gives a verified time-in-business date that downstream funders treat as a threshold input.
Time in business is a hard milestone in alternative lending. Crossing one, three, or five years can change which funders approve a file and at what rate.[1] Pulling that date from the primary state record, rather than relying only on applicant memory, is where the operational value compounds.
Why automate this before bank statements or credit?
Bank statement parsing and credit pulls are already served by mature specialist tools, so rebuilding them rarely pays off. The SOS check is different. It is a structured, state-by-state lookup that is tedious to do by hand and complex to build across all 50 states, which makes it the manual step worth replacing first.[1] Verified entity data also supports fair-lending and adverse-action discipline by grounding decisions in primary-source facts rather than unverified applicant input.[5][7]
What was the integration change that replaced the manual queue?
How long did the integration take?
The build was short. Per Cobalt's 1West case study, an engineer read the documentation and stood up the core integration in less than a week.[1] The reason the change works as a playbook is that it does not ask the team to rebuild underwriting. It replaces one manual lookup with one API call placed at the same point in the flow.
Before introducing a vendor, most teams weigh build-in-house against incumbent providers such as Wolters Kluwer or CSC for lien and entity data.[9] The build-in-house path stalls on the same wall 1West hit: integrating and maintaining all 50 state systems is a large, ongoing cost. The integration question is therefore not capability but friction, and a single primary-source SOS endpoint removes the per-state maintenance burden.
What does the API call look like in the flow?
The check runs as a single request once the application provides a business legal name and state. The marketplace fires it early, gets back the verified entity record, and writes the result into the file.
curl --location 'https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Corp&state=delaware&liveData=true' \
--header 'x-api-key: YOUR_API_KEY' \
--header 'Accept: application/json'The response returns the registered entity, including verified business start date, status, and address fields, which the platform uses to confirm ownership and time in business automatically.[3]
What does the after-state workflow do automatically?
Which manual decisions became automated rules?
The platform now runs the SOS check inside intake and applies logic that a human used to apply by hand. The clearest example is start-date handling. The system pulls the verified start date and takes the earlier of the applicant-entered date and the SOS date, which can push a borrower across a time-in-business threshold without a manual re-key or re-sign.[1]
Match coverage is strong but not absolute. Cobalt's 1West case study reports a successful SOS match more than 90 percent of the time, with misses concentrated in cases like a business operating in one state but incorporated in another.[1] Match-rate performance depends on name normalization and the correct state, which is why entity matching quality matters as much as raw coverage.[3]
How did this change throughput and the team's work?
The processing team stopped opening state portals file by file and got that bandwidth back for judgment work. Automating the check let 1West handle more applications without scaling headcount in lockstep, and roughly a quarter of customers now move through the platform end to end without speaking to anyone.[1] The operational gain is the disappearance of a manual queue, not a new decisioning engine.
How do the before and after workflows compare?
What changed step by step?
| Workflow dimension | Before: manual SOS verification | After: automated SOS verification |
|---|---|---|
| Who runs the check | Human processing team | API call inside intake |
| When it runs | After flagging, often batched | Early, on name plus state |
| Per-file time | Minutes to hours | Real time |
| Throughput limit | Headcount of the queue | API capacity |
| Start-date handling | Manual lookup, possible re-sign | Auto-pull, earlier-date rule applied |
| Error source | Hand-keyed transcription | Primary-source record |
| Coverage on misses | Re-search by hand | Match above 90 percent, exceptions flagged |
| Effect on incompletes | Spikes under load | Reduced and consistent |
What is the honest read on the metrics?
The verifiable claims are these: integration in under a week, SOS match above 90 percent, about 25 percent fully self-service customers, and a heavy reduction in manual verification labor.[1] The case study does not publish a single fixed reduction percentage, so a lender repeating this playbook should measure its own before-and-after manual-touch rate rather than assume a number.
What is the repeatable playbook other lenders can copy?
How should a team sequence the rollout?
The playbook is deliberately small. It moves one step, measures it, then expands.
1. Baseline the manual step. Count files per day, average minutes per SOS lookup, and current incomplete rate.
2. Place the call early. Trigger the SOS check as soon as legal name and state exist in the file.
3. Normalize the name and state first. Match quality depends on a clean legal name and the correct state of incorporation.[3]
4. Codify the human rules. Encode start-date logic, owner-match checks, and address-match checks as automated rules.
5. Route the misses. Send no-match and cross-state cases to a small exception queue instead of clearing them silently.
6. Store the raw record. Keep the primary-source response so a later reviewer can see what was verified.
7. Re-measure. Compare the new manual-touch rate against the baseline to get your own reduction figure.
Where does this sit in the full verification stack?
SOS verification is the identity anchor, not the whole file. It pairs with UCC lien discovery, TIN and EIN matching, court-record review, and bank and credit analysis to form a complete picture.[8] Entity data confirms the business exists and who owns it, then the other checks add debt, litigation, and cash-flow context.
What are the honest limits of this approach?
What does SOS automation not solve?
Cobalt is a primary-source data provider, not a decisioning engine, and the case study results reflect 1West's specific workflow rather than a guaranteed outcome.[2] Automating the SOS check does not read bank statements, score credit, or make the funding decision. It removes a manual lookup and returns verified entity facts.
Where do coverage and accuracy caveats apply?
Match rates are high but not universal, and cross-state incorporation, name variants, and state filing lag can produce misses.[1] The correct design treats a no-match as an exception to review, never as an automatic clear. Demand for fast small business credit keeps rising, which makes disciplined exception handling more important, not less.[6][10]
.jpg){kind=small}
.png)