Can an API Detect Fraudulent Business Applications? What Verification Data Actually Does

Executive Summary: The fraudulent application does not arrive through your underwriter. It arrives through the ISO packet: a broker-submitted intake file with a business name typed from memory, an address that does not match the bank statement, and supporting documents assembled by a third party who has never met the merchant. One funder put it plainly: "We're getting this from third parties who generally aren't that sophisticated doing SOS searches for us." Another lending infrastructure team described applications where three different documents carried three different addresses. A verification API will not tell you which of those applications is fraud. What it will do is put the state's own record next to the application, live, at the moment you decide. This article explains exactly which returned fields surface which fraud patterns, where the check belongs in your underwriting waterfall, and which states and fields are not covered. The stakes are not theoretical. The SBA Office of Inspector General estimates more than $200 billion in potentially fraudulent pandemic-era business loans, roughly 17 percent of disbursed funds, much of it borrowed against businesses that barely existed.^[1] In April 2026 the SBA referred 562,000 suspected fraudulent COVID-era loans, totaling $22 billion, to Treasury for collection.^[2] Application fraud against business lenders is a volume business, and it exploits one gap more than any other: stale data. A company dissolved last month still reads Active in somebody's cached file. That gap is where this article starts.

Can an API Detect Fraudulent Business Applications?

A business verification API does not decide whether an application is fraudulent. It supplies the primary-source facts that fraud logic runs on: current entity status, filing date, registered agent, officers, lien filings, and sanctions matches, pulled live from the state of record. The decision rule stays with the lender's own model.

That distinction matters because "fraud detection" implies a verdict, and a verdict is not what verification data provides. Only three capabilities in a verification stack can honestly be described as detection:

• Name and EIN mismatch. A boolean IRS match between the submitted business name and EIN. A mismatch is a classic synthetic-identity signal: a real EIN paired with a fabricated business name, or the reverse.

• UCC stacking detection. Existing lien filings against the applicant reveal advances already taken from other funders, the core signal for business verification to prevent loan stacking.

• OFAC sanctions screening. A match against the sanctions list is a hard stop no lender's risk appetite overrides.

Everything else the API returns is substrate: normalized, primary-source fields your own rules consume. There is no built-in fraud scorecard, deliberately. Funders vary too widely in risk appetite for one vendor's score to fit an MCA shop writing same-day deals and a trade credit team underwriting 60-day terms. The fields are normalized across all 50 states precisely so that your team builds and owns the decision logic. For a map of how verification data feeds fraud decisioning across the vendor landscape, see our buyer's guide.

What Is a Ghost Business, and How Does Verification Surface One?

A ghost business is an applicant whose registration either never existed or was dissolved before funding. Verification surfaces it by pulling entity status and filing date live from the state of record. A registration that never existed and one dissolved last month fail differently, and both can read as legitimate in a cached file.

The never-existed case is the easier catch: the state returns no record, and the application dies at intake. We covered the anatomy of these schemes in how fraudsters create entities that don't really exist. The dangerous case is the resurrected dissolved entity, a real company with a real filing history that quietly stopped existing. Whether it reads Active or Dissolved on funding day depends entirely on when your data source last looked.

Cached databases fail here on a schedule nobody publishes. Corey Batz of Bectran described what that looked like with a prior data vendor: "This said service is not very reliable, they were pulling in very outdated and most of the time just straight up wrong data, and we had reports from our customers which then looked very bad on us." A lending platform's product team made the same point about evaluating any cached source: the refresh schedule is unknown, so the staleness risk is unquantifiable. The pandemic loan programs demonstrated at national scale what happens when nobody checks the state record at all: Kabbage paid up to $120 million to settle allegations it failed to catch fraudulent PPP applications, as we covered in our analysis of the settlement.

