Skip to main content
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 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 page.

​
Entity

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

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

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)

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

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 to sell the receivable to you.
  • You confirm acceptance by responding with a Sales Response, and Lead debits your Operating Account for the sale amount.
For details on hold period calculations and settlement mechanics, see 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.
In Sandbox, there is an additional step required to advance the Funding object to a posted status. After calling the Create a Funding endpoint, call the Simulate Advance Funding to transition the Funding object to a posted status.

​
Process

​
Day T (e.g., Monday)

1

Borrower Signs Up for Product

Borrower applies for or opts in to a lending or overdraft product with the fintech program.
2

Create Entity

Program calls the Entity API to create an Entity object representing the end-user.
3

Create Application

Program calls the Application API 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).
4

Create Account

Program calls the Account API 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).
5

Create Subledger Balance

Program calls the Subledger Balance API to create a Subledger Balance object.A successful Subledger Balance API call requires a valid Account ID (returned via the Account API call above).
6

Return Successful Subledger Balance Response

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.
7

Create Funding

Program calls the Funding API 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). 
8

Return Processing Funding Response

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.
9

Execute Funding in Near Real-Time

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 to transition the Funding object to a posted status. No money movement occurs in Sandbox.
10

Send Webhook With Posted Funding Response

Lead sends a webhook 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.
11

Execute External Disbursement

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)

1

Create Disbursement Transaction

Program reports Day T’s funding in the Transaction File (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.
2

Update Balance

Program reports Day T end-of-day Subledger Balance values in the Balance File.
3

Borrower Repays Portion of Borrowed Amount

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)

1

Create Payment Transaction

Program reports Day T repayment in the Transaction File (type: payment).
2

Update Balance

Program reports Day T end-of-day Subledger Balance in the Balance File.
3

Request to Sell Receivable

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 to the shared SFTP.
4

Confirm Purchase of Receivable

Program accepts (or rejects) the receivable sale by posting a Sales Response File 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)

1

Create Payment Transaction

Program submits daily Transaction Files to reflect all repayment activity on the prior day.
2

Update Balance

Program submits daily Balance Files 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 ownershipLead 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 fileLead posts the file containing receivables to sell to the partner after the hold periodLead still posts the Sales Request file, but it contains no on-sheet receivables
Sales Response fileThe partner confirms the purchase of the receivables in the Sales Request fileThe 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.