pitch.apis.finance
The functions a lending system calls.
Verification, extraction, deterministic math, lifecycle tracking — called mid-flow by your systems and agents, at posted rates, with a receipt for every call. The licence, the credit decision, the ledger, and the customer stay with you.
↓ scroll · arrow keys
Every lending flow stops in the middle for work that is neither the core system nor the licence: verify the applicant and the documents, extract a file into typed records, compute the figures, chase what's stale. Today that work is either a back office of humans or a chain of bespoke vendor integrations — each behind a negotiated contract, each priced in a procurement cycle, none of it readable by the system actually doing the calling.
That was tolerable when humans drove the flow. It breaks now, because the caller is increasingly a machine: an origination system, a servicing stack, an agent acting for either. A machine cannot sit through procurement. A price it cannot read at call time does not exist for it, and a vendor log it cannot reconcile is a liability its compliance team inherits.
The contract is small enough to state in full. discover the catalog — typed schemas, posted rates, versions. describe one function's contract. estimate a call before making it — the estimate is binding for the quoted inputs. verify identity, document authenticity, stated-fact consistency across a file. extract documents into structured, typed records. compute deterministic financial math — amortization, payoff, fees, quotes — versioned so the same inputs always reproduce the same figures. track what a file is missing, what is stale, what needs a chase. inspect the receipts.
// illustrative product mechanics, not results
POST /invoke
{
"function": "compute.amortization@v12",
"program": "heloc-2026",
"inputs": { "principal": 250000, "termMonths": 360, "aprPct": 6.125 }
}
// every call returns a receipt:
{
"receipt": {
"function": "compute.amortization@v12",
"program": "heloc-2026",
"credential": "org:lender/systems/los-prod",
"rate": "cited from the public card",
"outcome": "ok"
}
}
Nothing changes silently underneath a lending flow: every function version carries a published deprecation schedule, and a receipt cites the exact version and the posted rate it settled at. Receipts are designed to be the one record a lender's compliance and finance teams both reconcile from.
The licence. The credit decision. The ledger. The customer. This rail computes, verifies, extracts, and tracks; it does not lend, underwrite as a legal act, or move money. Any step a statute reserves for a licensed person belongs to the lender's own licensed staff, and the rail is built so that routing is explicit.
That boundary is the design, not a limitation. A rail that tried to absorb the licensed steps would become a competitor to its own customers; a rail that supplies functions into licensed flows is infrastructure to all of them at once — including to lenders who compete with each other. Neutrality is what the boundary buys.
Where the applicant's data goes is a contract term, not an appendix. Verification and extraction mean applicant data — consumer NPI under GLBA — crosses into the rail mid-flow, so the rail is built to be read as a GLBA service provider. Data is program-scoped like the credential that carries it, processed to execute the invoked function and produce its receipt, and never used to train models. Retention is bounded by the program's stated retention window, and subprocessors are disclosed on a published list before they touch a program's data — not discovered in an audit.
The control posture — access, retention, subprocessor management — is asserted as an audited fact when the SOC 2 Type I report is published, not before. Until then it is a design commitment, written into the contract where a compliance team can hold the rail to it.
One statute can bind the supplier, not just the licence-holder. Verification output consumed in credit decisioning can make the supplier a consumer reporting agency under FCRA regardless of who holds the lending licence — so the boundary argument above does not settle it, and this deck does not pretend it does. The design intent is that verification functions operate as the lender's service provider on data the lender supplies about its own applicant — not assembling third-party consumer data for furnishing across customers — but that posture is a legal conclusion, not a design choice, and it is not claimed as fact here.
How each verification function family sits relative to FCRA — CRA status, permissible purpose, adverse-action obligations — is ratified by counsel per family and published as part of the capability contract before that family serves a credit decision. Non-CRA status is asserted then, or the scope is narrowed until it can be.
| name | unit | covers |
|---|---|---|
| Verification | per invocation | identity · document authenticity · stated-fact consistency |
| Extraction | per invocation | lending-file documents to structured, typed records |
| Deterministic math | per invocation | amortization · payoff · fee and quote calculations, reproducible per version |
| Lifecycle tracking | per invocation | missing · stale · needs-a-chase, across a file lifecycle |
Financial services is the home of the bespoke vendor contract, which is exactly why this rail refuses one. The caller is a system, so the price has to be readable at call time by the thing deciding whether to call. One card means the studio's own brands pay what a national lender pays — list price IS the arm's-length price, and third parties paying it are what makes that true. And every receipt cites the posted rate, so a lender's finance team closes its books against the same public card its compliance team audits agent spend against. Volume does not buy a different rate: on a mostly fixed-cost platform, volume improves our margin at the same card, and the card staying flat is what keeps the rail neutral between a seed-stage fintech and a national lender.
Per-invocation rates by function class. The structure is fixed — metered, classed by compute and latency profile, program-scoped; the figures publish when the card is live, and no figure is asserted before then.
Machine settlement over x402 / Mandate rails is the designed payment path. Until the first settlement clears on those rails, payment is by funded program balance drawn down per receipt.
The kill-class for anything sold into lending is demand cyclicality, and a metered rail does not get to hide from it: per-invocation revenue rides the industry's volume, by construction.
US mortgage origination ran roughly $4.4 trillion in 2021 and roughly $1.5 trillion in 2023 on MBA's published series — close to a 3x swing in two years, driven by rates alone, with refinance-heavy segments swinging harder still. That is the demand curve this rail is built under, stated rather than wished away.
Four properties are designed against it. Metered-with-no-minimums is trough-shaped: in a downturn a lender cuts seats and renegotiates contracts, but a metered bill falls with volume by itself — there is nothing to cancel, so the integration survives the trough that kills per-seat vendors. The catalog spans the counter-cycle: origination functions run hot when rates fall; when rates rise, books season and the calls come from the servicing side — lifecycle tracking, chase work, payoff and audit math. The catalog grows by demand evidence, so in a trough it grows on the trough's side. The rail's own cost base doesn't ride the cycle: no licensed human supply sits on this brand's books — that cost structure belongs to the estate's regulated cells — so a volume trough compresses revenue, not viability. Lending is the wedge, not the boundary: the dimension is financial services — consumer, auto (composed with auto.dev's rails), SMB, servicing-first fintechs — with cycles that do not move as one.
The countercyclical mix is a design claim today, and this deck labels it as one. It is claimed as fact when a reported function mix shows servicing-side volume holding through a rising-rate leg — not before.
Primary motion is B2A2B: our functions serve a business customer through its systems and agents — the lender's origination flow calling the rail mid-flow on its own behalf. Secondary is A2A: external agents transacting with the rail directly, machine to machine, settlement included. The channel matches the motion — machine-readable discovery at the apex domain and position in the agent-discovery namespace, because a rail whose caller is a system is found the way systems look, not the way buyers browse.
A2A is the least proven motion in the estate and the largest one if it lands. It is claimed when the first external settlement clears, not before.
The functions on this rail — verification, extraction, deterministic math, lifecycle tracking — are precisely the work that migrates Human → Agentic → Generative → Code. The statutory floor in financial services sits with the licence-holder, which is the customer; the rail itself carries no licensed-supply cost, so its economics are software economics on a mostly fixed-cost platform, and margin improves with volume at an unchanged public card.
Calling-system count, invocation volume, and revenue. Not presentable until the reporting basis resolves; no figure appears in this deck before then.
in the agent-discovery layer, financial services should resolve to apis.finance the way automotive resolves to auto.dev — the domain is the shelf position for machine callers
a lender that has closed a year of books against versioned receipts and one public card does not re-verify a new vendor for sport — the audit trail is the switching cost
posted rates let the rail serve competing lenders simultaneously; a negotiated-price vendor structurally cannot be the neutral default for a whole industry
versioned functions reproduce the same figures for any auditor at any later date — the property compliance teams standardize on and then defend internally
Stated plainly: this deck precedes the brand's public surfaces. apis.finance is a G4 projection of the studio's G3 stack — the function runtime (functions.do), API layer (apis.do), and data layer (database.do) — and the brand-specific surfaces are designed, not shipped. Every amber below is deliberate: the deck is built before the catalog, and says so.
The catalog — typed schemas, posted rates, latency classes, versions — is the primary surface, designed so a system never needs an HTML page to find, price, or call a function. It is claimed when a machine can fetch it cold.
The rail is built to the Agent eXperience Protocol posture — discoverable, priceable, callable by machine. Conformance is claimed only when a cold conformance run is published.
The claim that matters: an external lender's or fintech's production flow, calling under its own program-scoped credential against a funded budget, reconciling from receipts. It posts when it has happened, with the receipt discipline as the evidence.
If this was forwarded to you: apis.finance is the demand rail into financial services — verification, document extraction, deterministic financial math, and lifecycle tracking, called mid-flow by a lender's or fintech's systems and agents at posted public rates, with a receipt for every call. The licence, the credit decision, the ledger, and the customer stay with the lender; the rail supplies functions into the licensed flow and never substitutes for the licence. Every claim above carries its own state and evidence — including the ones not yet earned. If you run a lending platform: read the contract. If you know who does: forward this.