Skip to main content

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

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:
  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 for the network settlement file formats Lead supports today.

Receivable Sale

Represents the sale of a receivable 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.
For details on hold period calculations and settlement mechanics, see Settlement Amount.

Data Flow

This illustrative example assumes that the program has a hold period of two business days, meaning Lead holds on to all receivables created for two business days before selling them.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)

1

Customer Opts In to Credit Product

Customer applies for or opts in to a credit or charge card 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 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 and a valid Application ID.
5

Create Card

Program submits a Cards File to Lead to create a Card object associated with the Account.

Day T-1 (e.g., Sunday)

1

Customer Transacts on Card

Customer makes a purchase on the card (e.g., $300), increasing the outstanding balance.
2

Create Balance

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

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)

1

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

Create Card Transaction

Program submits a Transaction File to Lead to report the card transaction (e.g., the $300 purchase).
3

Update Balance

Program submits a Balance File to Lead reflecting the end-of-day Balance after the transaction.

Day T+1 (e.g., Tuesday)

1

Update Balance

Program submits a Balance File reflecting the end-of-day Balance from Day T.
2

Customer Repays Portion of Balance

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)

1

Submit Payment Transaction

Program submits a Transaction File to Lead to report the Day T+1 repayment (type: payment).
2

Update Balance

Program submits a Balance File reflecting the end-of-day Balance after the repayment.
3

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.
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 account is closed)

1

Submit Transactions

Program submits daily Transaction Files to reflect all transaction activity from the prior day.
2

Update Balance

Program submits daily Balance Files to reflect all end-of-day balances from the prior day.