Skip to main content
This guide walks through originating a term loan or line of credit — personal loans, BNPL, or other credit products — disbursing the proceeds instantly over the Instant Payments API, and the two operating cycles typically ran afterward: daily servicing reporting, and the daily purchase of the receivables Lead originates. It’s for platforms that underwrite and service their own borrowers with Lead as the regulated lender of record.

​
How it works

Your borrower becomes an Entity; your underwriting decision becomes an Application; the borrower’s legal relationship with Lead is an Account with the credit_with_underwriting capability; the loan’s terms live on a Balance; drawing principal is a Funding — where real money is moved from a Lead GL to a Funding FBO; and the disbursement is an instant payment from that FBO to the borrower’s external account. Because Lead is the lender of record, each Funding also creates a receivable — Lead’s claim on the loan. After your program’s hold period has passed, receivables are grouped into a daily sale that you purchase, moving the asset from Lead’s balance sheet to yours. Origination is a per-loan flow; servicing reporting and the daily sale are program-level rhythms.

​
Example scenario

Lakeshore Lending offers small-dollar personal loans inside its budgeting app. Maya applies for $2,000; Lakeshore approves her in-app, reports her personal information and the approval to Lead, opens her loan, draws the principal, and sends it to her checking account at her own bank over FedNow — Maya receives the money before she closes the app. The draw creates a receivable on Lead’s books; after the hold period it rolls into a daily sale alongside that day’s other loans, and Lakeshore purchases it from Lead. Maya’s repayments are reported back to Lead through Lakeshore’s daily servicing files.

​
Objects involved

​
Before you start

  • Sandbox credentials with scopes covering entities, applications, accounts, subledger balances, fundings, and instant payments. Your Funding FBO exists from onboarding.
  • Note Instant Payments reaches FedNow-participating institutions today; RTP support is targeted for early Q4 2026 on the same API. Not every receiving bank participates.
  • Two parts of this program run on files today. Servicing is reported through the daily Balance and Transaction files, and the daily receivables sale runs as the Sales Request/Response file exchange — schemas for both in the File Reference. API successors are planned for both — user balance/transaction APIs and a sale API that tells you when a sale is generated (Platform Evolution); the shape of each cycle is unchanged across the transition, and this guide will be updated as they ship.
  • The Accounts and Subledger Balance APIs used below will also be succeeded by their unified-model equivalents (user accounts and user balances — Platform Evolution).

​
Integration steps

​
Step 1: Create the borrower Entity

Report the borrower with your KYC/OFAC screening results attested.

​
Step 2: Report the underwriting decision via Application

Applications are always reported in a terminal status — approved, declined, or canceled. Lead does not require you to report in-flight applications. Declines require the adverse-action fields.

​
Step 3: Open the Account

Created in an active status, and references the Application object created in the prior step. (Note: today this is the Account API; its unified-model successor is the User Account API — Platform Evolution.)

​
Step 4: Define the loan using a Balance

Decision point: For non-revolving credit products, several terms are required up front: expected_maturity_date, max_funding_amount, term, and the repayment schedule.
For revolving credit products, fewer terms are required up front. See more about the two structures at Lending Overview.
(Note: the Subledger Balance API’s unified-model successor is the User Credit Balance API — Platform Evolution.)

​
Step 5: Draw the principal with Funding

Principal decomposes into external_disbursement_amount, withheld_amount, and merchant_origination_fee_amount. Decision point: Based on your product’s funds flows, you will use some subset of these three components. For many programs, the entire loan amount is submitted as external_disbursement_amount.
Once Lead has made the funds available in your Funding FBO, you will receive a funding.posted webhook. When it fires, the principal is in your Funding FBO ready to disburse, and the receivable this draw creates on Lead’s books enters your program’s hold period.

​
Step 6: Check Instant Payment reach before promising instant funds to your end-user

Decision point: build this into the UX before the borrower chooses instant disbursement. If the borrower’s bank can’t receive, fall back to ACH from the same FBO — same funds, slower rail — rather than failing the loan.

​
Step 7: External disbursement

Design for finality: instant sends are irrevocable. Track two lifecycles — the payment’s status to posted, then counterparty_status for when the borrower’s bank has actually credited the funds. Tell Maya “sent” and “delivered” separately.

​
Step 8: Purchase the day’s receivables

Each business day, the receivables that have cleared your program’s hold period are grouped into a single sale — the day’s purchase of loans from Lead, priced per how settlement amounts work (principal plus imputed interest for the hold period). Today you acknowledge the purchase through the Sales Request/Response file exchange over SFTP (Sales File schema); the settlement amount moves from your settlement account. This cycle is not optional — it’s how the loans you originate become yours — so build it as a daily operational rhythm from day one, including the empty-day case. Note: upcoming Sale API The planned Sale API replaces the file exchange with a daily sale object you review and accept in a single call, with acceptance settling the funds (Platform Evolution). The cycle’s shape — daily grouping, whole-day purchase, settlement — is unchanged; build your reconciliation against the day’s sale as a unit, not against file mechanics. For funding-based programs the API successor lands together with the unified-model migration.

​
Handling exceptions

​
Testing this flow in sandbox

The origination chain runs end-to-end in sandbox: POST /v0/fundings//advance to simulate the funding posting, and the five instant-payment simulators for the disbursement leg including all three return-request outcomes (Environments & testing). Reconcile a sandbox run using the payment identifiers (end_to_end_id, transaction_id, uetr). Servicing files can be validated against the File Reference schemas before production submission. Balances & Transactions (servicing) · Funding & Receivables · Instant Payments · Originate Your First Loan (full payloads) · Run a credit or charge card program (revolving credit and card receivables) · Executing vs. reporting If something in this guide doesn’t match what you see, contact your Lead team.