> ## Content Index > Fetch the complete content index at: https://emrizki.my.id/llms.txt > Use this file to discover other available public pages before exploring further. # What bank switching and ATM flows taught me about reliability - URL: https://emrizki.my.id/writing/atm-bank-switching-reliability/ - Published: 2026-10-13T00:00:00.000Z - Updated: 2026-10-13T00:00:00.000Z - Description: A cash withdrawal looks simple. Following one end to end taught me most of what I know about building systems people can trust. - Author: Muhammad Rizki - Tags: #Import 2026-10-25 12:40 You walk up to an ATM, put in your card, type a PIN, and money comes out. It takes maybe thirty seconds. Most people never think about it again. I spent a good part of my early career thinking about those thirty seconds. I worked on banking systems for Permata and BTN, on bank switching, on Mastercard integration, and on mobile banking features for payments and inquiries. I followed ATM transactions from the card reader all the way to core banking and back. It was the best reliability school I could have asked for. ## The path of one withdrawal Here is a simplified version of what happens. The ATM reads your card and builds a message. That message travels to the acquiring bank, which may not be your bank at all. If it is not, the request goes through a switch, which routes it to the right issuer. The issuer checks the PIN, the balance, the limits and a handful of fraud rules. It approves or declines. The answer travels all the way back. The ATM dispenses cash. Then everyone confirms that it actually happened. Every hop is a place where something can go wrong. A network blip. A timeout. A machine that dispenses but fails to report it. A reversal that arrives before the original. A message that arrives twice. And at every hop, real money is involved. Nobody shrugs off a missing hundred thousand rupiah. ## Lesson one: timeouts are a decision In most software, a timeout is an error. In payments, a timeout is a question with no answer. Did the issuer approve or not? You genuinely do not know. So you need a rule for every possible silence. Do you reverse? Do you retry? Do you hold and reconcile later? Each choice has a cost. Get it wrong and someone is debited without getting cash, or gets cash without being debited. I learned to design the unhappy paths first, because the happy path mostly takes care of itself. ## Lesson two: everything must be idempotent Messages get resent. Networks duplicate things. Operators press buttons twice. A reliable system has to recognise that it has already seen a request and respond the same way, without doing the work again. This sounds obvious. It is surprisingly hard to get right across several systems built by different teams in different decades. The trick is to agree on identifiers early and never, ever reuse them. ## Lesson three: reconciliation is not optional No matter how careful you are, the books will occasionally disagree. The ATM thinks one thing, the switch thinks another, the core banking ledger thinks a third. Banks run reconciliation every day for exactly this reason. I came to see reconciliation as a form of humility. It assumes the system will be wrong sometimes, and builds a calm, routine way to find out and fix it. I wish more modern platforms had that mindset built in from the start, instead of adding it after the first painful incident. ## Lesson four: the boring parts carry the weight Nobody brags about their reversal handling. Nobody gives a conference talk about end of day settlement files. But that is where reliability lives. When I later moved into architecture roles in health tech and telco, I kept looking for the equivalent of those boring parts. Where are the retries? Where is the source of truth? What happens if this message arrives twice, or never? The answers usually told me more about a system than any diagram. ## Lesson five: respect the old systems Core banking platforms are often older than the engineers integrating with them. It is tempting to treat them as a problem. In my experience they are usually the most reliable piece in the chain, precisely because they have been tested by millions of real transactions over many years. Integrating well meant learning their rules, not fighting them. That lesson has stayed with me through every migration since. ## Why it still matters Today I work on large-scale digital transformation and migration, and I use AI agents every day. The context is different, but the questions are the same. What happens on a timeout? Is this safe to repeat? How will we know if the numbers drift? An ATM withdrawal is a small, beautiful example of a distributed system that people trust with their money without a second thought. That trust is earned in the unhappy paths. I try to remember that every time I design something new. Also, I still check my balance after every withdrawal. Old habits.