> ## 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. # Lending and Overdraft > How to exchange information with Lead to support lending (term loans and lines of credit) or overdraft programs. All content discussed on this page is oriented towards partners utilizing the latest version of the product as of Q1 2026. If you have questions about whether this content is relevant for your program, reach out to your Technical Account Manager. Lead offers two balance sheet models: Originate-to-Sell and On-Sheet Lending. Both models follow the same general data flow described on this page, which is written from an Originate-to-Sell perspective. If your program uses On-Sheet Lending, see the [On-Sheet Lending](#on-sheet-lending) section below for the differences. ## Concepts The following data objects are core to how lending and overdraft products are represented in Lead’s system. Below is a product-specific overview. For product-agnostic definitions, see the [Data Objects](/file-integrations/data-objects) page. ### [Entity](/api-integrations/entity/overview) Represents the legal person or organization receiving the lending or overdraft product. An **Entity** must exist before any product can be provisioned (unless one has already been created for the person or organization). ### [Application](/api-integrations/applications/overview) Captures data collected during the application process to support credit regulatory requirements. Example fields include: * Application decision * Adverse Action Notice (AAN) timestamps * Credit bureau data An **Application** is required for all lending products except **courtesy overdraft**. ### [Account](/api-integrations/accounts/overview) Stores compliance and program-level information associated with the product offered to the Entity. All lending and overdraft products require an **Account**. Example fields include: * Credit limit * Available credit * SCRA / MLA indicators ### Balance (also referred to as [Subledger Balance](https://docs.lead.bank/api-reference/endpoint/subledger-balance/create-a-subledger-balance)) Represents the outstanding amount owed by the Entity. Each Balance maps 1:1 to a term loan, line of credit, or overdraft product. All Balances for these products have a `type` of **credit**, as they track amounts owed. In some interfaces this object is labeled **Subledger Balance**. Future versions will standardize the name to **Balance**. Balances support two structures: * Non-Revolving (e.g., Term Loan) * Behavior: Fixed principal; repayments do not restore available credit. * Lifecycle: A new Balance is created per loan and closed upon reaching a terminal status. * Revolving (e.g., Line of Credit) * Behavior: Subject to a credit limit; repayments restore available credit. * Lifecycle: A single Balance remains open across multiple draws and repayments. ### [Funding](/api-reference/endpoint/funding/create-a-funding) Represents a “draw” against a Balance. A Funding object is your instruction to Lead to fund principal to the borrower. * **Non-revolving Balance (e.g., term loan):** Typically one Funding per Balance. * **Revolving Balance (e.g., line of credit):** Multiple Fundings may occur over the lifetime of a single Balance. ### Receivable Sale Represents the sale of a receivable designated as Originate-to-Sell from Lead to you after the applicable hold period. Example: * A term loan is funded on day **T**. * Lead creates a receivable with the hold period starting on **T**. * At the end of the hold period, Lead initiates a [**Sales Request**](/file-integrations/sales-request-and-response/request-schema) to sell the receivable to you. * You confirm acceptance by responding with a [**Sales Response**](/file-integrations/sales-request-and-response/response-schema), and Lead debits your Operating Account for the sale amount. For details on hold period calculations and settlement mechanics, see [Settlement Amount](/file-integrations/sales-request-and-response/settlement-amount). ## Data Flow This illustrative example is for an Originate-to-Sell program and assumes a hold period of two business days, meaning Lead holds each receivable for two business days before selling it. ```mermaid theme={null} %%{init: {'theme': 'base', 'sequence': {'messageMargin': 40}, 'themeVariables': {'background': '#ffffff', 'noteBkgColor': '#ffffff', 'noteBorderColor': '#000000', 'actorBkg': '#ffffff', 'actorBorder': '#000000', 'actorLineColor': '#cccccc', 'sequenceDiagramBackground': '#ffffff', 'mainBkg': '#ffffff', 'signalColor': '#000000', 'labelBoxBkgColor': '#ffffff', 'loopTextColor': '#000000'}}}%% sequenceDiagram participant Borrower participant Program participant Lead rect rgb(255,255,255) Note over Borrower,Lead: Day T (Mon) Borrower->>Program: Opts in to credit product Program->>Lead: Create Entity (via Entity API) Program->>Lead: Create Application (via Applications API) Program->>Lead: Create Account (via Accounts API) Program->>Lead: Create Subledger Balance (via Create Subledger Balance API) Program->>Lead: Create Funding in processing status (via Create Funding API) Note over Lead: Execute funding in near real-time Lead->>Program: Webhook — Funding posted Program->>Borrower: External disbursement (via Lead's Payment Rail APIs) end rect rgb(255,255,255) Note over Borrower,Lead: Day T+1 (Tue) Program->>Lead: Create Disbursement Transaction (via Transactions File) Program->>Lead: Update Balance (via Balances File) Borrower->>Program: Repays portion of borrowed amount end rect rgb(255,255,255) Note over Borrower,Lead: Day T+2 (Wed) Program->>Lead: Create Payment Transaction (via Transactions File) Program->>Lead: Update Balance (via Balances File) Lead->>Program: Request to sell Receivable (via Sales Request File) Program->>Lead: Confirm purchase of Receivable (via Sales Response File) end rect rgb(255,255,255) Note over Borrower,Lead: Day T+N (until Balance closed) Program->>Lead: Create Payment Transaction (via Transactions File) Program->>Lead: Update Balance (via Balances File) end ``` In Sandbox, there is an additional step required to advance the Funding object to a `posted` status. After calling the [Create a Funding](https://docs.lead.bank/api-reference/endpoint/funding/create-a-funding) endpoint, call the [Simulate Advance Funding](https://docs.lead.bank/api-reference/endpoint/funding/advance-a-funding) to transition the Funding object to a `posted` status. ## Process ### **Day T (e.g., Monday)** Borrower applies for or opts in to a lending or overdraft product with the fintech program. Program calls the [Entity API](https://docs.lead.bank/api-reference/endpoint/entity/create-an-entity) to create an Entity object representing the end-user. Program calls the [Application API](https://docs.lead.bank/api-reference/endpoint/application/create-an-application) to create an Application object. A non-lending overdraft product (e.g., courtesy overdraft) will not require an Application object and this step can be skipped. A successful Application API call requires one or more valid Entity IDs (returned via the Entity API call above). Program calls the [Account API](https://docs.lead.bank/api-reference/endpoint/account/create-an-account) to create an Account object. A successful Account API call requires one or more valid Entity IDs (returned via the Entity API call above). If the product requires an application, the Account API will additionally require a valid Application ID (returned via the Application API call above). Program calls the [Subledger Balance API](https://docs.lead.bank/api-reference/endpoint/subledger-balance/create-a-subledger-balance) to create a Subledger Balance object. A successful Subledger Balance API call requires a valid Account ID (returned via the Account API call above). Lead API returns a 200 response indicating success. At this stage, the product has been created with a zero-dollar balance (i.e., no amount is owed by the end-user yet) and is ready to be funded. Program calls the [Funding API](https://docs.lead.bank/api-reference/endpoint/funding/create-a-funding) to create a Funding object tied to the Subledger Balance. A closed-end, single-draw term loan will have one Funding API call over the lifetime of the Subledger Balance. A closed-end, multi-draw term loan may have multiple Funding API calls over the lifetime of the Subledger Balance. An open-end line of credit will typically have multiple Funding API calls over the lifetime of the Subledger Balance. A successful Funding API call requires a valid Subledger Balance ID (returned via the Subledger Balance API call above).  Lead API returns a 200 response indicating success and the Funding object is in a `processing` status. At this point, Lead has not yet deposited the funds into the Funding FBO. Lead disburses the requested amount to the Funding FBO in near real-time, and the lending or overdraft product has been funded. In Sandbox, the disbursement does not happen automatically. Program calls the [Simulate Advance Funding](https://docs.lead.bank/api-reference/endpoint/funding/advance-a-funding) to transition the Funding object to a `posted` status. No money movement occurs in Sandbox. Lead sends a [webhook](https://docs.lead.bank/api-integrations/webhooks#event-types) to the program's endpoint indicating that the Funding object has transitioned to a `posted` status. This webhook serves as confirmation that Lead has deposited the funds into the Funding FBO. Once the funds are available in the Funding FBO, the program can utilize Lead’s payment rail APIs (e.g., ACH, Wire, Fednow) to execute the next leg of the disbursement. ### **Day T+1 (e.g., Tuesday)** Program reports Day T's funding in the [Transaction File](https://docs.lead.bank/file-integrations/balances-and-transactions/transactions-schema) (type: `disbursement`). For transactions where `type` = `disbursement` and `transfer_type` = `internal_transfer`, the `fee_amount` must equal the `other_fees.borrower_origination_fee_amount` on the associated Funding object. Program reports Day T end-of-day Subledger Balance values in the [Balance File](https://docs.lead.bank/file-integrations/balances-and-transactions/balances-schema). Borrower repays a portion of their owed principal by sending funds to the fintech program. This step is included as an illustrative example only to demonstrate how repayments should be reported in Transaction and Balance Files. Not all products can have repayments happen at this stage in the product's lifecycle. ### **Day T+2 (e.g., Wednesday)** Program reports Day T+1 repayment in the [Transaction File](https://docs.lead.bank/file-integrations/balances-and-transactions/transactions-schema) (type: `payment`). Program reports Day T+1 end-of-day Subledger Balance in the [Balance File](https://docs.lead.bank/file-integrations/balances-and-transactions/balances-schema). As the two business day hold period has completed, Lead creates a request to sell the receivable to the program by posting a [Sales Request File](https://docs.lead.bank/file-integrations/sales-request-and-response/request-schema) to the shared SFTP. Program accepts (or rejects) the receivable sale by posting a [Sales Response File](https://docs.lead.bank/file-integrations/sales-request-and-response/response-schema) to the shared SFTP. Upon receipt, Lead debits the program’s Operating Account for the sale amount. ### **Day T+N (until the Balance reaches a terminal status)** Program submits daily [Transaction Files](https://docs.lead.bank/file-integrations/balances-and-transactions/transactions-schema) to reflect all repayment activity on the prior day. Program submits daily [Balance Files](https://docs.lead.bank/file-integrations/balances-and-transactions/balances-schema) to reflect all end-of-day (EOD) balances on the prior day. ## On-Sheet Lending **Preview** — On-Sheet Lending is an upcoming product offering. Reach out to your Lead Technical Account Manager to learn more about the offering and when and how your program can enable it. In the On-Sheet Lending (OSL) model, Lead originates the receivable and holds it on its own balance sheet until the loan reaches a terminal status, such as paid in full or charged off. Lead and your organization agree on the balance sheet model for your program at contract signing. The table below summarizes the differences between the two supported models. | | Originate-to-Sell (OTS) | On-Sheet Lending (OSL) | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Receivable ownership | Lead holds the receivable from origination through the hold period, then transfers ownership to the partner via the Sales Request / Response exchange. The partner holds the receivable through its terminal status (e.g., paid in full, charged off) | Lead holds the receivable from origination through its terminal status (e.g., paid in full, charged off) | | Sales Request file | Lead posts the file containing receivables to sell to the partner after the hold period | Lead still posts the Sales Request file, but it contains no on-sheet receivables | | Sales Response file | The partner confirms the purchase of the receivables in the Sales Request file | The partner still submits the Sales Response file, but it contains no receivable entries | ### How the Sales Files Differ Under OTS, Lead originates a receivable and holds it for the hold period, then posts a Sales Request file instructing you to purchase it. You confirm acceptance by submitting a Sales Response file, and Lead debits your Operating Account for the sale amount. Under OSL, Lead retains all receivables on its balance sheet — there are no receivables to sell. Lead still posts Sales Request files and you still submit Sales Response files on the same schedule, but neither file will contain on-sheet receivables. This file exchange serves as confirmation that Lead is holding the receivable rather than transferring ownership to you. Outside of the Sales Request and Response files, all other API or file interfaces work identically under both models.