How Money Actually Moves: Tour of the Banking System

Here's the thing nobody tells you upfront: your money doesn't "travel" anywhere.

When you send ₹500 to a friend, nothing physically moves. What actually happens is two numbers change in two different ledgers — your bank reduces a number next to your name, and your friend's bank increases a number next to theirs. That's it. That's the whole trick.

The entire banking system — every rail, every acronym, every "processing" spinner you've ever stared at — exists to answer one question really well:

The rest is just details.

Here's an analogy that makes this click immediately.

Imagine you and a group of colleagues go out after work. Over the course of the evening, money moves in all directions — someone covers the drinks, someone else pays for parking, another person picks up dessert. You could settle each of these the moment they happen, with everyone pulling out their phone every ten minutes. But nobody does that. Instead, you keep a mental tally across the whole evening, and at the end of the night, only the net amounts settle. If Riya owes Arjun ₹800 across four small things, and Arjun owes Riya ₹300 across two others, they don't move ₹1,100 back and forth — Riya just sends Arjun ₹500, once, and the whole evening is squared.

Banks do this with each other at national scale. Your bank and the receiving bank don't move your exact ₹500 the instant you hit send. Instead, a neutral referee — the RBI — keeps a running tally of everything every bank owes every other bank across thousands of transactions, and settles only the net difference periodically.

This is called net settlement, and it's how NEFT works. It's why NEFT isn't instant in the old-school sense — it happens in batches, because the whole point is to net things out first, not move money one transaction at a time.

Now imagine a different scenario: instead of splitting a dinner bill, a company needs to transfer ₹50 lakh to a vendor right now, for a bulk order that ships today, and both sides need absolute certainty it's done — no "we'll settle later," no ambiguity.

For this, you don't net anything. You just move the money immediately, completely, transaction by transaction, with a trusted central authority confirming it instantly. No batching, no waiting, no "what if something fails before settlement."

This is gross settlement — every transaction settles individually, in real time, for its full amount. In India this is RTGS, and it literally stands for Real Time Gross Settlement.

This is also why RTGS has a minimum amount (₹2 lakh). Settling every transaction individually and instantly is expensive plumbing to run — banks have to keep real money parked and ready at all times to guarantee instant settlement. You don't want to use that expensive, instant machinery for a ₹200 transfer. That's not a technical limitation, it's a deliberate design choice — like keeping an armored truck on standby only for high-value pickups, not for the corner store's daily cash.

So now you have two extremes: "settle in batches" (NEFT) and "settle every single transaction immediately" (RTGS). What about everyday people who want to send ₹2,000 to a friend at 11 PM on a Sunday and want it to land in seconds, not in the next batch window?

This is where it gets genuinely clever. IMPS (and UPI underneath it) does something sneaky and smart: it gives you the experience of instant settlement, while the actual bank-to-bank settlement still happens in batches behind the scenes — just like NEFT.

Here's how: NPCI (the organization that runs IMPS/UPI) sits in the middle and effectively says, "I'll personally guarantee this transaction happened, right now, to both banks — even though we'll actually true-up the real money between you two later." It's a trusted intermediary absorbing the timing gap so you don't have to wait for it.

Think of it like a UPI payment at a busy street vendor. You scan, pay, see a green tick, and walk away with your food in ten seconds. The vendor is confident the money is real. But the actual settlement between your bank and the vendor's bank happens quietly in the background, in the next batch cycle. The experience feels instant. The settlement isn't. NPCI's guarantee is what bridges that gap — it tells both banks "this is good, trust it" — and that makes real-time retail payments economically viable at hundreds of millions of transactions a day.

This separation between what the customer experiences as final and what has actually settled between institutions is one of the most important ideas in payments infrastructure — and it becomes even more consequential once software systems, not humans, are the ones initiating transactions.

Everything above assumes both banks are in the same country, talking to the same central referee (RBI). International payments break that assumption completely — there is no single global referee that every bank in every country trusts and reports to.

So how does sending money from Mumbai to New York actually work, if there's no shared boss?

Imagine you want to send a gift to someone in a city where you don't personally know anyone. But you know a neighbor, who knows someone in that city, who knows the recipient. So the gift passes hand to hand through a chain of people who already trust each other, even though you and the final recipient are strangers.

This is precisely how international wire transfers work, through a system called correspondent banking. Your bank doesn't have a direct relationship with the recipient's bank in the US, so it routes the payment through a middleman bank — a "correspondent" — that it does have a relationship with, usually because it already holds an account there. The instruction to move the money travels through a messaging network called SWIFT.

Here's the detail almost everyone gets wrong: SWIFT does not move money. SWIFT is just the messaging system — like a very secure, very formal postal service for instructions. It's the equivalent of a letter saying "please give Sarah ₹500 on my behalf" — the letter itself isn't the money.

The actual money moves separately, leg by leg, through each correspondent bank's local settlement system (their own version of RTGS), often passing through two or three banks before it reaches the final destination. Each hop can take its own sweet time and often takes its own small fee — which is exactly why international transfers are slower and pricier than domestic ones, and why you sometimes see a mysterious "intermediary bank fee" eat into the amount that arrives.

If you're sending dollars and the recipient needs rupees, somewhere in that chain, a bank or financial company has to actually convert one currency into another — and they make money doing it.

There are two ways this typically happens:

The banking system is not a single thing. It is a collection of carefully designed trade-offs — each rail solving a different version of the same problem, each one shaped by a specific set of constraints around speed, certainty, and cost. What looks like a maze of acronyms from the outside is, once you understand the underlying logic, a surprisingly coherent set of decisions made by engineers and policymakers over decades.

This matters because that same logic — net vs. gross settlement, trusted intermediaries bridging timing gaps, the gap between acknowledged and settled — doesn't go away as payments evolve. It gets inherited. Every new layer built on top of these rails, from UPI's virtual address abstraction to the payment protocols being designed for AI agents today, is still solving the same core problem your bank solved when you made your first NEFT transfer: how do you move value between two parties that don't share a ledger, reliably, at scale, without anyone losing money in the gap?

Part 2 of this series goes inside the rails. We'll trace exactly what happens — hop by hop, system by system — from the moment you tap send to the moment money lands, and why each step in that chain exists.