Building a credit-decision pipeline — the queries we see most

What we mean by a credit-decision pipeline

A credit-decision pipeline is the automated step in an underwriting workflow that pulls verification data on a prospective borrower and surfaces it for either a human reviewer or a rule-based decision engine. The pipeline runs after the credit application is submitted and before the underwriter reviews. Its job: enrich the application with public-records data so the underwriter or rules engine has the facts.

Across the credit-decision pipelines we’ve integrated with, a few query shapes recur. Knowing them ahead of time helps a developer scope the integration.

Query shape 1: New deal verification

The single highest-volume query. The pipeline has just received a credit application. The application includes the prospective borrower’s legal name, state of formation, and (for trucking deals) a USDOT or MC number. The pipeline calls the verification API once to enrich the application before queueing it for review.

The typical request:

POST /api/v1/lookup
{
  "company_name": "Acme Logistics LLC",
  "state": "TX",
  "usdot": "1234567"
}

The response includes the SOS record, the FMCSA record (because USDOT was provided), the OFAC screen on both the entity and the principals returned from the SOS record, and any flags. Downstream the pipeline:

• Files the result against the application as a verification artifact.
• Checks the flags against the rules engine’s automatic-decline triggers.
• Queues the application for human review with the verification attached.

This shape accounts for somewhere around 70-80% of total volume in most pipelines.

Query shape 2: Re-verification on existing borrowers

Many lenders re-verify existing borrowers periodically — quarterly, annually, or on renewal events. The shape of the call is identical to query 1, but the comparison-point is the prior verification stored in the lender’s records rather than the current credit application.

The relevant logic is in the pipeline: compare today’s response to the last response. Surface deltas — a change in standing flag, a change in officer composition, a change in MCS-150 date — for human review. Most fields don’t change. The ones that do are signal.

This shape is lower volume than query 1 but produces a higher ratio of human-review events because deltas are by definition interesting. The cost economics are similar.

Query shape 3: Officer-name search across states

A specialized query that comes up in fraud-detection and shell-detection contexts. The pipeline has identified an officer name on a credit application or a verification result and wants to know what other entities the same individual is associated with nationally.

POST /api/v1/people/search
{
  "officer_name": "John Smith",
  "limit": 100
}

Response includes all SOS records nationally where the same officer name appears. The result is noisy by definition — common names produce many false positives — but the data is useful when combined with date-of-birth, address, or other disambiguating signal.

This shape is low volume in total but very high volume from specific customers (fraud teams, KYB platforms, due-diligence-as-a-service providers). It’s the kind of query that a normal lender might run once per deal during a high-risk review and that an investigative team might run thousands of times per week.

Query shape 4: Address-overlap search

The companion to officer search. The pipeline has identified an address — typically the principal address on an SOS record — and wants to know what other entities list the same address.

POST /api/v1/addresses/search
{
  "address": "123 Main St, Cheyenne WY 82001",
  "limit": 50
}

Response includes all SOS records nationally where the same address appears. Useful for shell-cluster detection — when 5+ unrelated entities share an address, the address is either a registered-agent service (probably uninformative) or an operator portfolio (probably informative).

Volume is similar to officer search — low total, high per-customer for specific use cases.

Query shape 5: Batch verification

Some pipelines process verifications in batches rather than per-application. The batch shape is essentially many query-shape-1 calls bundled. Common use cases:

• Overnight batch processing of new applications received during the day.
• Periodic re-verification of all active borrowers.
• One-time portfolio scrub when a lender acquires another lender’s book.

Batch queries are latency-tolerant (no human is waiting) but cost-sensitive (volume is high). The pipeline typically issues them with high concurrency, accepts queued responses, and processes them as they return.

What you typically want in a response schema

Across pipeline integrations, the fields that downstream rules-engines and review-UIs consume most often:

• status: a normalized standing flag (active, delinquent, dissolved, unknown). Different from each state’s specific flag — normalized for comparability across states.
• status_raw: the state-specific flag text (Active, Not in Good Standing, Forfeited Existence, etc.). Useful for the human reviewer; not the right field for an automated rule.
• principal_address: the principal place of business as filed.
• registered_agent: agent name and address.
• officers[]: an array of officer/manager records with name, title, and address.
• latest_filing_date: the date of the most recent maintenance filing.
• latest_filing_age_days: today minus latest_filing_date, computed server-side.
• fmcsa: nested object with USDOT, MC, operating-authority status, MCS-150 date, BASIC scores, and crash count. Null if the entity has no USDOT.
• ofac: nested object with screen result and any matches found.
• flags[]: an array of computed flags — stale_filing, pending_cancellation, address_overlap_high, officer_appears_widely, etc.

The flags array is what your rules engine should key off. The raw data is what your reviewer needs to see.

Idempotency and caching

A practical question: should the pipeline cache verification results, and for how long?

The right answer depends on the use case. For real-time underwriting decisions, current data is the point — caching is at the API gateway and usually 0-60 minutes. For periodic re-verification, caching makes no sense because the whole point is to detect changes.

A pattern we see often: pipelines cache responses for 24 hours keyed by (company_name, state) to avoid double-charging on a single application that gets reviewed multiple times the same day. That’s a reasonable default. Caching for weeks or months defeats the purpose of verification.

What this means for you

Most credit-decision pipelines look similar at the API layer. New-deal verification is the bulk of the volume. Officer-name and address-overlap searches are specialized, low-volume but valuable. The response schema needs both normalized fields (for automated rules) and state-specific fields (for human reviewers). Caching should be short.

A free lookup returns the same payload structure as /api/v1/lookup. Developer documentation lives alongside the API endpoint.