Is Manual Underwriting Dead? No, But Manual Verification Should Be

Every few years, underwriting gets declared dead. Credit scoring was supposed to kill it. Bank-statement analysis was supposed to kill it. Machine learning was supposed to kill it. Now AI gets the same headline.

But in small business lending, the obituary is wrong. Manual underwriting is not dead because small businesses are messy. A merchant can have irregular deposits, thin credit history, a new LLC, a confusing DBA, existing UCC filings, a recently changed address, or a signer whose relationship to the business is not obvious from the application.

The real question is narrower and more useful: should underwriters still be manually verifying the entity behind the application?

The answer is no. Manual entity verification should be retired from high-volume workflows. Underwriters should review risk, exceptions, and policy calls. They should not spend time navigating 50 state websites to confirm whether an LLC exists, whether it is active, when it was formed, and whether a screenshot got saved into the loan file.

Why Is Manual Underwriting Still Alive in Small Business Lending?

Manual underwriting survives because small business credit is not consumer credit with a different form. A consumer file usually has one person, one credit profile, and a fairly standardized identity structure. A business file can include the entity, owner, signer, DBA, tax ID, state registration, lien history, court history, and payment behavior.

The FDIC's 2024 Small Business Lending Survey is useful here because it separates automation rhetoric from actual adoption. Outside credit cards, automated lending remains uncommon among banks, and the FDIC reported that one in ten banks had a credit-scoring system that could partially or fully automate underwriting or decisioning for small business applications.¹ That is not proof that banks are behind. It is proof that small business credit does not reduce cleanly to one automated score.

What Does Manual Judgment Still Do Well?

Manual judgment is still valuable when the signal is ambiguous. An underwriter can distinguish a business that looks thin because it is young from a business that looks thin because the applicant is hiding risk. An underwriter can spot explanation quality, borrower behavior, industry context, and exception patterns that a rule engine may treat too rigidly.

The Federal Reserve's 2025 small business credit work also shows why speed matters in this market. Online and nonbank finance applicants often choose those providers because they expect faster funding or believe they are more likely to be approved.² Speed is a borrower expectation, but speed without risk control is just faster exposure.

Where Does Manual Work Stop Helping?

Manual work stops helping when the task is deterministic, repetitive, source-based, and auditable. Confirming whether an entity is active in a Secretary of State database is not a judgment problem. It is a data retrieval problem. Copying an officer name into a CRM is not a judgment problem. It is a workflow integration problem. Saving a timestamped screenshot is not a judgment problem. It is an audit artifact problem.

The mistake is asking whether underwriting should be automated. The better question is which part of underwriting is judgment, and which part is clerical verification pretending to be risk work.

What Part of Manual Underwriting Should Die First?

The first part to retire is manual business verification. It is the least defensible manual step because it has high volume, inconsistent execution, direct audit implications, and a clear API replacement path.

For Cobalt's ideal buyers, the pain is especially acute. The ICP file describes high-volume alternative lenders, MCA providers, and lending infrastructure companies processing hundreds to thousands of applications, often with same-day or 24 to 48 hour approval expectations. Their risk and operations leaders are measured on approval rate, fraud rate, time to approval, default rate, and cost per application. Manual verification pushes against every one of those KPIs. Even in bank lending, the FDIC reported that approximately half of U.S. banks were using or considering financial technology in small business lending, with common use cases around compliance, data management, and servicing after approval.⁹

What Does Manual Verification Usually Include?

• Secretary of State lookup. Confirm legal name, entity status, formation date, registered agent, officers where available, and source URL.
• Name matching. Decide whether "ABC Holdings LLC" on the application matches "A.B.C. Holdings, L.L.C." in state records.
• Screenshot capture. Save proof of the state record at the moment of decision.
• Manual notes. Copy status fields, filing dates, and exceptions into the LOS or CRM.
• Escalation routing. Decide whether a no-match, inactive status, dissolved record, or ambiguous result should go to compliance, underwriting, or fraud review.

Those tasks matter, but that does not mean a person should perform them one at a time. The person should review the exceptions surfaced by the system.

Why Is Secretary of State Data the First Automation Layer?

