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 credit and charge card 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 credit or charge card 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
Account
Stores compliance and program-level information associated with the credit or charge card product offered to the Entity. Example fields include:- Credit limit
- Available credit
- SCRA / MLA indicators
Card
Represents the physical or virtual card issued to the Entity. A Card is associated with an Account and tracks card-level details such as card status, card type, and network.Balance
Represents the outstanding amount owed by the Entity on the credit or charge card product. A Balance tracks the current statement balance, available credit, and any adjustments resulting from purchases, payments, or fees. All credit and charge card products have a Balance with atype of credit, as these balances track the amount owed by the end-customer. For secured card products, the account will also have an associated Balance with a type of deposit, representing the security deposit held as collateral.
Balance files submitted on day T must reflect all end-of-day balances from the prior calendar day (T-1).
Transaction
Represents an individual transaction posted to the card account. Transactions capture activity such as purchases, payments, fees, and adjustments, and are reported to Lead via the Transaction File. Transaction files submitted on day T must reflect all activity from the prior calendar day (T-1).Collateral (if applicable)
Represents any collateral associated with the credit or charge card product, such as a security deposit for a secured card program. Collateral is only applicable for programs that require it.Network Settlement
The Network Settlement file is the source-of-truth input for Lead to know how much money needs to move to settle with each card network for a given settlement date, accounting for the net effects of transactions, refunds, disputes, interchange, and fees. These files typically originate at the Issuer Processor. Programs are responsible for retrieving the file from the Issuer Processor and submitting it directly to Lead in one of two ways:- As-is — if the Issuer Processor already provides the file in a network-generated format (e.g., T461 or T140 for Mastercard)
- Reformatted — if the Issuer Processor provides the file in a different format, you convert it into a network-supported format (e.g., T461 or T140 for Mastercard) before submitting
Receivable Sale
Represents the sale of a receivable designated as Originate-to-Sell from Lead to you after the applicable hold period. Example:- The end-customer swipes their card multiple times, with the transactions settling on day T.
- Lead creates a single receivable aggregating all transactions that settle on T for a given Balance.
- 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.
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.Files submitted to Lead are processed in grouped workflows. The flow below reflects the order in which reports are submitted, not how they are grouped into workflows for processing.
Process
Day T-2 (e.g., Saturday)
Customer Opts In to Credit Product
Customer applies for or opts in to a credit or charge card product with the fintech program.
Create Entity
Program calls the Entity API to create an Entity object representing the end-user.
Create Application
Program calls the Application API to create an Application object.A successful Application API call requires one or more valid Entity IDs (returned via the Entity API call above).
Create Account
Program calls the Account API to create an Account object.A successful Account API call requires one or more valid Entity IDs and a valid Application ID.
Create Card
Program submits a Cards File to Lead to create a Card object associated with the Account.
Day T-1 (e.g., Sunday)
Customer Transacts on Card
Customer makes a purchase on the card (e.g., $300), increasing the outstanding balance.
Create Balance(s)
Program submits a Balance File to Lead to establish a Balance of
type = credit for the account. At this stage, the Balance is created with a zero-dollar amount; the $300 outstanding balance will be reflected on Day T once the transaction settles.If the product is a secured credit card with a deposit collateral, a Balance of type = deposit also needs to be established.Create Collateral (if applicable)
If applicable, program submits a Collateral File to Lead to record any collateral associated with the account.
Day T (e.g., Monday)
Submit Network Settlement
Program retrieves the Network Settlement file from the Issuer Processor and submits it to Lead for all card transactions that settled on Day T. See the Network Settlement Reports for supported file formats.
Create Card Transaction
Program submits a Transaction File to Lead to report the card transaction (e.g., the $300 purchase).
Update Balance
Program submits a Balance File to Lead reflecting the end-of-day Balance after the transaction.
Day T+1 (e.g., Tuesday)
Update Balance
Program submits a Balance File reflecting the end-of-day Balance from Day T.
Day T+2 (e.g., Wednesday)
Submit Payment Transaction
Program submits a Transaction File to Lead to report the Day T+1 repayment (type:
payment).Update Balance
Program submits a Balance File reflecting the end-of-day Balance after the repayment.
Request to Sell Receivable
Lead creates a request to sell the receivable to the program by posting a Sales Request File to the shared SFTP.
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 account is closed)
Submit Transactions
Program submits daily Transaction Files to reflect all transaction activity from the prior day.
Update Balance
Program submits daily Balance Files to reflect all end-of-day balances from 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.
| 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 |