Professional License Check for Marketplace Lending

June 3, 2026
June 3, 2026
7 Minutes Read
Business Verificationblog main image

Executive Summary: A professional license check for marketplace lending answers a specific intake question: does the borrowing business actually hold the credential it needs to legally do the work it does. For construction-adjacent marketplaces funding contractors, that credential is a state contractor license, issued and tracked by boards like California's CSLB.[1] This use case walks through how a marketplace lender verifies a contractor license at onboarding, where Cobalt's coverage is confirmed, and how to route the borrowers and states that fall outside it.

Why does a marketplace lender need a license check at intake?

What risk does an unlicensed or lapsed borrower create?

A marketplace lender funding a construction business is exposed if that business cannot legally operate. A lapsed, suspended, or revoked license can stop the borrower from winning contracts, collecting on completed work, or defending against disputes, including mechanic's lien fights that complicate recovery.[2] For VP Risk and Marketplace Ops, the license is a leading indicator of whether the revenue backing the advance can keep flowing.

Why verify rather than trust the application?

Self-reported status is not a control. A borrower may report a license that expired, was suspended after application, or belongs to a different entity. An independent check at onboarding gives the marketplace an objective input it can apply consistently across every contractor in the book, instead of relying on each applicant's disclosure.

What does "professional license" mean in this use case?

Which licenses does this cover?

Scope this honestly. For Cobalt, "professional license" here means contractor licensing in four confirmed states: California, Florida, New York, and Texas. Contractor licensing itself is fragmented; even with multi-state exam accreditation through groups like NASCLA, there is no single queryable national record.[3] It does not extend to medical, legal, real-estate, or financial-advisor licenses, which sit under separate boards such as California's DCA umbrella.[4] If a marketplace funds those professions, this specific check does not apply and those credentials need a different verification path.

Which states are confirmed?

StateAPI state codeAuthority behind the dataIntake action
California`ca`CSLBVerify before activation
Florida`fl`DBPR Construction Industry LicensingVerify before activation
New York`ny`NYC Department of BuildingsVerify before activation
Texas`tx`TDLRVerify before activation

Oregon and every other state are not confirmed. Route Oregon to Cobalt sales and route all other states to a fallback lookup. Do not let an uncovered state pass as verified.

How does the onboarding check run end to end?

What does Marketplace Ops collect at intake?

The single hard requirement is the license number. The Contractor License API searches by license number, not by business name, so the onboarding form must capture the number as a required field for contractor borrowers. If the number is missing, the check cannot run, so the form design is the first place this use case succeeds or fails.

What does the API call look like?

curl --location 'https://apigateway.cobaltintelligence.com/contractorSearch?licenseNumber=987654&state=fl&callbackUrl=https://marketplace.example.com/cobalt/callback' \
--header 'x-api-key: YOUR_API_KEY' \
--header 'Accept: application/json'

The endpoint is asynchronous and delivers through a callback, typically in 30 to 60 seconds. That fits onboarding well: the marketplace can hold activation in a pending state while the callback resolves, rather than blocking the applicant on a synchronous response.

How should Ops turn a license result into an onboarding action?

What signals map to what actions?

SignalOnboarding actionWhy it matters
Active license, covered stateContinue activationIssuing board confirms legal operation
Expired or suspendedRoute to risk reviewBorrower may not be able to operate or collect
RevokedHold or decline per policyStrong signal the business cannot legally perform
Disciplinary action presentRoute to risk reviewContext that may change terms
Uncovered state or OregonFallback lookup, no auto-clearCoverage gap must be closed by a human

Who sets the threshold?

Cobalt is a data source, not a decisioning engine. The API reports what the state board says. VP Risk sets the rule for what expired, suspended, or revoked status means for activation, pricing, or decline. Cobalt confirms the status; the marketplace owns the decision and the audit trail.

The onboarding question is not whether the contractor says the license is current. It is whether the issuing state board confirms it before the marketplace activates the borrower, and whether Ops has a defined answer for every state the check does not cover.

How does the marketplace handle states the check does not cover?

What is the fallback path?

For any state outside CA, FL, NY, and TX, route the borrower to a fallback: the state board's public verify tool or a manual review step. Florida's portal and Texas TDLR both publish public license lookups, and most states offer an equivalent.[5][6] The principle matches the unsupported-state handling in a pre-funding UCC lien search workflow: missing coverage routes to fallback, never to silent clearance.

Why does this matter for a high-volume book?

Marketplace lending runs on throughput, so the temptation is to auto-pass anything the API does not flag. That is exactly how a revoked license in an uncovered state slips through. An explicit fallback flag keeps the gap visible and forces a human to resolve it before activation.

How does the license check fit the rest of onboarding?

What runs alongside it?

For a construction-adjacent marketplace, the practical stack is Secretary of State entity verification, then contractor license verification, then court records for litigation and judgment context. Compliance screening such as OFAC runs alongside, as covered in BSA/AML for alternative lenders. Each layer answers a separate onboarding question, and the license check is the one that confirms the borrower can legally do the work.

What should engineering store?

Store the raw callback response, the parsed status, the license number and expiration, any disciplinary detail, and the activation decision reason. The raw record proves what was checked. The parsed fields drive routing. The decision reason explains, months later, why the borrower was activated, conditioned, or declined.

What onboarding checklist should the team use?

What should the first version include?

1. Require the license number on the contractor intake form.

2. Send covered-state borrowers (CA, FL, NY, TX) to the Contractor License API by number.

3. Hold activation pending while the callback resolves.

4. Apply risk rules to expired, suspended, revoked, or disciplinary results.

5. Route Oregon to sales and all other states to a fallback lookup.

6. Store raw response, parsed status, and activation reason for audit.

How can a marketplace start checking licenses at onboarding?

Begin by making the license number a required intake field for contractor borrowers in the four covered states, then wire the rest to a fallback. To see the Contractor License API return live status during an onboarding flow, you can book a Cobalt demo.

References

1. CSLB, California Contractors State License Board

2. Mechanic's Lien, Legal Information Institute

3. NASCLA, National Association of State Contractors Licensing Agencies

4. Verify a License, California Department of Consumer Affairs

5. MyFloridaLicense, Florida DBPR

6. TDLR, Texas Department of Licensing and Regulation