> ## Documentation Index > Fetch the complete documentation index at: https://docs.lead.bank/llms.txt > Use this file to discover all available pages before exploring further. # Instant Loan Origination and Disbursement > Originate a term loan or line of credit, disburse instantly over FedNow, and run the daily servicing and receivables-purchase cycles. 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** | Object | Surface | Role in this flow | Reference | | ------------------------------- | ------------------------ | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Entity | user | Maya, with Lakeshore's KYC/OFAC results attested | [Entity endpoints](/api-reference/endpoint/entity/create-an-entity) | | Application | user | The terminal underwriting decision | [Applications endpoints](/api-reference/endpoint/application/create-an-application) | | Account | user | Maya's credit relationship with Lead (credit\_with\_underwriting) | [Accounts endpoints](/api-reference/endpoint/account/create-an-account) | | Balance | user | The loan's terms and position (type: credit) | [Subledger Balance endpoints](/api-reference/endpoint/subledger-balance/create-a-subledger-balance) | | Funding | execution | Draws principal from a Lead GL into the Funding FBO | [Funding endpoints](/api-reference/endpoint/funding/create-a-funding) | | Funding FBO | core | The Lead-managed account the principal lands in | [Banking Infrastructure](/products/banking-infrastructure/overview) | | Instant Payment | execution | The disbursement to Maya's external account | [Instant Payments endpoints](/api-reference/endpoint/instant-payment/create-an-instant-payment) | | Daily sale (receivables) | execution *(file today)* | Your purchase of the receivables Lead originated | [Sales File schemas](/file-reference/sales/request-schema) | | Balance / Transaction reporting | user *(file today)* | Your daily servicing report — repayments, interest, fees | [Balance](/file-reference/balances-and-transactions/balances-schema) & [Transaction](/file-reference/balances-and-transactions/transactions-schema) File schemas | ## **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](/file-reference/balances-and-transactions/balances-schema). API successors are planned for both — user balance/transaction APIs and a sale API that tells you when a sale is generated ([Platform Evolution](/core-concepts/platform/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](/core-concepts/platform/platform-evolution)). ## **Integration steps** ### **Step 1: Create the borrower Entity** Report the borrower with your KYC/OFAC screening results attested. ```text theme={null} POST /v0/entities { "type": "individual"... } ``` ### **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. ```text theme={null} POST /v0/applications { "status": "approved"... } ``` ### **Step 3: Open the Account** ```text theme={null} POST /v0/accounts { "capabilities": ["credit_with_underwriting"], "application_id": "...", "entity_id": "..." } ``` 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](/core-concepts/platform/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](/api-reference/endpoint/subledger-balance/create-a-subledger-balance). ```text theme={null} POST /v0/subledger_balances { "type": "credit", "structure": "non_revolving", "max_funding_amount": 200000, "...": "..." } ``` *(Note: the Subledger Balance API's unified-model successor is the User Credit Balance API — [Platform Evolution](/core-concepts/platform/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. ```text theme={null} POST /v0/fundings { "subledger_balance_id": "...", "external_disbursement_amount": 200000, "withheld_amount": 0, "merchant_origination_fee_amount": 0 } ``` 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** ```text theme={null} POST /v1/instant_payments/check_availability { "routing_number": "..." } ``` **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** ```text theme={null} POST /v1/instant_payments { "amount": 200000, "debtor": { "account_id": "your Funding FBO" }, "creditor": { "...": "borrower's external account" } } ``` 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](/products/funding-and-receivables/sales-settlement-amount) (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](/file-reference/sales/request-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](/core-concepts/platform/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** | What happens | Signal | What to do | | ------------------------------------------------ | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Application declined | Your own decision | Report it with adverse-action fields via Application — declines are reported too, not skipped. | | Instant payment rejected | status → rejected; rejection.rejected\_by | Lead, network, or counterparty — retry/repair logic differs by which. | | Sent in error / fraud-induced send | Your own decision | POST /v1/instant\_payments/{id}/request\_return; the only recourse, and it's a request, not a recall. | | Insufficient funds for the day's receivable sale | Settlement failure on the sale cycle | Fund your settlement account and re-run the acknowledgment; the day's purchase settles whole, so treat settlement-account funding as a daily pre-check, not a reaction. | ## **Testing this flow in sandbox** The origination chain runs end-to-end in sandbox: POST /v0/fundings/{id}/advance to simulate the funding posting, and the five instant-payment simulators for the disbursement leg including all three return-request outcomes ([Environments & testing](/core-concepts/platform/environments-and-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](/file-reference/overview) schemas before production submission. ## **Related** [Balances & Transactions](/products/balances-and-transactions/overview) (servicing) · [Funding & Receivables](/products/funding-and-receivables/overview) · [Instant Payments](/products/instant-payments/overview) · [Originate Your First Loan](/get-started/quickstart/originate-your-first-loan) (full payloads) · [Run a credit or charge card program](/guides/issue/credit-and-charge-card-program) (revolving credit and card receivables) · [Executing vs. reporting](/core-concepts/platform/executing-vs-reporting) *If something in this guide doesn't match what you see, contact your Lead team.*