To be precise about our own architecture: Cobalt also operates a cache, updated monthly, and it serves roughly 70 to 80 percent of lookups sub-second. Cache is triage and enrichment. The live primary-source call sits on the fund/no-fund gate, where freshness decides the outcome. The difference between the two modes is the difference between real-time verification that prevents lending fraud and a faster version of the stale file that funded the ghost.

How Do Lenders Verify a Business Is Legitimate Before Funding?

Lenders place a live entity-status check on the fund/no-fund gate, pulled from the state of record rather than a cached copy. Active versus inactive is the gating field: a fact, not a score. Filing date, registered agent, and officers then support the lender's own decision rule.

Juanita Chapa at Professional Credit Service states the rule most underwriting teams already run informally: "We don't want to move forward if the entity isn't active. Can't do much if they're out of business." The status field turns that instinct into an automated gate. The supporting fields each answer a specific application question:

• Entity status. The gating fact. Active proceeds; inactive, dissolved, or not-in-good-standing routes to decline or manual review.

• Filing date. Establishes true time in business, against the application's claimed operating history.

• Registered agent. A registered agent address that matches the "business address" on the application is a mail-drop signal worth a rule.

• Officers and directors. The names behind the entity, checked against the guarantor on the application. This is the straw-ownership field.

• State of formation. Reveals foreign registrations and cross-state incorporation patterns that change which record is authoritative.

• Filing history. Reinstatements and amendments tell you whether this entity has died and come back before.

What a fact-based gate cannot do is think for you. Even teams building AI-native underwriting have learned that the model needs an authoritative substrate underneath it. Gary Highland, whose product EntityScanAI is itself an AI agent, is candid about the boundary: "Our AI agent is not 100% reliable in checking status of entities." The founder of an AI verification product buying a primary-source data feed is the clearest statement available of where the reliability line currently sits.

Where Should the Verification Check Sit in the Underwriting Waterfall?

Cheapest declines first. That is the entire architecture, and it comes straight from how high-volume funders describe their own operations. Joe Salvatore at Idea Financial: "We try to stay very lean in terms of costs. We have a waterfall progress of how we do things. The applications we're going to decline, we like to do so early on and inexpensively as possible."

Placed as sequential steps:

1. Run the immediate knockout based on SOS status. The cheapest declines happen at intake. An application for a dissolved entity should never reach a human underwriter, and every file that dies here lowers your cost per decline.

2. Pre-screen against cache. Roughly 70 to 80 percent of lookups return sub-second from cache. Use it for triage, enrichment, and pre-filling stips, never as the final word on status.

3. Confirm live at the fund/no-fund gate. The live primary-source pull belongs at the decision point, where an entity dissolved since the last cache refresh changes the outcome. Live calls run from about 7 seconds to roughly 2 minutes, with state processing times varying from about 14 to 180 seconds; Texas is among the slowest.

4. Branch New Jersey and Delaware to a purchased-report path. Two states do not publish entity status publicly. Route them to a separate workflow (covered in the limitations section below) rather than letting them silently pass.

Timing is not a detail here; it is the economics. Craig Clark at General Merchant Funding, on running EIN checks too late in the file: "It sounds like it's a little, but that could speed up a minute on each file. Add that up over thousands and you're getting a lot of time back." The same logic appears in automated underwriting systems for small business lenders: every check placed late costs the manpower spent on files it would have killed.

The live call itself is one request:

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

The response returns `status`, `filingDate`, `registeredAgent`, `officers`, a `screenshotUrl` audit artifact, and a `possibleAlternatives` array, the fields the rest of this article maps to fraud patterns. Slow-state latency stays off the user-facing path with async handling: a `retryId` for polling or a `callbackUrl` that receives results when the state responds.

How Do You Verify Ownership When the Application Has the Wrong Business Name?

Broker-submitted names are dirty by default: merchant names carrying extra location text, consumer names in place of business names, missing suffixes. Normalization strips punctuation and entity type across all 50 states before matching, and when the exact match is uncertain the response returns an alternatives list of up to 10 close matches, each with a confidence score from 0 to 1.0 built for auto-decisioning thresholds.

