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.

​
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 user).

​
Application

Captures metadata collected during the application process. 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 from Lead to you after the applicable seasoning period (i.e., the period during which Lead owns the receivable). Example:
  • A term loan is funded on day T.
  • Lead creates a receivable with seasoning starting on T.
  • At the end of the seasoning period (e.g., T+2), the receivable is sold to you.
  • That individual transfer is represented by a Sale object.
For details on seasoning calculations and settlement mechanics, see Settlement Amount.

​
Data Flow

This illustrative example assumes that the program has a seasoning period of two business days, meaning Lead holds on to all receivables created for two business days before selling them.
Lending And Overdraft Data Flow

​
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 (Coming Soon) 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 (Coming Soon) 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.
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.
10

Send Webhook With Posted Funding Response

Lead sends a webhook (Coming Soon) to the program’s endpoint indicating that the Funding object has transitioned to a posted status.
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).
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 seasoning 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.