Onramp · anatomy · The Agentic Bank

Verifies the application, pulls the bureau file, and surfaces every data-quality and FCRA-dispute flag before underwriting.

First stage of the consumer-lending pipeline. Assembles the clean package the underwriter works from; it does not make the credit decision.

Methodology

1 Pull the application and confirm the required fields are present (income, employment, requested amount; for auto, term and collateral value).
2 Pull the credit report and summarise it: the score (or that none was returned), utilisation, the derogatory count, and whether it is a thin file.
3 Compute the existing (pre-loan) debt-to-income ratio from the stated monthly debt and income.
4 Surface every data-quality and FCRA issue as a flag: a missing field, a thin file, a stale tradeline, and especially an active FCRA dispute on a derogatory.
5 Set readyForUnderwriting to false when the package is incomplete, has no usable score, or carries an unresolved dispute that bears on the decision.

Sandboxed tools

In-process MCP tools only. Built-in tools disabled, settingSources [], permissionMode bypassPermissions. The only ground truth is the tools.

get_application read

The applicant's credit-relevant fields (no prohibited-basis data is exposed).

get_credit_report read

The bureau credit file by its reference.

record_intake commit

Commits the verified intake package. Called exactly once.

Outcome contract

A verified intake package: the product, completeness, the verified fields with the existing DTI, the credit summary, the flags, and a readyForUnderwriting gate.

▸ the validated schema (IntakePackage)

type IntakePackage = {
  product: "auto" | "card"
  completeness: "complete" | "incomplete"
  verified: { income, monthlyDebt, requestedAmount,
              existingDtiPct, employment }
  creditSummary: { scored, score: number | null,
                   utilizationPct, derogatories, thinFile }
  flags: string[]                  // data-quality + FCRA issues
  readyForUnderwriting: boolean
}

Grounding

real FCRA accuracy / dispute handling. An active, unverified FCRA dispute on a derogatory must be surfaced, not silently relied on downstream.

synthetic Synthetic lending applicants + bureau files. Applicants, credit reports, and the policy. Synthetic, because real applicant data is proprietary.

Governance seams

The three trust boundaries a runtime governance layer clamps onto. Shown here ungoverned, so you can see exactly what would be inspected, redacted, or blocked.

Model plane

context in

The Onramp methodology plus the application and the credit report.

governor → Confirm intake collects only credit-relevant fields, no prohibited basis.

Tool plane

application + bureau

The get_application and get_credit_report calls' full I/O.

governor → Govern which bureau is pulled and what fields intake may read.

Data plane

the commit

The verified package and its readiness gate written to the case journal.

governor → Require the readiness gate to hold a dirty package before underwriting sees it.

Onramp never sees or seeks prohibited-basis data, and its job is to surface problems rather than bury them: an active FCRA dispute or a thin file sets readyForUnderwriting to false instead of passing a dirty package downstream.

Evals & guardrails

4 / 4 golden Graded on completeness, the flags raised, and the readiness gate.

Active FCRA dispute. Flags a disputed, unverified derogatory and holds readiness rather than passing it silently.
Thin file. Marks no usable score and sets readyForUnderwriting to false.

Orchestration

Worker intake / verification

⇢First stage; feeds Spark
⇢Part of Onramp → Spark → Equipoise → Backstop → Keystone