> ## 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.
# Credit or Charge Cards
> How to exchange information with Lead to support credit or charge card programs.
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 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](/file-integrations/data-objects) page.
### [Entity](/api-integrations/entity/overview)
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](/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
### [Account](/api-integrations/accounts/overview)
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](/file-integrations/card-files/schema)
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](/file-integrations/balances-and-transactions/balances-schema)
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 a `type` 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).
For programs with deposit collateral (`type` = `deposit_balance` on the [Collateral Object](https://docs.lead.bank/file-integrations/collaterals/schema)), the collateral deposit balance must contain only funds designated as collateral — any non-collateral funds must be held in a separate, distinct deposit balance.
### [Transaction](/file-integrations/balances-and-transactions/transactions-schema)
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](/file-integrations/balances-and-transactions/transactions-schema).
Transaction files submitted on day T must reflect all activity from the prior calendar day (T-1).
### [Collateral](/file-integrations/collaterals/schema) (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](/file-integrations/network-settlement/overview)
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:
1. **As-is** — if the Issuer Processor already provides the file in a network-generated format (e.g., T461 or T140 for Mastercard)
2. **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
See [Reports](/file-integrations/network-settlement/reports) for the network settlement file formats Lead supports today.
### 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**](/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.
Files submitted to Lead are processed in grouped [workflows](/file-integrations/file-delivery/overview#workflows). The flow below reflects the order in which reports are submitted, not how they are grouped into workflows for processing.
```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 Customer
participant Program
participant Lead
Note over Customer,Lead: Day T-2 (Saturday)
Customer->>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 Card (via Cards File)
Note over Customer,Lead: Day T-1 (Sunday)
Customer->>Program: Transacts on card ($300)
Program->>Lead: Create Balance (via Balances File)
Program->>Lead: Create Collateral, if applicable (via Collaterals File)
Note over Customer,Lead: Day T (Monday)
Program->>Lead: Submit Network Settlement Reports (from Issuer Processor)
Program->>Lead: Create Card Transaction (via Transactions File)
Program->>Lead: Update Balance (via Balances File)
Note over Customer,Lead: Day T+1 (Tuesday)
Program->>Lead: Update Balance (via Balances File)
Customer->>Program: Repays a portion of the credit balance ($15)
Note over Customer,Lead: Day T+2 (Wednesday)
Program->>Lead: Submit 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)
Note over Customer,Lead: Day T+N (until the account is closed)
Program->>Lead: Update Balance (via Balances File)
Program->>Lead: Submit Transactions (via Transactions File)
```
## Process
If your Entity, Applications, or Accounts API requests reference `Documents`, upload them to your SFTP `/documents` folder before making the API call — they must be present in SFTP before they can be referenced.
### **Day T-2 (e.g., Saturday)**
Customer applies for or opts in to a credit or charge card 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 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 and a valid Application ID.
Program submits a [Cards File](https://docs.lead.bank/file-integrations/cards/cards-schema) to Lead to create a Card object associated with the Account.
### **Day T-1 (e.g., Sunday)**
Customer makes a purchase on the card (e.g., \$300), increasing the outstanding balance.
Program submits a [Balance File](https://docs.lead.bank/file-integrations/balances-and-transactions/balances-schema) 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.
If applicable, program submits a [Collateral File](https://docs.lead.bank/file-integrations/collateral/collateral-schema) to Lead to record any collateral associated with the account.
### **Day T (e.g., Monday)**
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](/file-integrations/network-settlement/reports) for supported file formats.
Program submits a [Transaction File](https://docs.lead.bank/file-integrations/balances-and-transactions/transactions-schema) to Lead to report the card transaction (e.g., the \$300 purchase).
Program submits a [Balance File](https://docs.lead.bank/file-integrations/balances-and-transactions/balances-schema) to Lead reflecting the end-of-day Balance after the transaction.
### **Day T+1 (e.g., Tuesday)**
Program submits a [Balance File](https://docs.lead.bank/file-integrations/balances-and-transactions/balances-schema) reflecting the end-of-day Balance from Day T.
Customer repays a portion of the outstanding balance (e.g., \$15).
This step is included as an illustrative example to demonstrate how repayments should be reported in Transaction and Balance Files.
### **Day T+2 (e.g., Wednesday)**
Program submits a [Transaction File](https://docs.lead.bank/file-integrations/balances-and-transactions/transactions-schema) to Lead to report the Day T+1 repayment (type: `payment`).
Program submits a [Balance File](https://docs.lead.bank/file-integrations/balances-and-transactions/balances-schema) reflecting the end-of-day Balance after the repayment.
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 account is closed)**
Program submits daily [Transaction Files](https://docs.lead.bank/file-integrations/balances-and-transactions/transactions-schema) to reflect all transaction activity from 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 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.
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.