Secretary of State data is foundational because it answers the first KYB question: does the legal business exist in the claimed state, and what does the primary source say about its status? Cobalt's internal SOS API documentation describes the product as a single API call for real-time business entity data from official Secretary of State databases across all 50 states and the District of Columbia. The response can include legal name, status, normalized status, filing date, registered agent, officers, addresses, state of formation, source URL, screenshot URL, confidence score, and possible alternatives.

That does not make SOS verification a complete underwriting decision. It makes it a clean first gate. If the business does not exist, is dissolved, is too new for policy, or has an ambiguous match, an underwriter should know that before spending time on deeper credit analysis.

Is Automated Underwriting the Same as Automated Verification?

No. This distinction matters because it keeps the article honest and keeps the product positioning credible.

Cobalt's published automated underwriting guide makes a similar point from the platform side: small business lending has a verification gap because many generic automated underwriting systems were built around consumer or mortgage workflows rather than entity-level business data.³ That is exactly where the strategic line should be drawn. Automate source retrieval and routing. Keep judgment where judgment changes the decision.

Why Does This Distinction Help Risk Leaders?

It prevents the false choice between "fully manual" and "fully automated." A VP of Risk does not need to argue that algorithms should approve every file. They can argue that the team should stop manually gathering the same primary-source facts. The risk function keeps control of thresholds, policy exceptions, and escalation logic.

Why Does This Distinction Help COOs?

It turns automation into an operations redesign rather than a staffing threat. The COO can move verification analysts out of browser-tab work and into higher-value exception review, audit sampling, and fraud pattern monitoring. That is easier to defend than a thin "replace people with software" pitch.

What Does a Modern Verification Workflow Look Like?

A modern workflow fires verification at application intake, routes routine results automatically, and reserves human review for exceptions.

1. Application arrives. Business name, state, address, signer, EIN, and owner data enter the LOS or application platform.
2. SOS lookup runs. The system calls a real-time SOS API for entity status, filing date, registered agent, officers where available, source URL, and screenshot URL.
3. Match confidence is scored. Exact matches flow forward. Moderate confidence results route to review. Low confidence or no-match results pause the file.
4. Related checks run. Depending on workflow, the lender may add TIN/EIN verification, OFAC screening, UCC filing data, or court records checks.
5. Underwriter sees a packet. The underwriting screen shows structured evidence instead of scattered screenshots and notes.
6. Exceptions get reviewed. People review mismatches, unusual statuses, thin state data, signer questions, and policy exceptions.

Here is a simplified SOS API pattern using Cobalt's documented request shape:

curl --location '{{COBALT_API_BASE}}/v1/search?searchQuery=Acme%20Corp&state=delaware&liveData=true&screenshot=true' \
  --header 'x-api-key: YOUR_API_KEY' \
  --header 'Accept: application/json'

The response can return entity status, formation data, registered agent data, officers where available, possible alternatives, source URL, screenshot URL, and a request ID. For slow state systems, Cobalt's public Help Center tells users to choose a results flow through webhook `callbackUrl` or polling with `retryId`, and to store JSON responses and screenshot URLs as audit artifacts.¹⁰ That means the user experience does not have to wait on a long-running state lookup.

What Should Still Route to a Human?

• Moderate confidence matches. The entity looks close, but not close enough to auto-clear.
• Inactive, dissolved, or revoked status. The result may be a hard decline, a compliance review, or an applicant correction, depending on policy.
• Newly formed entities. Formation date may trigger minimum time-in-business rules.
• State data gaps. Some states disclose less officer or ownership data than others, so the workflow needs a policy path for thin state records.
• Signer mismatch. The person signing the application may not appear in officer, principal, or related-business data.

This is where manual underwriting remains alive. It is not dead. It is pointed at the right problems.

What Does the Market Data Say About Speed and Risk?

The market data supports a practical middle position: borrowers reward speed, but lenders still need evidence and auditability.

The Federal Reserve's 2025 Employer Firms report found that nearly four in ten employer firms sought a loan, line of credit, or merchant cash advance in the prior 12 months.⁴ The Federal Reserve's broader small business credit analysis also notes that applicants use online and nonbank financing channels because of speed and perceived approval likelihood, while online lender applicants reported higher rates of challenges such as high interest rates and unfavorable repayment terms.²