Ownership questions extend past the name. Bitty Advance raised the cross-state problem directly: merchants incorporate in one state and operate in another, "are there common states like the Delawares." State of formation plus a multi-state search answers which record is authoritative. For officer-level questions, the officers and registered agent fields carry the names; a related-business lookup that connects entities through shared officers is currently in beta.

Two limitations belong in this section rather than a footnote. First, suffix variants can score lower than expected: the same company with and without "LLC" may return a weaker confidence score than the match deserves, so calibrate thresholds against your own file mix. Second, some states return DBA or fictitious-name records ahead of the parent legal entity, and Missouri is a known problem state for this. Juanita Chapa described the practical version of the problem: records that read only as an informal trade name, with the legal entity nowhere on the application. When automating secretary of state lookups at scale, both quirks argue for routing low-confidence matches to review rather than auto-declining.

How Does Verification Create a Compliance Audit Trail?

Each lookup can return a timestamped screenshot, watermarked and linked to the source state document, captured at the moment of the pull. That artifact replaces the manual workflow Jamie Parker at Heron Data described watching inside lending operations:

"This is literally a team goes in, takes a screenshot, saves it to the CRM because that's how they audit that it was in good standing."

Bectran sees the same behavior across its customer base: credit teams going to the Secretary of State site themselves, plugging in the information, taking the screenshot, filing it. That screenshot is the artifact that proves the entity was in good standing on funding day, at the moment the decision was made, with the state's own page as evidence. A product leader at a lending infrastructure platform evaluating the API made the compliance value explicit: the screenshot was the feature they flagged for their auditors, a theme we explored in why data alone isn't enough for audits.

Regulators have raised the cost of thin files on the funder side too. The FTC permanently banned the operators of a merchant cash advance firm from the industry outright,^[3] and in 2024 a federal court entered a $20.3 million judgment against one of them personally.^[4] A conduct ban ends a career in business financing, and directors-and-officers coverage does not survive it. When enforcement arrives, the funders that can produce a timestamped record of what they verified, and when, are in a materially stronger position than the ones that cannot. Broker-channel criminal cases like the Kris Roglieri arrest show the same verification questions reaching intermediaries, and the pattern extends into private credit: this year a private lender's $100 million investor pool came under fraud investigation, a case we tracked in Beyond Banks.^[5]

Want to see what the audit artifact looks like on a real file? Request a demo and run a live lookup on any entity you choose.

Which States and Which Fields Are Not Covered?

A page arguing that stale data funds fraud earns the right to be read only if its own coverage claims are current. As of July 2026:

• Entity status: 48 states plus DC. New Jersey and Delaware do not publish entity status publicly. The workaround is a purchased status report, $6.25 per entity in New Jersey and $10 to $15 in Delaware; both states return certificates instantly. Route both to the purchased-report branch of the waterfall.

• UCC lien data: 11 states, returned inside the same SOS call.

• Contractor license verification: 4 states (California, Texas, Florida, New York), with Oregon next.

• Court records: state-level coverage including New York and Miami-Dade, with federal dockets available through a separate integration.

• FEIN: not returned. Only Florida collects and displays it at the state level. TIN/EIN verification is a boolean match against the IRS; it confirms whether a name and EIN pair, and it does not perform an EIN-to-name search or retrieve tax documents.

• OFAC scoring: methodology not fully explainable. The matching algorithm is not proprietary to Cobalt, and 95 is offered as a base threshold rather than a tuned recommendation.

• Known data-quality issues. DBA records ahead of parent entities (Missouri), suffix-variant confidence scoring, a documented API-versus-UI matching discrepancy, and normalization rules not yet published in written docs.

