A practitioner’s notes on financial infrastructure
At the close of the authorization flow, the Cardholder walked out of the Tokyo coffee shop (Merchant) with a $5 latte. The Ohio Credit Union (Issuer) executed a soft-post, reserving $5 on the Cardholder’s credit limit.
But the Merchant’s Demand Deposit Account (DDA) at their local bank is still exactly $0.00. The ISO 8583 0100/0110 exchange was strictly a distributed state synchronization to guarantee funds; it was not a financial settlement.
Once the Cardholder leaves, the system constraint flips. We no longer care about the 2-second SLA. The engineering focus shifts to guaranteed delivery, idempotency, double-entry bookkeeping, and capital efficiency.
To move actual fiat, the architecture abandons real-time synchronous APIs and pivots to bulk asynchronous file processing.
Step 1: The Capture (Closing the Auth State)
An authorization (0100) is a reservation with a Time-To-Live (TTL). If the Merchant doesn’t finalize it, the Issuer’s core banking system will age out the soft-post (usually in 5-7 days) and return the $5 to the Cardholder’s available_credit.
Before end-of-day, the Merchant’s POS system sends a Capture message (ISO 8583 MTI 0200 or 0220) to the Payment Gateway. This message references the original transaction using the STAN and RRN generated during the auth sprint.
- System State Change: The Gateway/Processor marks the transaction as CAPTURED in its database. It is now eligible for financial settlement. If this message is lost, the Merchant’s integration must have a cron job to poll for PENDING_CAPTURE states and retry (idempotency keyed on the RRN).
Step 2: Clearing (Asynchronous Reconciliation)
The Acquirer now needs to tell the Issuer exactly what it owes them. They do not do this via synchronous API calls. They use batch file exchanges.
Depending on the region and network, this involves pushing massive, fixed-width flat files (e.g., VisaNet BASE II files, or Mastercard ICS files) over SFTP or dedicated AS2 connections.
These files contain hundreds of thousands of captured 0220 records. When the Card Network receives the Acquirer’s file, it performs Netting Calculation. It applies the complex fee matrices:
- Interchange: E.g., 2.10% + $0.10 owed to the Issuer.
- Assessment: E.g., 0.14% owed to the Card Network.
- Acquirer Margin: E.g., 0.05% retained by the Acquirer.
The Network generates a corresponding file and sends it to the Issuer.
The Reconciliation Nightmare: The Issuer’s back-office systems ingest this file and attempt to match it against their internal CAPTURED auth ledger. They match on PAN, RRN, and Amount.
- Match: Ready for settlement.
- No Match (Orphan): The Issuer’s system flags an exception. Was the capture message lost? Did the Acquirer send the wrong RRN? Automated reconciliation engines spend millions of compute cycles resolving these 0.01% edge cases before settlement can occur.
Step 3: Settlement (Macro Capital Movement)
Once clearing files are reconciled, actual money must move between the Acquirer’s bank and the Issuer’s bank.
Moving $5 at a time via SWIFT or Fedwire is an anti-pattern; the overhead and liquidity drain would collapse the system. Instead, the Card Network operates a central Net Settlement Service.
At the end of the settlement window, the Network calculates the net position across all participants.
- If the Issuer (Ohio) is owed a net $10 million across all its global transactions today…
- And the Acquirer (Tokyo) owes a net $10 million…
The Network doesn’t move $10 million. It simply zeroes out the positions in its central ledger.
In reality, there is a “Settlement Bank” (usually a massive tier-1 bank like JPMorgan) sitting under both the Acquirer and Issuer. The Network instructs the Settlement Bank to move only the net delta between the Acquirer’s settlement account and the Issuer’s settlement account via a single bulk wire or central bank RTGS (Real-Time Gross Settlement) transfer.
Step 4: Funding the Merchant (Eventual Consistency)
The Acquirer now has the funds in their settlement account. The final step is paying the Merchant.
The Acquirer runs a nightly batch job against its merchant ledger. For the Tokyo coffee shop, it sums all captured transactions, subtracts the Merchant Discount Rate (MDR = Interchange + Assessment + Acquirer Margin), and calculates the payout:
- Gross Volume: $2,000
- MDR (e.g., 2.29%): -$45.80
- Net Payout: $1,954.20
The Acquirer generates an ACH batch file (or the Japanese equivalent, a Zengin file) and pushes it to the Merchant’s local bank. Because this relies on domestic batch rails, the funds land in the Merchant’s DDA on a T+1 or T+2 basis.
The Architecture of Eventual Consistency
If you map the entire lifecycle, card payments are a masterclass in CQRS (Command Query Responsibility Segregation) and Eventual Consistency.
- The Sync Layer (Command): Optimized for UX. It guarantees that the intent to pay is recorded and funds are reserved (available_balance -= 5).
- The Async Layer (Event/Query): Optimized for financial truth. It processes the resulting events (Capture files, Clearing files) to slowly, methodically align the independent ledgers of the Merchant, Acquirer, Network, and Issuer.
The green checkmark on the POS terminal isn’t a database commit confirming a funds transfer. It is a highly optimized UI state designed to buy the backend systems the 48 hours they need to execute perfect double-entry bookkeeping across four disconnected financial institutions.