For a high-volume lender, that creates a hard operating target: move fast enough to win good borrowers, but not so fast that entity verification becomes a checkbox.

Why Is Manual Verification a Speed Problem?

Manual verification adds minutes to every file and hours to the queue. In a same-day funding model, the queue matters more than the average lookup time. One file taking 10 minutes is manageable. Hundreds of files waiting behind the same manual step is not.

Cobalt's internal crosswalk source for this topic showed the demand signal behind the article: the "Is Manual Underwriting Dead?" short had a Business Value score of 47.4, 883 YouTube views, 104 Google Search Console impressions, and no existing blog match. That makes it a good strategic POV topic because the market is already asking the question, but Cobalt has a clearer answer than the headline implies.

Why Is Manual Verification a Risk Problem?

Manual verification produces inconsistent artifacts. One analyst saves the screenshot. Another copies only the status text. Another uses a stale tab from a previous search. Another checks the wrong state because the applicant listed a principal office rather than formation state.

Regulators and bank partners care about documented programs, not verbal confidence. FinCEN's Customer Due Diligence materials continue to frame covered financial institution obligations around identifying and verifying customers, understanding relationship purpose, and conducting ongoing monitoring on a risk basis.⁵ FinCEN's 2025 BOI changes also show why teams cannot rely on one static regulatory assumption about beneficial ownership data. Domestic reporting company obligations changed, and foreign reporting company deadlines remained separate.⁶

How Should a VP Risk or COO Redesign the Team?

The strongest automation programs do not simply remove work. They change the work. The verification team becomes an exception and control team.

What KPIs Should Change?

• Exception rate. What share of SOS lookups requires human review?
• Auto-clear rate. What share clears through policy without manual touch?
• Median verification time. How long from application submission to verification packet ready?
• Audit artifact completeness. What share of files has request ID, source URL, timestamp, and screenshot URL?
• False decline review rate. How often does automation route a file to decline or review when the underwriter later clears it?
• Verification-attributable loss review. Which funded losses involved an entity verification miss?

Those KPIs are more useful than measuring how many manual searches an analyst completed. Once the clerical work is automated, productivity is not clicks. Productivity is cleaner routing and better risk control.

Where Does Cobalt Fit Without Overclaiming?

Cobalt is best positioned as the primary-source business verification layer. It is not a loan decisioning engine, and it should not be described as one. Its role is to fetch and normalize official state data so the lender's underwriting workflow can make faster, more defensible decisions.

For SOS verification, the relevant Cobalt capabilities are:

• All 50 states plus DC. One API shape across state systems that have different interfaces and data formats.
• Live or cached mode. Live data for final verification, cached data for fast pre-screening where policy allows it.
• Normalized fields. Status and entity data returned in consistent field names instead of state-specific formats.
• Confidence scoring. Match quality can route high-confidence results forward and send moderate or low confidence results to review.
• Timestamped screenshots. Screenshot URLs support audit documentation, with the caveat that customers should store artifacts in their own system of record.
• Async support. Callback and retry handling for slower state systems.
• Optional related-business discovery. The beta `findRelatedBusinesses=true` parameter can surface businesses linked through officers or registered agents, useful as risk signal enrichment.

That is enough to remove a major manual bottleneck while keeping Cobalt's claims appropriately bounded.

What Limitations Should Be Named?

Some state systems are slow. Officer data availability varies by state. Delaware status checks can involve state-imposed fees. New Jersey makes less public information available than states such as Florida. Screenshot URLs are temporary, so lenders should download and retain them. Related-business discovery is beta. These limitations do not weaken the argument. They make the argument credible.

What Is the Practical Answer to "Is Manual Underwriting Dead?"

The answer is: no, but the job description is changing.

Manual underwriting remains valuable when the file requires interpretation. It is wasteful when the file requires primary-source retrieval. A strong underwriting operation in 2026 should look less like a room of people searching state websites and more like a decision system with human review at the exact points where judgment changes the outcome.

That means the question is no longer "human or machine?" It is:

• Which facts should the system retrieve automatically?
• Which results should auto-clear under policy?
• Which exceptions deserve human review?
• Which artifacts must be retained for audit?
• Which misses should feed back into policy?

Lenders that answer those questions will not kill underwriting. They will make underwriters more useful.

FAQ Schema