Publishing this list is a choice. One prospective partner, Shanker at Verdata, described their own caution before launch this way: "We have incorporated cobalt in our product. We haven't turned it on. We don't want wrong associations." That is the correct standard for verification data, and it is the standard this table is written to. A fuller state-by-state accounting lives in our answers to the 34 most-asked questions about Secretary of State APIs.

What Match Rate Should You Expect, and Why Does It Vary?

Expect a range, not a number. On clean inputs, one high-volume marketplace has run match rates above 90 percent. A rollout against dirty inputs ran 45 percent: 8,000 matched responses across 20,000 transactions. At another lender, a prior data provider simply failed to find the business roughly 15 percent of the time.

The causes are consistent and worth engineering against:

• Incomplete or informal names. "Joe's Plumbing" when the state record reads "JT Plumbing Services LLC."

• Consumer names in place of business names. Sole-proprietor files where the applicant field carries a person, not an entity.

• Suffix variants. With and without LLC, Inc., or Corp., which can also depress confidence scores.

• Cross-state incorporation. The record lives in a formation state the application never mentions.

• Inconsistent data across documents. The three-addresses-in-three-documents pattern that broker-channel intake produces.

Any vendor quoting one universal match rate is describing their cleanest customer. The honest engineering answer is to measure against your own intake channel, then use the alternatives list and confidence scores to recover the matches dirty input costs you. The in-house build comparison covers why normalization across 50 disagreeing state formats is most of the work.

Why Does Automated Fraud Decisioning Still Need a Primary-Source Substrate?

AI is entering underwriting faster than its guardrails are. Synthetic identity fraud is the growth category: U.S. lenders carried an estimated $3.3 billion in exposure to synthetic identities on new accounts in the first half of 2025,^[6] and a single synthetic identity charge-off averages roughly $13,000.^[7] Synthetic business identities raise the ceiling further, because a fabricated company can borrow more than a fabricated person.

The teams building AI into this fight are the ones most insistent on primary-source data underneath it. Theo at Onramp Funds, on general-purpose AI in the underwriting path: "You do not get consistent results yet and they don't have the guards to ensure it acts like an API." Gary Highland built EntityScanAI as an AI agent and buys the primary-source feed anyway, for the reason quoted earlier: the agent alone is not 100 percent reliable on entity status. None of this argues against AI in underwriting. A probabilistic layer needs a deterministic substrate: state-of-record facts the model can trust, so its judgment is spent on the fraud patterns rather than on whether its own inputs are current.

Which Returned Field Surfaces Which Fraud Pattern?

Every caveat in that table is carried in its own row deliberately. A signal map that hides its asterisks in a footnote is how coverage assumptions end up in production.

Glossary

• Ghost business. An applicant whose state registration never existed or was dissolved before funding.

• Resurrected dissolved entity. A dissolved company presented as active, exploiting stale data between cache refreshes.

• DBA / fictitious-name masking. Applying under a trade name that hides the legal entity of record.

• Straw ownership. A real person fronting an application for an undisclosed controlling party.

• Loan stacking. Taking multiple advances against the same business, visible in UCC filings.

• Synthetic business identity. A fabricated company built from fragments of real data, often a real EIN paired with a fake name.

• Cost per decline. The fully loaded cost of processing an application you reject; the waterfall exists to minimize it.

• Immediate knockout. An intake-stage rule that kills an application on a single disqualifying fact, such as SOS status.

• Stip. A stipulation; a document or condition required before funding.

• Incompletes. Applications missing required data, the files where dirty intake names concentrate.

• Registered agent. The entity's designated recipient for legal service, listed in the state record.

• Good standing. The state's confirmation that an entity is active and compliant with filing requirements.

Where to Go Next

If the fraud patterns in this article map to files you have already funded, start with the substrate. Review the leading Secretary of State API solutions for the verification layer, compare vendors in the business verification API buyer's guide, or request a demo to run live lookups against your own recent applications, including the ones that felt wrong.