Payments and Accounts — The Journey of One Transfer
In one line
A bank's systems are divided into three layers — channel, core banking, and information — and a single transfer passes through those layers and the settlement network to be posted to the ledger — that journey may not be complete, which is why closing and reconciliation exist.
Why it was split into three layers
When you first join a bank, you hear things like "that's a core banking matter," "it has to be blocked at the channel," "pull it from the information layer." These three are the names of organizations and also of systems.
| System | Role |
|---|---|
| Channel | Where the bank meets customers: mobile app, internet banking, ATMs, branch terminals, open banking APIs. |
| Core banking | The core that holds accounts and the ledger. The only place that changes balances, and the most conservatively run. |
| Information layer | A replica of core banking used for analysis, reporting, and marketing. A copy, not the original. |
The reason for splitting this way is to isolate load and risk. The channel receives tens of millions of inquiries a day but does not change balances. Core banking changes balances but is protected from inquiry load. The information layer can run heavy aggregations without slowing core banking. In return, there is a price — messages travel between the layers, and that round trip is not always complete.
The journey of one transfer
When a customer taps an interbank transfer in a mobile app, roughly this happens.
- The channel layer checks authentication and limits and sends a withdrawal request message to core banking.
- Core banking checks the balance of the withdrawing account and records the withdrawal in the ledger.
- The bank sends a deposit request to the receiving bank through the shared network of the Korea Financial Telecommunications and Clearings Institute.
- The receiving bank deposits into the recipient's account and responds. For the customer, it is a matter of seconds up to here.
- Actual money movement between banks is not done case by case. A day's worth is collected, the net difference is calculated, and settlement is made between each bank's current accounts opened at the Bank of Korea, through the Bank of Korea's financial network. This is net settlement, and in practice it takes place at a set time on the next business day.
One important fact in this structure: there is a period in which the recipient has already received the money but settlement between banks has not yet finished. What happens if a bank collapses in between is settlement risk, and that is why the Bank of Korea manages collateral and limits.
Ledger, closing, and consistency
The core banking ledger is a record of transactions accumulated in time order, and the balance is their sum. For performance, a balance column is kept on each account, but it is a copy. When the day ends, the daily close runs, finalizes that day's transactions, and rolls over the accounting date. After the close, no more transactions can come in with that day's date, so transactions after the cutoff time are posted to the next business day.
The core procedure of the close is reconciliation. You check whether these pairs match: what the channel answered as success against what was posted to the ledger, our ledger against the counterparty's settlement file, and the balance column against the ledger sum. The forms a mismatch takes are a fixed few.
| Mismatch | What happened |
|---|---|
| Only in the channel | The response went out but posting to the ledger failed. The customer believes it went through. |
| Only in the ledger | It was posted to the ledger, but the response was late and the channel recorded a timeout. The customer thinks it failed and presses again → a duplicate transaction. |
| Different amount | A message parsing, digit, or currency unit problem. Rare, but it lingers the longest. |
| Only the balance differs | Someone edited the balance column without a ledger entry. That is not a correction but an incident. |
Corrections have rules too. You do not edit or delete ledger rows. A missing transaction is entered as a correcting transaction, and a transaction that went out wrongly is offset with a transaction in the opposite direction. What happened has to remain in order so you can answer customer complaints and audits.
What a systems engineer actually runs into in systems that handle money
What developers are first surprised by in the financial domain is not the business rules but the requirements around time and order.
The day does not end at midnight. Business days and calendar days differ, and transactions after the close time roll over to the next business day. So you must not take the notion of "today" directly from the system time, and there has to be a separate place that manages the business date. If you leave this out, people will each say differently which date a transaction in the few minutes around the close belongs to.
You cannot touch the ledger during the close. If new transactions come in while balances are being finalized, the totals will not match. So during the close window you block writes, or queue what comes in during that time and apply it after the close. If the service has to run 24 hours, the structure becomes one where core banking closes and only the channel stays alive.
In reconciliation, exception handling is the main body. It is the work of matching our ledger with the counterparty's records, and most of it matches automatically; the problem is the few cases that do not match. You separate those with a different amount, those only on our side, and those only on the other side, and who handles each and by when must be fixed. Without this flow, unmatched cases pile up and one day become a big number.
A cancellation is not a deletion. If you delete a wrong transaction, the audit trail breaks. You create one more transaction in the opposite direction to offset it, and link the two transactions. The ledger has to be an append-only book, and only then can the balance at any point in time be recomputed.
Never handle amounts as floating point. The fact that 0.1 + 0.2 is not 0.3 is a problem even at the won level. Store them as integers (the smallest currency unit) or decimal types, and carry the currency and the number of decimal places along with the value.
Time is UTC when stored and the business day when judged. If you mix the two, transactions near midnight are certain to go off.
What really matters in practice
First, a timeout is not a failure. It means the channel did not receive a response, not that core banking did not process it. After a timeout the channel must look up the result to confirm, and must show the customer "processing." If you show "failed," a duplicate transaction results.
Second, retries need an idempotency key. To make sure that the same request arriving twice is posted only once, core banking has to remember the unique reference the channel created. Reconciliation finding duplicate transactions is an after-the-fact measure, and the idempotency key is a before-the-fact measure.
Third, the balance column is not the truth. If they differ, the ledger wins. A trace of the balance having been fixed with an UPDATE is itself an audit finding.
In the next lab you will reconcile the channel log and the ledger directly, find all four of the above kinds of mismatch, and correct them with correcting transactions.