Card Issuing Reconciliation, Interchange Economics, & Network Settlement
Architecting multi-way matching across cardholder ledgers, issuer processors (Marqeta, Galileo, Lithic), and payment network clearing files.
Dual-Message Mechanics: Auth vs Presentment vs Clearing
When a cardholder swipes, the issuer processor authorizes the transaction, reducing available balance while leaving ledger balance unchanged. Days later, presentment files arrive from Visa (Base II clearing) or Mastercard (IPM clearing) with the final settlement amount. Issuers must match presentments back to original authorization IDs and release expired authorization holds automatically.
Interchange Income Calculation and Fee Verification
Card issuers earn interchange income based on intricate network rate tables determined by merchant category code (MCC), card product type (consumer debit, commercial prepaid), entry mode (e-commerce token vs chip), and transaction size. Reconciling issuing revenue requires validating network fee statements against expected contract tiers.
Continuous Card Issuer Balance Invariants with NAYA
The NAYA Proof Engine ingests authorization webhooks, daily clearing files, and sponsor bank settlement wires. It enforces strict mathematical invariants across cardholder ledger balances, processor suspense accounts, and bank reserves, emitting comprehensive proof packs for sponsor bank compliance.
Frequently Asked Questions
Common questions about this topic
QWhat is "Interchange++"?
A pricing model where fees are broken down transparently (Interchange + Scheme Fee + Acquirer Fee). It is harder to reconcile than "Blended" pricing but offers better margins.
QHow do you handle FX on cards?
The Scheme converts the currency. The settlement file shows the amount in the Issuer's currency. The Scheme charges an FX markup, which must be validated against the rate table.
Get technical insights weekly
Join 4,000+ fintech engineers receiving our best operational patterns.