Introduction
When submitting files to Lead, the system validates records across multiple layers — from field formatting to cross-file reconciliation — to ensure data integrity for regulatory reporting and moving funds between accounts. This page breaks down error types and messages so you can quickly identify, troubleshoot, and resolve issues.Overview of File Validation Errors
The system performs validation in sequential groups. If a file fails in an earlier group, the system does not execute validations in later groups — so the absence of errors in a later group does not mean the file passed those validations. For example, if the balances file fails a validation in group two, group three validations do not run.1. File Integrity
1. File Integrity
2. Record Evaluation in the Same File
2. Record Evaluation in the Same File
3. Record Evaluation Across Files
3. Record Evaluation Across Files
File Integrity
File Integrity checks run first and validate the structure and uniqueness of the file itself, before any field-level or business logic evaluation begins. The system applies the following checks:- Duplicate Detection: Identifies records where every field value in one record is identical to every field value in another record in the same file.
- Duplicate Primary Keys: Validates that each record’s primary key only appears once in the file. For example, in the Accounts schema, the primary key is
client_account_id. - Non-empty Files: Validates that required files are not empty (e.g., network settlement files must have at least one record).
- Single Settlement Date: All records in a network settlement file must share the identical settlement date.
Error Codes
Field Format
Field Format checks validate individual field values in isolation — confirming that each value is correctly entered, properly formatted, and within its allowed constraints before any business logic runs. The system applies the following checks:- Data Type Checks: Validates that the value meets the criteria for that specific data type (e.g. decimal fields should be a decimal, not a string).
- Format Checks: Based on the field, additional validation checks for the semantic meaning of that value, such as ISO 8601 date/datetime formats, US ZIP codes, US state codes, ISO 3166 country codes, and ISO 4217 currency codes.
- Data Constraints: Enforces required field presence, allowed value sets (enums), and maximum string lengths.
- Decimal Place Requirements: Enforces that a decimal has a specific number of decimal places. Most commonly found with fields that represent currencies (e.g. if the balance is in USD, it has two decimal places). Some common variations are:
- Interest/APR rate precision strictly enforced to 3 or 6 decimal places.
amount_in_usdmust always have exactly 2 decimal places.- Minimum or maximum decimal bounds, including special-case decimals for accrued interest.
Error Codes
Field format errors are field-specific and follow predictable patterns tied to each file’s schema. This document does not enumerate individual error codes here because they map directly to schema-level field definitions — the error code itself (e.g.,balance_currency_missing, transaction_effective_at_invalid_format) identifies both the file and the field in question. To understand whether a field is required, along with its format, allowed values, and precision, refer to the schema reference for the file type you are validating.
Business Rules
Business Rules evaluate the meaning and relationships between fields within a single record — going beyond format to ensure the data is internally consistent and logically valid. The system applies the following checks:- Polarity: Validates that the sign of the amount field in the Transactions File is consistent with the transaction type, transfer type, and applied field.
- Component Constraints: Enforces non-zero amounts only on applicable types for principal, interest, and fee fields.
- Relational Rules:
- Balance Composition: Enforce that a top-level amount is fully and correctly broken down into its components. Amount = Principal + Interest + Fee
- Status Pairing: Ensures valid
statustostatus_reasonpairings (e.g., in the Accounts schema, a “closed” status must pair withentity_closed,client_closed, etc.). - Past Due Consistency: All four past-due fields must be completely present or completely absent.
- Balance Constraints: Dispute or charge-off balances must be ≤ the main balance.
- Repayment Details: Type and frequency are strictly required when the program structure demands it.
- Commercial Accounts:
authorized_signersare required whenaccount_holder_type= commercial
- Timestamp Ordering: Timestamps must follow a logical ordering sequence. For example, a record cannot be updated before it is created
Error Codes
Accounts
Balances
Transactions
Collaterals
Program Configuration
Program Configuration checks verify that submitted records are consistent with your program’s specific setup — such as eligible transaction types, supported currencies, and required bank account identifiers. These rules vary by program, so not all of the following checks may apply to you. The following checks are applied:- Allowed Transactions: Validates allowed transaction types, transfer types, and fee types per your specific program (credit, deposit, or funding).
- Settlement Accounts:
client_settlement_bank_account_idmust match one of the bank accounts established in the program’s configuration. - Funding Constraints: Funding programs must use the Credit balance type, USD currency, and omit the
client_balance_id. - Multi-Currency Exceptions: Multi-currency programs have relaxed settlement currency matching, but
amount_in_usdis required.- Settlement Currency: Must equal the transaction currency, unless the program is configured to support multiple currencies.
- Conditional Fields: Certain fields are conditionally required depending on if your program is a non-funding type.
funding_idrequirements depend on the transaction type and your program configuration.
How to Resolve
Because these validations depend on your specific program configuration managed by Lead, you cannot resolve them independently.Contact your Technical Account Manager to confirm which validations apply to your program.
Cross-File Reconciliation
Cross-File Reconciliation checks run last and compare data across multiple files or against prior successful submissions — ensuring consistency over time and across related records. These checks only run after the file passes all earlier validation categories. The following checks are applied:- Continuity: Balances that are not in a closed status from yesterday’s file must appear in today’s file.
- Existence: All foreign keys correctly reference an existing object. For example, in the Transactions file, the
balance_idandcard_idmust be existing Objects. - Daily Balance Checks: Ensures that today’s balance (T) equals yesterday’s balance (T-1) plus today’s daily activity. This is verified for the overall balance, and independently for principal, interest, fees, dispute, charge-off, and rewards components.
- Card Network Settlement Matching: The sum of transaction amounts per network must equal
network_settlement.TransactionAmount. This applies to refunds as well. - Duplicate Protection: Prevents the reuse of transaction IDs across files.

