Skip to main content
Lead is the lender of record for every credit product on the platform: when your customer borrows, Lead originates the loan. That one fact shapes the whole integration — it’s why underwriting decisions are reported to Lead (Applications), why the loan’s terms live on an object in Lead’s system (the Balance), why drawing principal is an execution call that moves real money (the Funding), and why the loans Lead originates become yours through a daily receivable sale — unless your program keeps them on Lead’s balance sheet (balance-sheet models).

​
The Four Moving Parts

1. Origination. The compliance chain is Entity → Application → Account → Balance. The Account carries a credit_with_underwriting capability (requiring an approved Application) or credit_without_underwriting for non-underwritten products such as courtesy overdraft. The Balance carries the loan’s terms; creating it moves no money — at creation it represents an unfunded loan. See The Balance Object. 2. Funding. The one execution API in the lending family (Executing vs. Reporting): a Funding draws principal from a Lead GL into your funding FBO, and you disburse onward over any payment rail — instant payments for real-time disbursement, ACH for batch, wires for large-dollar. 3. Servicing. You are the servicer and ledger of record. Repayments, interest, and fees are reported to Lead through the daily Balance and Transaction reporting. For revolving products this reporting is operationally load-bearing: available credit — which gates the next draw — is computed from what you report. 4. Receivable Cycle. Because Lead is the lender of record, every origination creates a receivable: Lead’s claim on the loan. Under the Originate-to-Sell model, receivables past your program’s hold period are grouped into a single daily sale you purchase; under On-Sheet Lending, Lead holds them to terminal status. See Receivables & the Daily Sale and Balance-Sheet Models.

​
What You Can Build

Closed-end term loans (including BNPL), open-end lines of credit, card-based revolving and charge credit (card programs), and overdraft products. The object model is identical across all of them; the differences live in the Balance’s structure (non-revolving vs. revolving) and your program configuration.

​
Integration Surface Today

Origination and funding are fully API-based. Servicing runs on the daily Balance and Transaction files, and the receivables sale runs on the Sales Request/Response file exchange — each with an API successor in flight. Current state per workflow: Integration Surfaces by Product; the forward story: Platform Evolution.
Legacy: the Disbursement API. Programs onboarded before the Funding API disburse through the rail-limited Disbursement API. It is not part of new integrations. If your program uses it, its reference documentation remains available and your Lead team can discuss migration.

​
In This Section

The Balance Object — the loan or line itself: creation, the two structures, terms, and Lead’s view of the live position · The Funding Object — your instruction to Lead to originate principal: the principal decomposition, lifecycle, and sandbox testing · Receivables & the Daily Sale — how loans move from Lead’s balance sheet to yours · Balance-Sheet Models — Originate-to-Sell vs. On-Sheet Lending · Sales Settlement Amount — how each day’s purchase is priced. End-to-end walkthroughs: Instant Loan Origination and Disbursement · Run a Credit or Charge Card Program · Originate Your First Loan (quickstart with full payloads).