Blog Post
Ensuring Data Integrity Between Switch and Core Banking Systems
The heartbeat of any bank is the interaction between its Payment Switch (like Postilion, Base24, or a cloud switch) and its Core Banking System (like T24 or Flexcube). The Switch authorizes traffic; the Core keeps the ledger. In a perfect world, these two systems would always agree. In reality, network latency, timeouts, and software bugs cause them to drift apart every day. This drift, if left unchecked, results in "Ghost Transactions" where money leaves the bank but stays on the customer's account ledger. This guide explains how to close the gap.
The Danger Zone: Timeouts and Reversals
The most common failure scenario is the Timeout.
1. Customer swipes card.
2. Switch sends debit request to Core.
3. Core processes debit but the response gets lost in the network.
4. Switch times out and sends a "Decline" to the POS terminal.
5. Result: Customer walks away without goods, but their account is debited.
To fix this, the Switch should send a "Reversal" (ISO 8583 message type 0420). But what if the Reversal also fails? You now have a permanent discrepancy.
Store-and-Forward (SAF): The Delayed Truth
Sometimes, the Core system goes offline for maintenance (COB). The Switch goes into "Stand-In" mode, authorizing transactions based on cached limits. These transactions are stored in a Store-and-Forward (SAF) queue to be posted later.
The Risk: If the SAF queue jams or files are corrupted during upload, thousands of transactions may never hit the ledger. Reconciliation software acts as the safety net, verifying that every SAF transaction was successfully booked.
Best Practices for Reconciliation
To ensure integrity, you need a robust matching strategy.
1. Key Linking Fields
Never match on Amount and Date alone. You must match on unique identifiers.
RRN (Retrieval Reference Number): The gold standard. Usually unique for 24 hours.
STAN (System Trace Audit Number): Useful, but resets frequently.
PAN (Card Number): Use masked PAN (last 4 digits) combined with RRN for high accuracy.
2. Handling Advice Messages (0220)
Financial "Advice" messages are offline notifications of a transaction. Ensure your reconciliation tool can distinguish between a "Request" (0200) and an "Advice" (0220) to avoid double-counting if both are present in the logs.
3. Automated 3-Way Matching
The ultimate check is the "Triangle":
1. Switch Log: What we told the network.
2. Core Ledger: What we booked internally.
3. Network File (Visa/Mastercard): What actually settled.
If all three agree, the transaction is undeniable. If any leg disagrees, Reconwizz flags it immediately.
Conclusion: The Zero-Trust Model
In banking operations, you cannot trust that "System A talked to System B." You must verify it. By automating the reconciliation between your Switch and Core, you catch technical failures (like dropped packets or logic errors) before they become financial losses. This ensures your normalized data is not just clean, but accurate.