Anita lost ₹47,000 on a Tuesday afternoon in March.

Someone called claiming to be from the electricity board. Her bill was overdue, they said. If she didn’t pay immediately, they’d cut the connection. She panicked — she works from home, she needs the WiFi — and followed instructions to “verify” her account through a UPI collect request.

Subscribe now

By the time she realized what had happened, the money was gone. She stared at her phone for a few minutes, then did what most people do: she called her bank.

The bank’s customer care line put her on hold for eleven minutes. When someone picked up, they told her to raise a complaint through the app. She asked them to reverse the transaction. They said they couldn’t. She asked who could. They told her to file an FIR, call 1930, and also register a complaint on the cybercrime portal. Three different places. Three different processes. Nobody told her what would happen next or how long any of it would take.

Here’s the thing that tripped Anita up, and trips up almost everyone in her situation: she assumed her bank could just pull the money back. That’s how credit cards work, right? You dispute a charge, the bank reverses it. She thought UPI would work the same way.

It doesn’t. And the reason it doesn’t is the thing most people never learn until they’re already 45 days deep into a process that was never built for their problem.

Last week we talked about fraud detection — the system that tries to stop bad transactions before they happen. This week is about what happens when that system fails. The transaction went through. The money left your account. Now what?

It depends on what kind of “wrong” happened. And most people find out too late that there are two answers, not one.

Two machines, two problems

There are two recovery paths in India’s digital payment system, and they have almost nothing to do with each other. Banks rarely explain this. Most people figure it out only after they’ve spent weeks going down the wrong one.

Machine 1: the chargeback (UDIR)

This is NPCI’s Unified Dispute and Issue Resolution system, launched in 2020. It handles technical problems. Your payment was debited but didn’t reach the merchant. You got charged twice for the same transaction. A payment timed out but the money left your account. In these cases, your bank can initiate a chargeback — a formal reversal request routed through NPCI to the recipient’s bank.

For these technical failures, the system has gotten quite good. Before UDIR, banks communicated through manual, file-based processes. A stuck payment could take days just to begin investigating. Now, many of these cases auto-resolve within hours. NPCI reports resolution times have improved by roughly 50% since UDIR was introduced.

The chargeback path also covers merchant disputes — you paid for something and it never arrived, or the merchant charged the wrong amount. These take longer (turnaround times run up to 30 days for small and offline merchants) but the process exists and broadly works.

Machine 2: the police freeze (CFCFRMS/1930)

This is what you actually need when you’ve been scammed. And it works completely differently.

When Anita sent money to a scammer, she authorized the transaction. She entered her PIN. From the bank’s perspective, this wasn’t a technical failure or a merchant dispute. She voluntarily transferred money to another person’s account. A chargeback can’t help her — her bank legally cannot reach into the scammer’s account and pull the money back from an authorized P2P transfer.

What can help is the 1930 helpline and the CFCFRMS (Citizen Financial Cyber Fraud Reporting and Management System). When you call 1930, the operator sends an emergency freeze request — a lien — to the beneficiary’s bank. Under police authority, that bank freezes whatever funds are still sitting in the account. The goal is to stop the money before it moves further.

But here’s the catch: even if 1930 successfully freezes the funds, getting that money back into your account usually requires a court order. Some states — Gujarat, UP — have set up faster processes through Lok Adalats or nodal police orders. Others haven’t. So “frozen” doesn’t mean “returned.” It means “stuck in a legal process that could take months.”

Anita didn’t know any of this. She walked into her bank expecting Machine 1 (chargeback — reverse the payment) when she actually needed Machine 2 (police freeze — stop the money, then get a court order). Her bank’s customer care agent didn’t explain the difference. Most don’t.

The golden hour

There’s a term that keeps coming up in cybercrime circles now: the golden hour. The I4C (Indian Cyber Crime Coordination Centre) borrowed it from emergency medicine, where treatment within the first 60 minutes after trauma dramatically improves survival. In fraud recovery, the math works the same way.

If you call 1930 within the first hour of losing money, the chances of freezing the funds before they move are reasonably good. After that first hour, they drop off sharply.

Why? Because fraudsters don’t leave money sitting in the account you sent it to. Within minutes, they split the amount across multiple accounts — mule accounts, often opened using rented bank credentials or forged KYC documents. The money gets layered through three, four, five hops and withdrawn as cash from ATMs in a different city. By the time your complaint reaches someone who can act on it the next morning, the account is empty and the trail is cold.

In 2025, the 1930 helpline received 3.24 crore calls. Mumbai’s helpline alone saved roughly ₹202 crore through rapid intervention. Nationally, the CFCFRMS system has saved over ₹7,100 crore across more than 23 lakh complaints since it launched.

Those numbers sound large until you set them against the ₹28,683 crore lost to digital fraud that same year. The system saved roughly a quarter of what was stolen. For every rupee recovered, three disappeared.

And that’s assuming you called at all.

Why half the victims stay quiet

Roughly half of UPI fraud victims never report the fraud. When you first hear that number, the instinct is to wonder what’s wrong with them. Why wouldn’t you report it?

Spend five minutes trying to navigate the reporting process and the number starts making sense.

There’s the shame. Most UPI fraud is social engineering — someone talked you into sending money. You weren’t hacked. Nobody broke into anything. You were convinced. Telling a stranger on a helpline that you fell for a fake electricity board call feels embarrassing, especially when you can hear them thinking “how did you fall for that?”

Then there’s the fragmentation. You’re told to call 1930, file a complaint on cybercrime.gov.in, raise a dispute in your UPI app, and file an FIR at your local police station. Four separate systems. The cybercrime portal asks for your transaction ID, the UTR number, the beneficiary’s VPA — details most people don’t know how to find on a good day, let alone while panicking.

Dvara Research studied the in-app complaint experience across six major UPI apps. Only four of the six even let you raise complaints inside the app. The other two sent you to external helplines. In the apps that did have complaint filing, the option was “placed obscurely in a corner at the top or bottom of the screen,” sometimes hiding behind other options, three taps deep from anywhere you’d naturally look.

And then there’s the math. If you lost ₹2,000 to a fake collect request, you do the calculation: is it worth three hours of my evening navigating a system that probably won’t return the money? For a lot of people, the answer is no. They absorb the loss and move on.

The reporting system was designed by people who understand how it works. It wasn’t designed for the person using it at 11 PM while their hands are shaking.

Anita’s 45 days

Let me walk through what actually happened to Anita after she lost that ₹47,000.

On day one, she called her bank, got told to use the app. She raised a dispute in the app. She also called 1930 and filed a complaint on cybercrime.gov.in. Three complaints, three systems, none of them talking to each other. She went to her local police station to file an FIR. The officer asked if she could come back tomorrow because the person who handles cyber complaints wasn’t in.

By day three she’d filed the FIR and gotten a complaint reference number from 1930. No update from her bank.

Day seven, her bank acknowledged the complaint. “Investigating.” No details on what that meant or what they were investigating.

Two weeks in, she called again. They said a chargeback had been raised with the beneficiary bank. (This was already the wrong tool — chargebacks don’t apply to authorized P2P transfers. But nobody told her that.)

Day thirty: the beneficiary bank responded. The funds had already been withdrawn. The account had been closed. Chargeback declined.

Day forty-five: her bank told her that since the transaction was “authorized” — she had entered her own PIN — they couldn’t process a reversal. They suggested she continue pursuing the case through the cybercrime portal and the courts.

Anita never got her money back.

Meanwhile, the 1930 freeze she’d triggered on Day 1 had actually worked — partially. The system froze about ₹11,000 in the scammer’s account before the rest was moved. But releasing even that ₹11,000 back to Anita required a magistrate’s order, which, three months later, she was still waiting for.

She spent 45 days going through a chargeback process that was never designed for her situation, while the process that could actually help — the police freeze and court recovery — moved on its own, slower timeline with no connection to anything her bank was doing.

This is the standard experience for social engineering fraud on UPI. Not an edge case.

Why chargebacks can’t fix social engineering

The chargeback system was built for a specific world: one where the main dispute is “I didn’t make this transaction” or “I paid a merchant and didn’t get what I ordered.”

In that world, the logic is clean. Either the transaction was authorized or it wasn’t. If it wasn’t, the bank bears liability — RBI’s July 2017 circular on customer protection says that for unauthorized transactions reported within three working days, the customer’s liability is zero. The bank has to credit the amount back within ten working days.

If someone hacks your account, clones your SIM, compromises your device — that’s an unauthorized transaction. The bank pays. And banks invest heavily in preventing this, because it costs them money.

But most UPI fraud doesn’t look like that. Most UPI fraud is social engineering. The caller claiming to be from your bank. The fake KYC update. The “digital arrest” scam where someone impersonates a police officer on video call. The investment group on WhatsApp promising 3x returns.

In every one of these cases, the victim enters their own PIN. The transaction is, technically, authorized. If a hacker breaks into a vault and takes your money, the bank pays. If a scammer politely convinces you to open the vault and hand them the money, you pay. The system only cares that you turned the key. It doesn’t ask whether you were lied to about what was on the other side.

India hasn’t created a mandatory reimbursement framework for this kind of fraud. The UK has — their Payment Systems Regulator made APP (Authorized Push Payment) fraud reimbursement mandatory in October 2024, with the cost split between the sending and receiving banks. Indian consumer advocates have been pushing for something similar. So far, it hasn’t happened.

Until it does, the gap between “unauthorized fraud” (system works) and “authorized fraud under manipulation” (system doesn’t work) is where most of the damage sits.

What’s actually getting better

Some of this is getting better, though.

UDIR has made technical dispute resolution dramatically faster. Double debits, stuck payments, timeout errors — these used to require manual coordination between banks that could drag on for days. Now many resolve automatically within hours. If your payment went out but the merchant says they never received it, the system handles that reasonably well.

The 1930/CFCFRMS layer has created a real-time fraud response that didn’t exist five years ago. The golden hour framework has saved thousands of crores. UP’s Cyber Fraud Mitigation Centre — where police and bank nodal officers sit in the same room — pushed recovery rates from around 25% to nearly 89% between September 2025 and March 2026. The difference wasn’t better technology. It was putting the people who could act in the same physical space and cutting the communication lag from days to seconds.

Mumbai’s 1930 centre saved ₹202 crore in 2025 alone, largely through immediate account freezes coordinated from a 50-person call centre in Bandra that operates 24/7.

The RBI’s proposed Kill Switch from the April 2026 discussion paper could give users a way to freeze their own outgoing payments instantly — a panic button you can hit before you even need to call anyone.

And NPCI’s July 2025 chargeback reform (RGNB — allowing banks to re-raise genuine chargebacks that were declined due to caps) acknowledged that the earlier cap system had swung too far toward preventing abuse and was blocking real complaints.

But the structural hole remains. For social engineering fraud — the kind that causes the most damage — there’s no clear liability framework saying the bank has to make you whole. Recovery depends on whether you called 1930 fast enough, whether the freeze caught any money, whether the courts in your state have a quick process for releasing frozen funds, and whether you have the persistence to follow through for months.

That’s a lot of things that have to go right, and very few of them are in your control.

What this tells you about where we are

The dispute resolution infrastructure for digital payments in India was built for an earlier version of the problem. An era where the main thing that could go wrong was a technical glitch — money stuck in transit, a double debit, a server timeout. For those problems, the system works well and is getting better.

The problem moved. The majority of losses now come from social engineering, and the recovery infrastructure hasn’t caught up. There are two separate machines — chargebacks for technical failures, police freezes for fraud — and most victims don’t know which one to use. The machines don’t talk to each other. And the one that matters most for fraud (the police freeze) ends in a court process that most people can’t navigate alone.

A 72-year-old in Lucknow who sends ₹1.8 lakh to a scammer under duress isn’t “authorizing” anything in the way that word should mean. But the system treats the transaction as if he walked into the bank, filled out a withdrawal slip, and handed someone the cash. The legal framework hasn’t caught up to the reality that consent under manipulation isn’t really consent.

That gap — between what the system was built for and what it’s being asked to handle — is where the next round of reform will have to focus. Whether it comes from RBI mandate, NPCI policy, or the courts, someone is going to have to decide who pays when a person gets tricked.

Next week

So far we’ve covered money moving fast, how it gets authenticated, how fraud is caught or missed, and what happens when you try to get your money back.

Next week, we step back from the crisis and look at something less dramatic but just as load-bearing: KYC and compliance. The paperwork underneath all of this. Why you had to submit your Aadhaar and PAN to open a bank account, what your bank actually does with that information, and why the “Know Your Customer” process is both the foundation and the bottleneck of India’s financial system.

There’s also a direct connection to what we just covered: the reason scammers have so many mule accounts to launder money through is, in part, a KYC problem. Forged documents, rented accounts, incomplete verification. The leaks in the identity layer feed directly into the fraud we spent two weeks discussing.

How Money Moves · Week 11 of 52

It’s 11:14 PM on a Sunday.

Rent is due tomorrow. You open your UPI app, type in the landlord’s number, punch in ₹18,000, confirm your PIN. The screen hangs.

Then: “Risk threshold exceeded.”

No explanation. No “try again in five minutes.” No number to call. Just a dead screen and a sinking feeling.

You try again. Same thing. You try splitting it — ₹9,000 first. That goes through. The second ₹9,000? Blocked.

Now you’re sitting on your couch at midnight trying to figure out whether your account has been flagged for something, whether your landlord will charge a late fee, and whether you should drive to an ATM and withdraw cash like it’s 2014.

Subscribe now

Here’s what happened in the 0.3 seconds between tapping Pay and seeing that error: your phone sent the payment request to your bank, which passed it through a fraud detection pipeline that scored your transaction against dozens of signals — the time, the amount, how often you transact at this hour, the recipient’s history, your device fingerprint — and decided, somewhere between a clear yes and a clear no, to block it.

You weren’t told why. You weren’t given a way to appeal. The system made a call.

And it might have been wrong.

Last week we talked about authentication — how UPI verifies that you are who you say you are. That’s a different question from what fraud detection is asking, which is: even if it’s you, should we let this go through?

The invisible scanner

Think about the last time you walked through airport security. Bag on the belt, metal detector, maybe a random check, two minutes, done. You probably didn’t think about it much.

Now imagine that same process in 300 milliseconds. No visible scanner, no uniformed guard, no tray for your laptop. You walk through a corridor and somewhere behind the walls, twenty sensors are reading your gait, your bag contents, cross-referencing you against a database, and deciding — in the time it takes you to blink — whether to let you through.

That’s what happens to every UPI payment. Not after the fact. Before. The system doesn’t wait for a complaint. It makes a judgment on every single transaction in real time, billions of times a day.

The corridor isn’t one scanner. It’s a pipeline of checks running simultaneously — some simple rules that have always existed, some machine learning models trained on years of fraud patterns, some bank-specific logic layered on top of NPCI’s shared infrastructure. At the end of the pipeline, a number comes out. A score. That score determines whether your rent payment goes through or gets killed at midnight.

The rules layer is the blunt end. Hard-coded conditions: if a transaction is from a device you’ve never used before, flag it. If you’re sending more than ₹50,000 in one transaction and have never done that, flag it. If you’ve made five transfers to five different accounts in ten minutes, flag it. Rules don’t think — they’re the equivalent of a sign that says “no liquids over 100ml.” They catch obvious things. They also catch a lot of innocent people.

The model layer is more sophisticated. A machine learning system trained on millions of past transactions — legitimate and fraudulent — takes everything the rules don’t cover and produces a risk score. Time of day, whether you usually transact at this time, how the amount compares to your normal pattern, the recipient’s history (have people who sent money to this account previously reported fraud?), your location, whether you opened the app from a notification or typed it in directly, how fast you entered your PIN. None of these signals mean much on their own. Together, they describe a picture of how this transaction compares to what fraud and non-fraud have looked like before.

Below a certain score, the transaction approves instantly. Above a certain score, it’s blocked. In the grey zone between them, the system adds friction — an extra confirmation screen, a short delay, an OTP. The exact thresholds aren’t public, for obvious reasons.

This whole pipeline runs in under half a second. You never see it. You only notice when it says no.

The people the system gets wrong

The fraud detection system isn’t calibrated to catch every fraudulent transaction. It can’t be, and I’ll explain why in a moment. But first, three people who end up on the wrong side of its decisions — in different ways.

Subscribe now

Priya is a freelance content writer in Pune. She works irregularly, gets paid late, and her rent is ₹16,000. She usually pays on the 1st but this month her client paid on the 30th. She sends the payment that night, at 11:47 PM, because that’s when the money arrived. Blocked. “Risk threshold exceeded.” She doesn’t know what that means. She screenshots the error, sends it to her landlord on WhatsApp, and lies awake wondering if her account has been compromised.

Her transaction was legitimate. The system flagged it because of a combination it had learned to associate with risk: the late hour, the amount, the fact that she hadn’t paid this recipient recently. Every individual signal was explainable. Together they crossed a line.

Mohan is 72 and lives alone in Lucknow. He gets a call from someone claiming to be from his bank, who tells him his account will be frozen unless he verifies his identity by transferring ₹2,000 to a “verification account.” He panics and does it. Then ₹10,000. Then ₹25,000. By the time his daughter calls that evening, he’s sent ₹1.8 lakh to an account that was created three days ago and has received transfers from forty other people that week.

The fraud detection system saw the pattern. It scored the later transactions higher. But Mohan’s first few transfers were small enough and spread out enough to stay below the threshold. By the time the score crossed the line, most of the money was gone. The system wasn’t wrong about what it saw — it just saw it too late.

And then there’s Ravi, who runs a provision store in Hyderabad and doesn’t understand why three customers this week tried to pay, got blocked, and walked out. He doesn’t know what triggered it. He can’t call anyone. He’s started keeping more change in the register again, just in case.

These three situations are all real categories of failure. The system is too tight for Priya, too slow for Mohan, and opaque for Ravi. There’s no single threshold adjustment that fixes all three simultaneously.

Why the model can’t just get better

The obvious question: why doesn’t someone build a better model?

Because the problem isn’t primarily technical anymore. It’s a design constraint that’s baked into what UPI is.

UPI’s whole identity is instant, free, 24/7 payments. That identity is real and valuable — it’s why 400 million people use it. But instant means the fraud detection system has a fraction of a second to make a decision. Within that window, it can only do so much. If you gave the system 30 seconds instead of 300 milliseconds, it could cross-reference more databases, run more models, ask more questions. Better decisions. But 30 seconds of waiting would break UPI. Nobody waits half a minute at a chai stall for their ₹20 to clear.

The result is a deliberate trade-off. If you tighten the thresholds — block more transactions that look suspicious — you catch more fraud but also block more legitimate payments. At current volumes of over 2,000 crore transactions per month — roughly 66 crore a day — a 1% false positive rate means roughly 66 lakh people blocked per day for no real reason. So the system is calibrated to let some fraud through in exchange for keeping the rails open for everyone else.

Who pays when fraud does get through? For unauthorized access — someone genuinely broke into your account — RBI guidelines make the bank liable if you report within three days. But most UPI fraud isn’t unauthorized access. It’s social engineering: someone convinced you to send the money voluntarily. In those cases, the bank isn’t required to reimburse you. The money is gone. The institution that processed the transaction profited from the fee and faces no loss.

This creates an uncomfortable incentive structure. Banks invest in detecting unauthorized fraud because they’re liable for it. Social engineering fraud costs the user, not the bank, so the institutional incentive to solve it is weaker. The people bearing the cost aren’t the ones with the resources to fix the problem.

The RBI steps in

On April 9, 2026, the Reserve Bank of India released a discussion paper that made a lot of people very angry.

The proposal: a cooling-off period of one to four hours on transfers to first-time payees or on anomalous transactions above certain thresholds.

Not a block. Not a rejection. A lag — but a targeted one. A lot of the coverage framed this as a blanket one-hour delay on all P2P transfers above ₹10,000. That’s not what the paper says. If you send your landlord of five years ₹18,000, it goes through instantly — he’s not a first-time payee. The delay kicks in when you’re sending a significant amount to someone you’ve never paid before, or when the transaction pattern looks unusual enough to warrant it. During that window, you can cancel. Your bank can review. If something looks wrong, there’s time to intervene.

The internet reacted the way the internet reacts. “RBI is killing UPI.” “Why punish honest users for fraud they didn’t commit.”

But look at the data in RBI’s own paper. Digital fraud complaints hit 28.6 lakh in 2025, up from 2.6 lakh in 2021. Total amount lost: ₹28,683 crore — according to the Indian Cyber Crime Coordination Centre. And 98.5% of total fraud value comes from transactions above ₹10,000.

The RBI isn’t slowing down your chai payment. It’s targeting the exact transaction type where almost all the money disappears.

Merchant payments are exempt. QR code payments are exempt. Your Swiggy order, your electricity bill, your kirana store purchase — none of it is affected. And neither is your landlord, or your mother, or anyone else you pay regularly. The delay only applies when you’re sending significant money to someone for the first time, or when your transaction pattern looks anomalous enough to flag. Think honestly about how often you urgently need to send a large amount to someone you’ve never paid before, where a one-to-four hour delay would cause a real problem. For most people, the answer is: rarely.

The paper also proposes three other things. A trusted contact system for senior citizens, where someone like your daughter gets notified before large transactions go through. An annual ceiling of ₹25 lakh on P2P transfers. And a Kill Switch — the ability to instantly freeze all outgoing transactions from your account the moment you suspect something is wrong.

The framing the RBI uses for the delay is worth noting: it’s designed to “break the fraudster’s psychological control.” Most social engineering fraud works by inducing panic — your account will be frozen, your loan will default, your family member is in trouble. The urgency is the weapon. An hour gives the victim time to think, call someone, and realize something is off.

Other countries have already done versions of this. The UK introduced a mandatory delay of up to four days for certain suspicious payments in 2024. Singapore introduced a “Money Lock” feature allowing users to ring-fence funds from digital transfers, alongside delays for high-risk transactions. India’s proposal is more targeted than either.

The feedback window is open until May 8, 2026. RBI is actively asking for responses. Whether you agree with the delay or not, this is one of the rare moments where public input has a real chance of shaping what gets implemented.

The red banner that beat the algorithm

Something worth sitting with before we move on.

The single most effective anti-fraud measure NPCI deployed recently wasn’t a new machine learning model. It wasn’t behavioural biometrics or device attestation or cross-bank fraud scoring.

It was a banner.

UPI apps started showing a prominent warning on collect request screens — the ones where someone is asking you to send them money. Large red text at the top: “YOU ARE PAYING. MONEY WILL BE DEDUCTED FROM YOUR ACCOUNT.”

Collect request fraud rates dropped significantly.

Banks had spent hundreds of crores on server infrastructure and data science teams building predictive models. PhonePe changed the font to red. The red font won.

That’s not a knock on the engineers. It tells you something real about where the actual vulnerability is. The encryption works. The authentication holds up. The transaction pipes are solid. The gap is between what a screen shows and what a human brain understands when it’s under pressure, reading fast, and already expecting good news.

All of which is why the RBI’s proposed delay is interesting not just as a fraud control but as a design philosophy. The underlying insight is the same as the red banner: the most effective intervention isn’t catching more fraud after the fact, it’s giving people a moment before the irreversible thing happens. The banner created a moment of pause. The delay creates a longer one.

Where this is heading

UPI has become what it is by making payments fast. That’s not changing. But at over 2,000 crore transactions a month, with fraud losses crossing ₹28,000 crore in a single year, the question of where to put friction — and how much, and who has to deal with it — can’t be deferred indefinitely.

What’s becoming clearer is that the next layer of defence isn’t algorithmic. The models are good and getting better, but they’re working within a time window that limits what they can do. The interventions that have actually moved the needle — the red banner, the collect request caps, and now the proposed delay — are all about inserting a moment of human judgment back into a process that was designed to remove it.

That’s not a retreat from the original vision. It’s a recognition that the original vision was incomplete. Speed was the right pitch in 2016. In 2026, with fraud at this scale, speed needs a counterweight in specific places. The question the RBI is trying to answer right now is exactly how narrow those places need to be.

Next week

The fraud detection system failed. The payment went through. You’ve been scammed.

Now what?

You’d think there’s a clear process: call your bank, file a complaint, get your money back. There isn’t. What exists is a multi-party dispute resolution process called a chargeback, and most people have never heard of it until they need it.

Next week: what happens after a fraudulent transaction — who you call, what timelines you’re working against, why some disputes take 90 days, and the uncomfortable reason most fraud victims never see their money again.

How Money Moves · Week 10 of 52

A colleague of mine almost lost money last month in a way that embarrassed him enough that he only told me about it quietly, at lunch, after I mentioned what I’d been writing about.

Subscribe now

He was selling a used monitor on OLX. A buyer messaged, seemed keen, and said he’d pay via UPI right away. A minute later, a notification appeared on his UPI app: a payment request for ₹8,500.

Except it wasn’t a payment. It was a collect request.

If he had entered his PIN — which the screen was prompting him to do, in the same familiar green interface he uses for every payment — he wouldn’t have received ₹8,500. He would have sent it.

He caught it because he paused and read the small print on the screen that said “Paying to” instead of “Received from.” Most of the screen looked like a normal payment confirmation. The amount was right. The timing was right. The one detail that was wrong was the direction of the money, and that’s not what you’re looking for when you’re expecting a payment.

Last week we talked about authentication — the locks on the vault door. This week is about the people trying to pick those locks, and the systems trying to catch them mid-pick.

How the scams actually work

The collect request trick that nearly got my colleague is the most elegant of the common UPI scams because it uses a legitimate feature of the system against the user.

UPI lets anyone send you a request for money. You don’t need permission to ask someone for money, only to take it. The request arrives as a notification and, at a glance, looks almost identical to a payment confirmation — same green interface, same amount displayed prominently, same PIN prompt. The scammer’s entire bet is on context. They engineer a situation where you’re expecting money — selling something on OLX, waiting for a refund, splitting a bill with a friend — and then send the collect request at exactly that moment. Your brain has already decided what this notification means. The amount matches what you’re expecting. You enter your PIN.

NPCI has since tightened the caps: standard P2P collect requests are now limited to ₹2,000 per transaction, maximum five requests per day. So a single scam can no longer drain tens of thousands in one go. But five requests at ₹2,000 each is still ₹10,000, and the psychological trick works just as well on a ₹2,000 request as it did on a ₹50,000 one. The ceiling came down; the method didn’t change.

The fake payment screenshot is a different kind of exploit — it doesn’t touch UPI’s systems at all. A buyer completes a purchase, ₹500 for a meal or ₹300 for produce at a stall, and shows the vendor a screenshot of a successful payment. The screenshot looks real: the right amount, a transaction ID, a timestamp, the familiar green screen. But it’s fabricated in an image editor, or it’s a genuine screenshot from an old transaction with the details edited. The vendor, busy, glances at the screen and sees what they’re expecting to see. The food changes hands. By the time they check their account at end of day, the customer has been gone for hours.

This works because of the gap we covered in Week 7 — the delay between what the customer’s app shows and what the merchant’s bank has actually credited. That gap is normally seconds. The screenshot scam turns it into a permanent absence, and the vendor’s willingness to trust the screen instead of waiting for their own bank’s SMS is the whole attack surface.

The customer care scam is in some ways the most professionally run. You search for “PhonePe customer care number” — maybe after a failed transaction or an unexpected debit — and the first result looks official. You call it. The person on the other end sounds competent, asks for your UPI ID, and sends a collect request for a small amount to “verify your identity.” You enter your PIN for ₹1 and nothing obviously bad happens. Then they send another. Or they walk you through installing a screen-sharing app and watching while you authenticate a real transaction. By the time the pattern becomes clear, you’ve already entered your PIN for a transaction you didn’t intend to authorise.

Google has cracked down on financial ads that aren’t from verified entities. The fake numbers survive through typo-squatting — “PhonPe support” instead of “PhonePe,” variations that don’t trigger the verification filters — and through buying new ad accounts faster than the moderators can close them. Some operations run professional-sounding IVR systems. It’s a commercial enterprise, not a teenager with a SIM card.

The QR code problem

QR codes deserve their own section because the attack is simpler than people expect, and it’s becoming more common.

Every UPI QR code uses the same underlying format — upi://pay — which initiates a push payment from the person scanning to the person whose ID is encoded in the code. That’s all QR codes do. They can’t encode a collect request. There is no such thing as a “receive money” QR code. When you scan and enter your PIN, you are paying. Every time, without exception.

Most people don’t know this, and scammers know that most people don’t know this.

The physical version of the attack is simple: print your own QR code linked to your own UPI ID, and paste it over the merchant’s legitimate code at a shop counter. Every customer who scans sends money to the scammer. The merchant doesn’t notice until the end of day when the till doesn’t match. Because each transaction is small — ₹30 for chai, ₹150 for lunch — nobody raises an alarm in real time.

The digital version is more targeted. A scammer messages you on WhatsApp with a QR code and a story: “scan this to receive your refund,” or “scan to confirm your delivery address,” or “the payment link wasn’t working, try this QR code.” You scan, see the familiar payment screen with an amount, assume you’re verifying something, enter your PIN. You just sent money to someone you’ve never met.

The whole thing works because the concept of “scan a QR code to receive money” sounds plausible to people who haven’t thought carefully about how UPI works. And there’s no reason most people should have thought carefully about how UPI works — that’s the point of making it simple.

What the fraud detection systems are actually doing

Every UPI transaction passes through a fraud detection layer before it’s approved. The specific rules aren’t published — for obvious reasons, publishing the exact thresholds would help fraudsters calibrate around them — but the general shape is known.

The simpler layer is rule-based: a set of if-then conditions that flag specific patterns. A user whose normal transactions run ₹500-₹2,000 suddenly initiating a ₹50,000 transfer. A new UPI ID receiving small amounts from fifteen different accounts within an hour. A collect request to an account that has never previously transacted with the sender. These rules exist at multiple levels — NPCI sets system-wide rules, banks add account-level rules, and apps like PhonePe and Google Pay add device-level and behavioural rules on top.

The problem with rules is that they’re static. Once a fraud network figures out the thresholds — and they do, through testing — they adjust. Send ₹49,000 instead of ₹50,000. Use fourteen accounts instead of fifteen. Spread over three hours instead of one. Rule-based detection is always catching the fraud pattern from six months ago.

Machine learning models are the attempt to get ahead of that adaptation. They’re trained on historical fraud data to recognise combinations of signals that don’t reduce to simple rules. The model might learn that the combination of a device registered in the last 48 hours, a collect request to an account that is itself new, at an unusual hour, with a recipient flagged in previous fraud reports, adds up to something worth stopping — even though no single factor is a rule violation. These models run in real time, producing a fraud probability score for every transaction before it’s approved. At 72 crore daily transactions, this is computationally significant.

What makes fraud detection hard — really hard — is not catching obvious fraud. Rules handle that. It’s the grey zone. Transactions that aren’t clearly fraudulent and aren’t clearly legitimate. The models assign a risk score and the system decides: approve, decline, or add a friction step. The friction steps are things you’ve probably noticed — an extra confirmation screen on a large transfer, a slight delay before a collect request appears, a “verify merchant details” prompt when you scan a new QR code. None of these are random. Each one means the system saw something worth slowing down.

The problem the defenders don’t talk about

Every fraud detection system that catches fraud also blocks legitimate transactions. This is unavoidable and the fraud teams know it, but it doesn’t come up much in public communication because it’s not a comfortable thing to say out loud.

If you set the thresholds tight enough — flag anything over ₹10,000, flag any payment to a new recipient, flag any transaction after midnight — you catch more fraud. You also block the person transferring rent to a new landlord, the freelancer receiving a first payment from a new client, the parent sending emergency money at 1 AM. 1% of 72 crore daily transactions is 72 lakh blocked payments per day.

So the systems are deliberately tuned to accept some fraud in order to keep the false block rate low. This is a conscious trade-off, made explicitly. The priority is not breaking the experience for the overwhelming majority of users who are doing nothing wrong. Some fraud will always get through as a result.

The real skill is in the grey zone — transactions that could go either way. That’s where the ML investment matters. Not in stopping someone trying to transfer ₹2 crore at 3 AM from a brand-new device (rules catch that), but in accurately reading ambiguous patterns without blocking things that are just unusual rather than fraudulent.

Manual review is the backstop, and at UPI’s scale it can only be used sparingly. The models have to be good enough that the volume of transactions needing human judgment stays small. Getting that right is harder than it sounds.

Why the attackers keep winning rounds

I want to be honest about where the defenders are at a structural disadvantage, because I think people assume this problem is being steadily solved. It isn’t, exactly.

Adaptation speed is the obvious one. When NPCI adds a rule or a bank updates its fraud model, fraud networks learn about it within days through testing. Adjusting a scam to stay under a new threshold takes hours. Retraining a detection model on new fraud patterns takes weeks or months. The defenders are always working with a lag.

The economics don’t help either. Building and maintaining fraud detection infrastructure costs crores. Running a collect-request scam operation costs some phones and a working knowledge of how the flow looks to a victim. For small-value fraud — ₹1,000-₹2,000 per incident — the per-transaction profit doesn’t justify intensive law enforcement attention, and the scammers know it. They operate at scale specifically because no individual incident is worth chasing.

But the thing that bothers me most is the problem from last week. When a user authenticates a transaction themselves — because they were tricked into it — fraud detection systems see a clean transaction. Right device, right SIM, right PIN, right person. The behavioural models are trying to catch the cases where something about the session looks off even if the authentication checks passed. But those models are still early and imperfect, and a determined social engineer who knows to keep their target calm and conversational is hard to catch.

There are also about 600 banks in the UPI ecosystem with very different levels of fraud detection sophistication. Large private banks have substantial ML infrastructure. Many smaller banks rely primarily on rule-based systems or shared NPCI tools. Fraud networks know which bank types have weaker detection and target their operations accordingly.

What’s changing

A few developments that may shift the balance, at least for a while.

NPCI is in a structurally unique position because it sees every UPI transaction across every bank simultaneously. It can detect patterns that no individual bank can see — the same recipient account collecting small amounts from dozens of different banks within an hour, the same device ID appearing in fraud reports across multiple apps. NPCI’s Fraud Risk Management system is being expanded so that when a device ID or UPI address is flagged on one app, the block applies across the entire ecosystem. Currently, a fraudster flagged on PhonePe can sometimes just move to Google Pay and continue. The cross-app blocking is designed to close that.

For QR code fraud specifically, the push is toward dynamic QR codes generated fresh for each transaction rather than static printed ones, and real-time merchant verification when you scan. If the app can confirm that this QR code belongs to a business registered at a specific address, active since 2019, that’s a lot harder to fake than a sticker anyone can print and paste.

New UPI IDs already face a 24-hour window after registration where total transactions are hard-capped at ₹5,000. This directly targets the pattern where fraudsters create fresh UPI IDs, run a burst of collect-request scams, and abandon them. The ₹5,000 ceiling makes that model much less profitable per account.

The biggest font

Something I’ve been sitting with through all of this research: the vast majority of UPI fraud isn’t a technology problem. It’s an information problem.

People don’t know what a collect request is. They don’t know that entering your PIN on a collect request sends money rather than receives it. They don’t know that a screenshot of a successful payment isn’t proof of a successful payment. They don’t know that scanning a QR code always means paying. This isn’t stupidity — UPI was designed to be so simple that you don’t need to understand how it works. For legitimate transactions, that’s exactly right. But the same not-thinking that makes UPI frictionless is what every scam exploits.

The apps that added large red banners to collect request screens — “YOU ARE PAYING. MONEY WILL BE DEDUCTED FROM YOUR ACCOUNT” — saw those specific scam rates drop. Not a new model. Not tighter rules. A bigger font. The collect-request screen looked too much like a payment receipt, so they made it impossible to confuse the two.

The screen-sharing detection we talked about last week is the same idea applied more technically — not adding a step to every transaction, but catching the one specific moment where something is clearly wrong and interrupting before the PIN gets entered.

The arms race between detection systems and fraud networks will keep going. That’s not a pessimistic take, it’s just the nature of the problem — every defence creates an incentive to find a way around it. But for the fraud that’s actually hurting the most people right now, some of the most effective changes have been the simplest ones. Make it impossible to misread the screen. Stop the PIN from working while someone else can see it. These don’t require better AI. They require someone asking: what does a user who is about to make a terrible mistake actually see on their screen, and can we change that?

Next week

Nine weeks in, we’ve traced the full lifecycle of a payment — how money works, how it moves, how it fails, how it’s secured, and how people try to steal it.

Next week I want to zoom out and look at what happens after a payment you didn’t intend to make. Not the pending transaction or the auto-reversal — those are system failures. What happens when the money moved correctly, from the system’s perspective, but you want it back? Disputes, chargebacks, and the messy process of reversing a payment that the system treated as legitimate.

How Money Moves · Week 9 of 52

Word count: ~2,500 words Arc 1 · Week 9 · How Money Moves

A few months ago, my uncle called me in a panic. Someone had transferred ₹48,000 out of his bank account through UPI. He hadn’t shared his PIN with anyone. He hadn’t lost his phone. He hadn’t clicked any suspicious link — at least not one he remembered clicking.

His first reaction was disbelief. “I thought UPI was safe. You need a PIN. How can someone pay without a PIN?”

His second reaction was to blame the bank.

His third reaction, after we spent an hour piecing it together, was quieter. Because the authentication system hadn’t actually failed. What failed was his understanding of what the system protects against — and what it was never designed to protect against at all.

That’s what this piece is about. When you tap “Pay” and enter your PIN, you’re passing through a series of locked doors. Some of those doors are surprisingly strong. And some aren’t doors at all — they’re curtains that look like doors if you don’t push on them.

Subscribe now

Why a four-digit number is enough

Your UPI PIN is four or six digits. That’s what stands between your bank account and everyone else. If you think about it purely as a number, it’s absurd — there are only 10,000 possible four-digit combinations. A computer trying random combinations could exhaust them in under a second.

So why does it work?

Because the PIN alone doesn’t do anything. It’s not a password to a website that anyone can type from anywhere in the world. A UPI PIN only functions when it comes from the right device, with the right SIM card, in the right app. Someone who knows your PIN but doesn’t have your phone can’t use it. Someone who has your phone but not your PIN can’t use it either. The PIN is the weakest factor on its own — it was never meant to work on its own.

This is what people mean when they talk about multi-factor authentication. Something you know (the PIN), something you have (the phone with your registered SIM). UPI requires both, simultaneously, for every transaction. The four-digit number is the part you see. The device check happens invisibly, before the PIN screen even appears.

The lock you don’t see

Before you ever enter a PIN, UPI has already checked something you don’t think about: whether the payment request is coming from the right device.

When you first set up UPI on a phone, the app does something called device binding. It registers a combination of your phone’s hardware identity and your SIM card — creating a fingerprint of that specific phone-SIM combination and tying it to your bank account. Your bank now knows which physical device is authorised to transact on your account. A payment request from any other device gets rejected before the PIN screen appears.

The SIM is doing two things here. During registration, the UPI app sends a silent SMS from your phone to a central server — you don’t see this, it happens in the background — confirming that the phone number registered with your bank is physically present in the device trying to set up UPI. That’s how the system links the physical device to your financial identity. But the SIM alone isn’t enough. NPCI also requires apps to check OS-level identifiers — the Android ID on Android, the device ID on iPhones — specifically so that cloning a SIM card alone doesn’t grant access.

This layer matters more than the PIN for most attack scenarios. You can guess a PIN if you’re determined enough. You can’t easily fake a device that was registered with a bank three years ago.

Where your PIN actually goes

When you type your UPI PIN, you’re not typing into PhonePe or Google Pay. That’s the part I didn’t know until I looked into it.

When the PIN pad appears on screen, a separate piece of software takes over — the NPCI Common Library, a piece of code that NPCI built and distributes to every UPI app. PhonePe’s code steps aside. The Common Library controls the PIN screen, handles the input, and encrypts it before the app ever touches it. The app is not involved in this step. It literally cannot read what you type.

The encryption works through a system called Public Key Infrastructure. Think of it as sealing a letter in an envelope that only your bank can open. The Common Library wraps your PIN, along with information about the device, the transaction amount, and the recipient, into a signed package. If anyone modifies any part of it during transit, the signature breaks and the transaction is rejected.

This sealed package travels from the Common Library on your phone, through your UPI app’s servers, through NPCI’s switch, and finally to your bank. Your bank decrypts it, verifies the PIN, and approves or rejects. At every point in between — PhonePe, NPCI, anyone else in the chain — the package passes through but can’t be read. Your UPI app processes millions of your transactions. It has never seen a single one of your PINs.

I find this more reassuring the more I think about it. We use these apps every day and assume they have access to everything. The amount, the recipient, the timestamp — yes. But the PIN is encrypted inside the Common Library on your device and decrypted only at your bank. Nobody else handles it in readable form.

Everything else happening in those two seconds

The PIN and the device check are the two things you’re aware of. But by the time your bank is decrypting your PIN, several other things have already happened or are happening in parallel.

The UPI app checks, at runtime, whether the phone itself has been tampered with. Rooted Android phones and jailbroken iPhones have weakened security boundaries — malicious software can read screen contents, intercept inputs, modify app behaviour. NPCI requires all UPI apps to run these integrity checks, and if the phone fails, the app refuses to work. Not a warning, a full refusal.

Before the PIN even matters, the system also verifies that the session is still valid — that you’ve authenticated into the app recently enough that it hasn’t expired — and that the transaction amount is within your per-transaction and daily limits. The standard P2P limit is ₹1 lakh per transaction, though the RBI has extended this to ₹5 lakh for specific contexts: hospitals, educational institutions, IPOs, RBI Retail Direct.

Your bank, once it gets the decrypted PIN, is running its own checks independently. Is the account active? Is it flagged? Is the balance sufficient? Has this account made an unusual number of transactions in a short window? Is the recipient account valid? Has it been flagged for fraud? Is this a new payee that might warrant a delay?

Most of these checks complete in milliseconds. You don’t see them, you don’t feel them, and when they all pass you just get the green screen. When any one of them fails, you get an error code that often tells you nothing useful about which check actually caught it.

How my uncle lost ₹48,000

So here’s what actually happened.

He got a call from someone claiming to be from his bank. They told him his UPI account needed to be “re-verified” or it would be blocked. They walked him through installing a screen-sharing app — AnyDesk, one of the legitimate remote access tools. Then they asked him to open his UPI app and “verify” by making a small transaction.

He entered his PIN while someone was watching his screen.

That’s it. Every authentication check passed. The right device, the right SIM, the right PIN — everything the system was designed to verify was present and correct. The system had no way of knowing that the person entering the PIN was doing it because a stranger on the phone told them to.

This is the gap. The authentication stack is very good at preventing technical attacks — someone using your stolen PIN from a different device, someone intercepting data in transit, someone trying to brute-force credentials. It was designed for those threats and it handles them well. But the most common way people actually lose money through UPI isn’t any of those things. RBI data consistently shows that over 95% of digital payment fraud involves the victim unknowingly authorising the transaction themselves. The cryptography almost never fails. The user is convinced to bypass it.

The five locks on the vault door don’t help if someone talks you into opening it yourself.

The SIM swap problem

There is one actual technical attack worth knowing about, and it predates UPI by years.

A SIM swap works like this. An attacker goes to your mobile carrier — in person at a retail outlet or by calling customer support — and convinces them to transfer your phone number to a new SIM card. Fake ID, bribing a store employee, talking a support agent into it. Once they have your number on their SIM, they can attempt to register UPI on their device. The silent SMS verification now goes to their phone. If they also have some of your personal details — name, date of birth, partial account number from a discarded bank statement — they can sometimes reset the UPI PIN.

The telecom operators have gotten better at flagging unusual SIM swap requests. NPCI has added a mandatory 24-hour cooling-off period after any SIM change — during that window, UPI registration on a new device is blocked and outgoing transactions are heavily restricted. Banks send alerts when a SIM change is detected for a registered number.

But the attack targets the telecom layer, not the banking layer. The bank doesn’t know your SIM was swapped. It just knows that a valid SMS verification came from your number. By the time you notice your phone has lost all network connectivity and figure out why, an attacker may have already moved money.

What’s being added

The authentication stack isn’t fixed. A few things are changing or have recently changed.

There’s a common misconception worth clearing up first. PhonePe and Google Pay both let you unlock the app with your fingerprint or Face ID — but that’s just opening the app. The actual payment authorisation is still the UPI PIN handled by the Common Library. The biometric is a convenience feature for the app itself. Real biometric payment authorisation exists in the AePS system, which lets you transact at a banking correspondent using your Aadhaar number and thumbprint, but that hasn’t crossed into mainstream UPI apps yet.

The most directly relevant change for cases like my uncle’s is screen-sharing detection. The Common Library now includes code that checks whether AnyDesk, TeamViewer, or similar remote access tools are running when you try to enter a PIN. If they are, the CL blocks the PIN screen entirely and shows a warning. If my uncle ran into the same scam today, there’s a reasonable chance he never gets to the step where he types his PIN.

Some UPI apps are also starting to run behavioural analysis on your device — checking whether the way you’re using the app matches your usual patterns. Typing speed, transaction timing, how the session started. The theory is that someone under pressure from a scam call behaves differently from someone paying normally, and that difference might be detectable. This is early, but it’s the right direction — not adding steps to every transaction, but trying to catch the moments where something is clearly off.

The push toward hardware-level device binding is also worth watching. SMS-based verification is the weak link in device registration, and there’s pressure to move toward using the secure element in modern phones — Apple’s Secure Enclave, Android’s StrongBox — to make device identity harder to fake or transfer.

The problem with adding more locks

Every additional check is friction. Another second, another step, another moment where someone hesitates or gives up.

UPI’s growth was built on the opposite of friction. Two-second payments. No OTPs. No waiting for an SMS code. Just a PIN and you’re done. That simplicity drove 400 million users. It’s why the chai vendor uses it, why the street vendor accepting ₹20 payments uses it, why people who found net banking intimidating use it. The friction was deliberately removed.

If you added biometric verification to every UPI transaction, you’d make it harder to lose money to scams. You’d also make it slower and more complicated for everyone. The elderly person who just got comfortable with UPI might stop using it. The rural first-timer might not get past setup. The people most vulnerable to fraud are often the ones who’d be most deterred by additional security requirements.

This is a real tension and there’s no clean answer to it. The system has so far stayed closer to the easy end of the spectrum, and the adoption numbers suggest that was probably right for the growth phase. But as the amounts flowing through UPI increase and the fraud gets more sophisticated, the balance has to shift somewhere.

What my uncle’s case actually shows is that the most useful security improvements might not be heavier verification on every transaction. They might be smarter detection of the specific moments where something has already gone wrong. A screen-sharing app running while you enter your PIN is a very precise signal. A pop-up saying “you are sharing your screen — are you sure you want to continue?” doesn’t add friction to any normal transaction. It only activates when the red flag is already there.

That’s harder to build than adding another password field. But it’s closer to what would actually help.

Next week

We’ve spent eight weeks building up how payments work — what money is, how it moves, what happens when it fails, and now how the system verifies who’s asking. Next week I want to look at the other side of that last question.

What happens when someone is actively trying to steal money, and not through social engineering — actual technical fraud? Fake UPI IDs, phishing QR codes, collect-request scams, and the real-time systems trying to catch them before the money moves.

Next week: fraud detection in UPI. And why it’s an arms race where the attackers get a vote.

Leave a comment

Word count: ~2,500 words Arc 1 · Week 8 · How Money Moves

Last month a friend tried to pay his electricity bill on PhonePe. ₹2,400. He pressed pay, the screen went white for a moment, and came back with: “Transaction Failed.”

He tried again.

“Transaction Successful.”

His bank account showed ₹4,800 debited. Two transactions. One bill.

He called PhonePe. They said wait 3-5 business days. He called his bank. They said it’s PhonePe’s problem. He called PhonePe again. They said it’s the bank’s problem. For five days, ₹2,400 of his money existed nowhere — not in his account, not with the electricity company, not with PhonePe. Floating somewhere in the pipes between institutions, waiting for someone to fish it out.

If you’ve used UPI for more than a few months, you’ve had some version of this. Not necessarily this bad, but the sinking feeling when the app says failed and your balance says otherwise. The helpless loop between customer support numbers. The quiet anxiety of not knowing where your money went.

Last week, we traced the two-second journey of a successful payment. This week I want to look at what happens when it isn’t.

The number that should bother more people

UPI’s overall success rate is around 99.2%. When you hear that, it sounds fine. A 0.8% failure rate. Barely anything.

But UPI now processes over 72 crore transactions every day. 0.8% of that is roughly 58 lakh failed payments. Daily. That’s nearly 60 lakh people staring at an error screen, wondering if their money is gone, every single day.

And the 99.2% is the system-wide average. The numbers look very different depending on which banks are in the chain. HDFC’s technical decline rate is around 0.08%. SBI’s is over 5%. Some regional banks like Baroda UP Bank are above 7%. The UPI app you use doesn’t matter as much as the banks on either end of the transaction. Two people using PhonePe can have completely different reliability depending on where they both bank.

Sixty lakh failures a day is an enormous number. The reason nobody thinks of it that way is that each failure is private — one person, one phone, one moment of frustration. There’s no visible pile of broken payments. Just 60 lakh individual bad experiences, each one logged, each one invisible to everyone else.

Where in the chain things break

Last week I described the five hops a UPI payment makes — your phone, your bank, NPCI’s switch, the receiver’s bank, and finally the receiver’s account. A payment can fail at any of those hops, and which hop it fails at changes everything about what happens next.

The simplest failure is also the most common: your bank says no before any money moves. Wrong PIN, insufficient balance, daily limit reached. The system worked exactly as it was supposed to. Your account wasn’t touched. Nothing to recover. This category covers most of the failures in that 0.8% figure, and it’s the only kind where “failed” actually means what you think it means.

The others are harder.

The one that causes the most confusion is a timeout. Your bank approves the transaction and debits your account. The debit is done — it’s written to the database, it happened. But the message moving forward through the chain doesn’t complete in time. Maybe NPCI is under load. Maybe the receiver’s bank is slow to respond. The system hits its time limit and marks the transaction failed.

At this point, you have a real problem. Money left your account. The transaction is officially failed. But the payment never arrived anywhere. Your ₹2,400 is in a holding account somewhere between the two banks, waiting for the reconciliation process to find it and send it back.

There’s also a stranger version of the timeout. Sometimes the receiver’s bank does process the transaction — just too late. By then, the system has already marked it failed. Now you have the opposite situation: the official record says failure, but money was actually credited to the receiver. The customer thinks they need to pay again. The merchant received money they didn’t expect. This is the case that gives engineers nightmares because it requires manual investigation to untangle.

Then there’s the case where the receiver’s bank is simply unavailable — under maintenance, overloaded, briefly offline. It gets the instruction but can’t process it. Sends back a decline. Meanwhile your bank has already debited you. Same problem: the debit happened, the credit didn’t, and the money needs to find its way home.

Where the money actually goes

My friend’s ₹2,400 didn’t disappear. Banks don’t lose money the way you lose your keys. Every rupee is an entry in a database somewhere.

What happened is that his bank debited his account, and then the transaction timed out before the electricity company’s bank could credit the payment. The debit from his account — that already happened and was final. But the credit never completed. So the money was sitting in a settlement account, a kind of holding area that exists between the two banks for exactly this situation. Think of it as a package that left the warehouse and is on a truck, but the truck broke down before it reached the delivery address.

The package is somewhere. It just needs to be found and sent back.

This is what the auto-reversal system is designed to do. When NPCI runs its reconciliation at the end of each settlement cycle, it compares notes between all the banks. Did you debit this amount? Yes. Did the receiver’s bank credit it? No. Mismatch. NPCI sends a reversal instruction and the money comes back. For payments between individuals, this is supposed to happen by the next business day. For merchant payments, banks have up to five business days. Miss those deadlines and the RBI mandates a ₹100-per-day penalty credited automatically to the customer’s account.

In theory, this all happens without you needing to do anything. In practice — and this is the part that hasn’t fully caught up with the theory — the system sometimes still needs a nudge.

The chai vendor who stopped trusting the sound

I spoke to a chai vendor near Koramangala. He runs a small stall, maybe eighty to a hundred customers a day. He switched to UPI three years ago and was happy about it for a while — no change problem, no fake notes, money straight into his account.

Then the failures started.

“Customer shows me the screen — ‘Transaction Successful.’ I hear the sound also. But money doesn’t come. Sometimes it comes after two hours. Sometimes next day. Sometimes never, and they already left.”

What he’s describing is a gap that exists in UPI’s architecture. When a transaction reaches a certain state, the customer’s app can show success before the merchant’s bank has actually confirmed the credit. The payment is in-flight — technically completed on one end, not yet confirmed on the other. The customer sees the green tick and walks away. The vendor has no way to verify in real time whether the money actually arrived.

His solution: he waits for the SMS from his bank before handing over the chai. If it doesn’t come within thirty seconds, he asks for cash.

“People get angry. They show me the green tick. But green tick and money in my account are two different things.”

He’s stumbled onto one of the harder problems in distributed systems — the difference between acknowledgment and settlement. The app is confirming that the instruction was sent. It is not confirming that the money landed. These feel like the same thing. For a ₹20 chai they mostly are. For a merchant processing lakhs a day, they absolutely are not.

Why salary day is worse

Payments fail more often on the 1st of the month. During major IPL matches. Diwali evening. Flash sales.

This isn’t a coincidence. The UPI infrastructure runs on physical servers with real throughput limits. On a normal day it handles around 70 crore transactions without much trouble. On salary day, when everyone is paying rent, EMIs, credit card bills, and sending money home at roughly the same time, the load spikes hard and the system starts to strain at the edges.

Individual bank infrastructure matters here too, and the gap between banks is wild. Larger private banks have invested heavily in server capacity and maintain low failure rates even under load. Smaller cooperative banks and regional rural banks have systems that buckle earlier. NPCI processes the transaction, but if the receiving bank’s server is overwhelmed at that specific moment, the transaction fails at the last hop — after your bank has already debited you.

This creates an odd unfairness. If you and the person you’re paying both bank with large private banks, your failure rates are probably low. If either of you uses a smaller bank, you’re rolling different dice. Same UPI system, same app, very different reliability depending on which two banks happen to be in the chain.

What’s actually getting better

The system has gotten better. Not everywhere, and not evenly, but better.

The auto-reversal timelines used to be much looser. Now they’re specific and have teeth: P2P reversals by T+1, P2M by T+5, with a ₹100-per-day automatic penalty if a bank misses the deadline. The penalty gets credited to your account without you having to ask. Banks that used to let reversals sit in a queue for a week found the motivation to process them faster once it started costing them money.

After the April 2025 outages, NPCI changed something more structural. Banks had been hammering the system with “Check Transaction Status” requests the moment anything looked uncertain — which was creating a cascade. The traffic generated by all those status checks was making the congestion worse. NPCI now requires banks to wait 90 seconds before the first status check, and caps them at three checks within a two-hour window. It’s an unglamorous fix but it cut down the failure storms during peak hours by a lot.

NPCI’s dispute resolution mechanism — UDIR — is also now fully automated and mandatory across all banks. The goal is that my friend never has to call both PhonePe and his bank and get bounced between them. The system reconciles itself, the mismatch gets flagged automatically, and the reversal happens. He shouldn’t need to call anyone. That’s mostly true now, though it depends on the bank.

NPCI also now tracks technical decline rates by bank and publishes the data. That’s how we know about the gap between HDFC’s 0.08% and SBI’s 5%. Public accountability turns out to be a decent motivator. Some of those banks have since upgraded their infrastructure.

But the core problem is still the same one it’s always been: UPI is a real-time system asking core banking infrastructure — much of it built for batch processing in a different era — to respond in milliseconds. Sometimes it can. Sometimes it can’t. The gap is narrowing, but it’s not gone.

What failure actually means at this scale

UPI’s adoption didn’t come from perfection. It came from being reliable enough, often enough, that people stopped worrying.

My friend got his ₹2,400 back after five days and still pays every bill through PhonePe. The chai vendor in Koramangala, despite his SMS rule, still uses UPI for most transactions. People have developed a calibrated sense of how much they trust it, and that calibration is mostly reasonable: ₹200 transfer without thinking about it, slightly nervous at ₹20,000, would probably use NEFT or RTGS for ₹5 lakh, and for buying a house you’re calling your bank directly.

That’s how trust in infrastructure tends to work. You don’t need zero failures. You need failures that resolve predictably and quickly, and you need people to be able to build a mental model of when to rely on the system and when to double-check. The chai vendor’s SMS rule is a reasonable response. He hasn’t abandoned UPI — he’s just learned where it’s flaky and adjusted.

The 60 lakh daily failures aren’t a sign that UPI is broken. They’re what 0.8% of an enormous number looks like. The question isn’t whether failures happen — they always will at this scale. The question is how quickly the money comes back, and whether you have to fight for it.

That’s where the work is still unfinished.

Next week

We’ve covered how payments succeed, and now how they fail. But there’s a question I’ve been avoiding for seven weeks.

When you enter your UPI PIN, you’re unlocking something. But what exactly? How does a four-digit number protect your entire bank account? What happens if someone watches you type it? What’s actually being verified before a single rupee moves?

Next week: the authentication stack. PINs, biometrics, device binding, and the invisible layers of verification underneath every tap of “Pay.” It’s better designed than you’d expect. Also more fragile.

How Money Moves · Week 7 of 52

You’re at a chaiwala. It’s hot. You’re in a hurry.

You open PhonePe, scan the QR code, type ₹20, enter your PIN, press pay.

Two seconds later: Payment Successful.

The chaiwala nods. You grab your chai.

I’ve done this hundreds of times. So have you, probably. It’s become so routine that you stop seeing it — the same way you stop seeing the steps involved in starting a car. You just turn the key.

But I got curious about those two seconds. Not “where does the money go” in a general sense — I knew the answer to that. I mean the actual sequence. What fires, in what order, between which computers, so that ₹20 moves from your account to a stranger’s account at a completely different bank, in real time, forty-five times a second across the country, and almost always works.

When I actually looked into it, I found it weirder and more interesting than I expected. There are five separate server clusters involved in every single payment. Five. Any one of them going offline kills the transaction. And the whole chain completes in roughly the time it takes you to put your phone back in your pocket.

Here’s what’s happening in those two seconds.

Before the money moves, the system needs to know it’s actually you

The first thing UPI has to figure out before moving any money is whether you are who you say you are. This sounds obvious, but think about what it has to work with. It can’t see your face. It can’t verify your signature. All it has is a tap on a phone screen.

So it uses two things together, and the combination matters.

The first is your phone itself. When you first set up PhonePe, the app sent a silent SMS from your device to verify that your SIM card — the one registered with your bank — was physically sitting inside that particular phone. Your hardware ID, your SIM, and your account number all got tied together in NPCI’s records. This is called device fingerprinting, or sometimes hard binding. Every transaction you make, the system quietly checks in the background: is this the same device?

The second thing is your PIN. And here is where it gets interesting, because the PIN you type never actually travels across the internet as a readable number.

Every UPI app — PhonePe, Google Pay, all of them — has a piece of software inside it that NPCI built and distributed, called an SDK. The moment you type your PIN, this SDK encrypts it on your phone using a public key that belongs specifically to your bank. By the time that encrypted PIN leaves your device and enters the network, it’s a scrambled block of data that only your bank can unscramble, using a private key that lives only on their servers.

So the thing traveling through the network isn’t your PIN. It’s a version of your PIN that is completely illegible to everyone it passes through — including NPCI, including PhonePe, including anyone sniffing the network. The only place your actual PIN gets read is inside your bank’s own systems.

That’s what makes the two-factor system work. Your phone proves this is your device. Your encrypted PIN proves this is you authorising this specific transaction. Together, they’re enough.

What actually happens between “Pay” and “Successful”

There are five separate systems the payment passes through. I’ll walk through them in order, because the sequence matters.

Your phone talks to a bank you’ve probably never heard of.

PhonePe isn’t a bank. It’s just the app. Behind it sits what’s called a PSP — a Payment Service Provider — which is an actual licensed bank. Axis Bank plays this role for PhonePe. When you tap Pay, your encrypted request doesn’t go to PhonePe’s servers first. It goes to Axis Bank. Axis validates that the request is properly formatted, attaches some metadata about your account, and forwards it along.

Axis Bank passes it to NPCI’s switch.

This is the central router for all of UPI — NPCI’s UPI Switch, a cluster of servers that handles where every payment in the country needs to go. Think of it as the sorting facility in a post office, except it processes millions of items simultaneously and in real time.

Your payment contains the chaiwala’s UPI ID — something like chaiwala@upi. The switch looks up which bank that ID belongs to. Let’s say it’s SBI. Now NPCI knows the route: your payment needs to go from Axis Bank’s system, through the switch, to SBI.

NPCI asks your bank to take the money out.

This is the debit step. NPCI sends a request to your actual bank — the one holding your account — asking it to debit ₹20. Your bank receives the encrypted PIN, decrypts it with its private key, checks it matches, checks you have ₹20, checks you haven’t hit your daily limit, and either says yes or no. If yes, it debits the account and sends confirmation back to NPCI.

NPCI asks the chaiwala’s bank to put the money in.

Confirmation received from your bank, NPCI now tells SBI to credit ₹20 to the chaiwala’s account. SBI checks the account is active, not frozen, and does the credit. Sends confirmation back to NPCI.

Everyone gets told it worked.

NPCI informs both PSPs. PhonePe updates the transaction status. Your phone shows the green screen. Your bank sends an SMS. The chaiwala’s bank sends one too.

Total time: about two seconds.

I know I keep saying that, but it still gets me. Five institutions talking to each other, money verified and moved between two people who’ve never met, on a Sunday at midnight if that’s when you need chai — two seconds.

The thing that surprised me most: NPCI never touches your money

I assumed, when I started looking into this, that the money must pass through NPCI somehow. It doesn’t.

NPCI is a router, not a bank. Your bank takes the money out. The other person’s bank puts it in. NPCI just carries the instructions between them. At no point does NPCI hold your ₹20 even for a millisecond.

This matters because it means UPI is fundamentally different from a wallet. When you load money into Paytm Wallet, that money sits with Paytm’s system. You’re trusting Paytm with the funds. In UPI, your money stays in your bank account right up until the moment it transfers to someone else’s bank account. There’s no intermediate custody.

There’s a practical consequence to the PIN encryption that I didn’t think through until I’d traced the whole flow. If someone sees you type your PIN somewhere — over your shoulder, on a camera — they still can’t do anything with it. The PIN is useless without your registered device. The device is useless without the PIN. And even if someone somehow got both, the request still has to come from the right SIM, through your bank’s decryption chain, and your bank is checking all of this.

A breach at Google or PhonePe can’t expose your banking credentials because your PIN never reaches those systems in readable form. That’s not a policy promise, it’s structural — the system literally cannot send them something it never received.

Why this specific architecture

India has a few hundred banks. They all run different software, built by different vendors, in different decades. Getting all of them to talk to each other directly would have been a nightmare — you’d need every bank to integrate with every other bank, and the number of integrations required grows exponentially with each new player.

UPI solved this the way most network problems get solved: put something in the middle. Every bank integrates with NPCI once, using a common protocol. NPCI handles the routing between them. The number of integrations is now linear — add a new bank, it plugs into NPCI, and it immediately connects to the entire network.

The PIN encryption design came from a different problem. In 2016, asking Indians to type their bank PIN into a phone app made everyone nervous — users, banks, and the RBI. The fear was reasonable: what if PhonePe’s servers got hacked? What if Google was logging keystrokes? The encrypted SDK approach was how they addressed this. By building the encryption directly into a library that NPCI controlled and distributed to all app developers, the PIN never had to be trusted to any third party.

Banks agreed to join UPI partly because of this. They retained control of the most sensitive step in authentication. Their customers’ PINs stayed with them, not with some startup’s servers. That was a genuine concession to the banks, and it probably mattered for getting them on board.

The PSP model — where every UPI app has to be backed by a licensed bank — also came from the RBI’s insistence that someone with a banking licence be accountable for every transaction. PhonePe can build a great app, but Axis Bank is the one answering to the regulator.

The PIN is starting to go away

For almost a decade, the PIN was the main way UPI knew it was you. That’s changing.

Since October 2025, you can authenticate payments up to ₹5,000 using biometrics instead — fingerprint or face unlock, whichever your phone supports. For accounts linked to Aadhaar, there’s also UIDAI’s facial recognition as an option.

I’ve been thinking about who this actually changes things for. My mother, for one — she keeps her UPI PIN in a notes app because she was scared of forgetting it, which is exactly the kind of workaround that undermines the whole point of having a PIN. Biometrics removes that problem entirely. It’s not a fringe case; I’d bet a significant fraction of UPI users over fifty have some version of this issue.

The RBI has also said that by April 2026, all digital payment transactions need two-factor authentication, but the second factor no longer has to be a PIN specifically. Biometrics counts. Device-based verification counts. The formal shift is from proving “what you know” to proving “what you are.”

There’s also a parallel change happening underneath, which most users will never notice. NPCI has been building fraud detection that runs in real time alongside every transaction — analysing device behaviour, transaction patterns, location signals, and feeding all of it into a risk score before the debit request even reaches your bank. If the score is bad enough, the transaction gets flagged or stopped. The system is trying to catch anomalies before the money moves rather than investigate them after.

And then there’s UPI Lite, which launched in 2022 and takes a completely different approach for tiny payments. It preloads a small balance directly onto your phone’s storage, so payments under ₹500 can settle without any server contact at all. No five-institution handshake, no PIN. Near-instant even on bad internet. Think of it as a prepaid card stored on your phone.

Something I’ve been thinking about since I looked into this

The architecture of UPI is also, whether anyone intended it this way or not, a statement about power.

The most sensitive step in the entire payment flow — the decryption of your PIN — happens inside your bank’s servers. Not Google’s. Not PhonePe’s. Not NPCI’s. Your bank’s. This is not accidental. The team that designed UPI deliberately chose to keep the trust anchor with the banks.

In a lot of other payment systems, the app company becomes the entity you’re actually trusting. They hold your money, they hold your credentials, they’re the ones you call if something goes wrong. The bank becomes invisible infrastructure. I think most people in 2016 assumed India’s digital payment ecosystem would evolve in that direction too — that eventually some super-app would effectively replace the bank for most retail purposes.

That didn’t happen, partly because of this architecture. The fintechs got the apps and the users and the brand recognition. The banks kept the keys. Neither could operate without the other. Whether that was the intention from the beginning or just how things shook out, I honestly don’t know — but it’s a more interesting outcome than “fintech ate banking.”

What I’m less sure about is whether this balance survives what’s coming. AI agents that transact on your behalf, UPI expanding to other countries, credit products layered on top of UPI rails — all of it adds new intermediaries, new relationships, new points where the question of who holds the trust anchor gets complicated again.

The part I keep coming back to

Here’s what still gets me when I think about how this system works.

When you type your UPI PIN, it gets encrypted on your phone using a public key that belongs to your bank. The matching private key, the one that can actually read what you typed, sits only on your bank’s servers. Nothing that passes through the network in between is legible to anyone except your bank.

Which means PhonePe has processed hundreds of millions of your transactions and has never once seen your PIN. Same for Google Pay. Same for NPCI. The only entity that reads your PIN in plain text is the specific bank where you hold your account.

I find this kind of remarkable for a system that runs at 7,500 transactions a second, involving dozens of app companies and hundreds of banks. The most sensitive piece of data in the whole architecture never leaves the custody of the two parties it directly concerns — you, and your bank — and it does this at a scale that would have seemed absurd to anyone who designed banking systems in 2000.

Two seconds

The reason this works is not that any single piece is particularly clever. It’s that every piece has one job, and the jobs don’t overlap. The app handles what you see. The PSP handles the handoff to NPCI. NPCI handles the routing. Your bank handles authentication and debit. The receiver’s bank handles the credit. Nobody is trying to do someone else’s job.

That’s actually quite hard to build, especially across institutions that had never cooperated before and had real reasons to be suspicious of each other.

The next time you see “Payment Successful,” you’ll have a better sense of what just happened.

Next week

We’ve been through the full anatomy of a UPI payment now — what money is, how clearing works, what happens when it fails at scale, who pays for free, how the four underlying systems differ, and what fires inside those two seconds when you press Pay.

Next week I want to look at the everyday failures. Not the April outage — that’s a different category. I mean the common ones. Money debited but the other person never got credited. The “Payment Failed” screen with no explanation. The refund that shows up three days later with a reference number that goes nowhere.

Payments fail on UPI 0.6% of the time, which sounds low until you do the math: at 7,500 transactions a second, that’s forty-five failures every second. Someone’s money is stuck right now. Probably a lot of someones.

Next week: When Payments Fail. Why it happens, who’s accountable, and why getting your money back is sometimes harder than sending it.

Word count: ~2,500 words Arc 1 · Week 6 · How Money Moves

Subscribe now

It’s 10 PM on the last day of the month.

You just transferred ₹22,000 to your landlord. NEFT. You hit confirm, watched the loading spinner, and got a message: Transaction initiated. Amount will be credited within 2 hours.

Two hours. For something called a “transfer.”

Meanwhile, your friend in the same city just paid his landlord ₹22,000 on PhonePe. UPI. The money landed in under three seconds. His landlord sent a thumbs up emoji immediately.

Same city. Same bank. Same amount. Two completely different experiences.

You stare at your phone wondering if you did something wrong.

You didn’t. You just used a different train.

India has four different systems for moving money between bank accounts: RTGS, NEFT, IMPS, and UPI. All four are running right now, moving trillions of rupees every day. Most people have used at least two of them without realising they are completely different things — built at different times, for different purposes, by different organisations.

Each one was the right answer to a specific problem at a specific moment in India’s financial history. Together they form a layered stack, not unlike the infrastructure beneath a city. Roads under metro lines under expressways, all built in different eras, all still carrying traffic.

This week, we take each train apart.

The Core Concept — Why Four Systems?

Nobody sat down and planned four systems.

Each one was built to fill a gap that existed at the time. India didn’t design a unified payment architecture and then build the components. It solved the most urgent problem at each moment, and each solution became infrastructure that the next one had to work around.

Think of Mumbai’s transport network. The local trains didn’t arrive as part of a coherent master plan alongside the metro and the expressways. The trains came first, then the roads, then the expressways, then the metro — each era’s solution layered on top of the previous one.

India’s payment systems followed the same arc. And just like Mumbai’s trains still carry more passengers than its metro, some of India’s oldest payment rails still move more value than the newest ones.

The four systems, in order of birth:

RTGS — born 2004. For large, urgent, institutional transfers.
NEFT — born 2005. For everyday retail transfers, in batches.
IMPS — born 2010. For instant transfers, any time, any day.
UPI — born 2016. For everyone, on a phone, with just an ID.

The Technical Deep-Dive

Let’s take each system apart. Think of them as machines with different personalities, built for different jobs.

RTGS — The Armoured Freight Train

Real-Time Gross Settlement. Launched March 26, 2004. Operated directly by the Reserve Bank of India directly.

The key word in the name is gross. Gross means each transaction is settled individually, one by one, in real time. Your ₹50 lakh transfer doesn’t wait in a queue with other transfers. It moves alone, right now, and lands in the recipient’s account within minutes.

This makes RTGS the most powerful system in India’s payment stack. But it has rules. The minimum transaction amount is ₹2 lakh. There is no maximum — you can move hundreds of crores in a single RTGS transfer if your bank allows it.

Why ₹2 lakh minimum? Because RTGS was designed for institutional money. The kind of transfer where waiting two hours is not an option — property payments, business settlements, corporate disbursements where the person on the other end needs confirmation right now.

Before RTGS existed, banks used to settle transfers between themselves manually at the end of each day. If one bank failed to deliver, the entire chain could collapse — a domino effect that could trigger a systemic crisis. RTGS eliminated that risk by settling each transaction in isolation, in real time, with immediate finality.

In 2024 alone, RTGS processed 29.53 crore transactions worth ₹1,938 lakh crore. That’s more than twice India’s entire GDP, moved through a single system in one year.

NEFT — The Scheduled Passenger Express

National Electronic Funds Transfer. Launched November 2005. Also operated by the RBI. Built on the same infrastructure as RTGS, but designed for a completely different purpose.

Where RTGS settles every transaction immediately, NEFT collects transactions into batches and settles them together every 30 minutes. Right now, somewhere, a NEFT batch is being processed. In 30 minutes, another one will run.

This is called deferred net settlement. Instead of moving every rupee immediately, NEFT figures out the net amounts owed between banks — who owes whom, after all the back-and-forth — and settles the difference. It’s more efficient for the banking system, even if slower for the individual.

NEFT has no minimum transaction limit. You can transfer ₹1 or ₹1 crore. There’s no maximum either, though individual banks set their own caps. Since January 2020, online NEFT from savings accounts is completely free — the RBI instructed banks to waive charges.

It’s the workhorse of India’s retail payment system — EMI payments, credit card dues, utility bills, the stuff that doesn’t need to arrive in the next three seconds but needs a clean paper trail. That trail actually matters for things like rent payments that show up on HRA declarations, where a UPI screenshot isn’t always enough.

IMPS — The Late-Night Express

Immediate Payment Service. Launched November 22, 2010. And this one is different — operated by NPCI, not the RBI.

IMPS was built to solve a specific frustration: RTGS and NEFT both had working hours. You couldn’t transfer money at 11 PM on a Sunday. If someone needed emergency funds on a holiday, they were stuck.

IMPS changed that. Instant transfer, 24 hours a day, including Diwali and New Year’s Day.

The limit was originally ₹2 lakh per transaction. In 2021, the RBI increased it to ₹5 lakh. Most banks charge a small fee — somewhere between ₹2.50 and ₹25 depending on the amount and the bank.

India was only the fourth country in the world to launch such a system — after South Korea, the UK, and South Africa. In 2024, IMPS processed 593 crore transactions worth ₹70.71 lakh crore. It still runs at enormous scale today, mostly invisible to the people using it.

Why still relevant when UPI exists? Because IMPS works for bank-to-bank transfers when you have the IFSC code and account number but not a UPI ID. It’s used heavily in mobile banking apps and by people who want a more formal, traceable transfer than a UPI payment.

UPI — The Metro

Unified Payments Interface. Launched 2016. Built by NPCI. And here’s the thing most people don’t know: UPI is not a separate payment system underneath. It’s a layer built on top of IMPS.

UPI didn’t replace the railway. It built a metro line over the existing tracks. The UPI layer handles the user experience — the app, the virtual ID, the QR code, the PIN. But when you press send, the actual movement of money uses IMPS rails.

What UPI added was the abstraction layer. You don’t need to know someone’s bank account number or IFSC code. You just need their phone number, their UPI ID, or a QR code. UPI made the complexity invisible.

The default limit is ₹1 lakh per transaction for most users, though specific use cases like healthcare and education get higher limits. It’s free. It’s instant. And it now handles more daily transactions than Visa globally.

The Ripple Effects — Real People, Real Systems

These aren’t abstract distinctions. The system you use determines what happens to you.

Priya, a small business owner in Coimbatore, gets paid by her corporate clients via NEFT. The amounts are large — ₹3 to ₹8 lakh per invoice. NEFT gives her a formal transaction record for her accountant, no fees, and predictable settlement within the hour. For her, UPI’s ₹1 lakh limit is irrelevant. NEFT is the right tool.

Rahul, a freelance designer in Bangalore, just sent ₹1,50,000 as a security deposit for a new apartment at 9 PM on a Sunday. The landlord needed confirmation that night. IMPS. Instant. The landlord got the SMS notification within seconds. NEFT would have made them wait until the next morning batch. UPI had a lower limit than he needed.

The treasury team at a large manufacturing company in Pune runs RTGS transfers every morning — supplier payments in the crores, where each transaction must settle individually and with immediate finality. No batch processing. No aggregation. Every rupee accounted for in real time. RTGS is the only system that works for this.

Your mother in a smaller city, paying your school fee online because she heard UPI is free — she’s probably actually using IMPS underneath without knowing it. The bank app says “IMPS” in small letters at the bottom of the confirmation screen. She never reads it.

Why Was It Built This Way?

Each system exists because of the specific gap it was filling when it was created.

2004: The RTGS gap. Before RTGS, large inter-bank transfers happened through manual end-of-day netting. Banks accumulated obligations throughout the day and settled the net amounts at close. If one bank in the chain couldn’t pay, the entire system was exposed. RTGS eliminated that by settling each large transaction individually and immediately. The RBI prioritised systemic stability. Hence the ₹2 lakh minimum — it was never meant for small transfers.

2005: The NEFT gap. RTGS was built for institutions. Retail customers needed something too — a way to transfer any amount to any bank in India without visiting a branch. It didn’t need to be instant. Batch processing was fine. The goal was coverage and reliability.

2010: The 24x7 gap. RTGS and NEFT both had working hours. Emergencies don’t follow banking hours. NPCI built IMPS to fill the nights and weekends — a system that never sleeps. India was only the fourth country globally to build something like this.

2016: The friction gap. IMPS solved the time problem but not the complexity problem. You still needed account numbers, IFSC codes, and mobile banking credentials. UPI removed all of that. A phone number or a QR code. Suddenly hundreds of millions of people who found net banking intimidating could send money.

The Bigger Picture — The Stack

Here is the thing that took me a while to fully appreciate.

These systems are not competing. They are stacked.

UPI sits on top of IMPS. IMPS settles through RTGS. NEFT settles through the same RTGS infrastructure. Which means when you tap PhonePe to pay for your chai, the trail underneath looks something like this:

UPI layer handles the user experience → IMPS rails move the money → at the end of the day, NPCI calculates the net obligations across all IMPS and UPI transactions → that net settlement batch goes to RTGS → RTGS settles it between banks using accounts held at the RBI.

The payment system beating Visa on transaction count settles through infrastructure built in 2004. The metro runs on the old railway’s tracks.

That’s not a flaw. You don’t tear up roads when you build highways. The new builds on the old, and the old becomes the foundation.

RTGS is the foundation of India’s entire digital payment stack. Most people have never heard of it.

The Mind-Blown Moment

When you pay your chai vendor ₹20 on PhonePe — and they get it in two seconds — here is what actually happens underneath:

The UPI layer processes your request. The IMPS rails execute the transfer. Later that day, NPCI bundles this ₹20 transaction with hundreds of millions of others, calculates the net obligations, and submits a settlement file to RTGS. The RBI’s own system — built for institutional transfers above ₹2 lakh — processes a batch file that includes your ₹20 chai payment.

India’s newest infrastructure runs on India’s oldest infrastructure.

And RTGS doesn’t just settle IMPS and UPI. The stock market (NSE, BSE), government securities, interbank lending — every major financial system in India eventually flows through RTGS and lands in accounts held at the Reserve Bank of India.

The RBI is not just the regulator. It is the settlement layer for the entire economy.

The Takeaway

Four trains. One track.

RTGS moved ₹1,938 lakh crore in 2024 — more than twice India’s GDP. It’s invisible to most people and essential to every institution.

NEFT handles the reliable, scheduled stuff: EMIs, invoices, rent. Batched, unglamorous, and free online since 2020. Still processing hundreds of crore transactions a month.

IMPS fills the gaps the others can’t — instant transfers at 2 AM on a holiday, up to ₹5 lakh, with a small bank fee.

UPI does most of what IMPS does, but hides all the complexity behind a phone number and a QR code. It’s the reason your mother can pay for groceries without knowing what IMPS is — even though she’s probably using it.

The next time you see those four options in your banking app, you’ll know what you’re looking at. Four different answers to four different questions about how money should move.

Next Week

Five weeks in, we’ve covered what money is, how clearing works, what happens when it fails, who pays for it, and how the four main systems differ.

Next week, we slow down and look at something more fundamental.

Every time you send money, there’s a moment of trust. The system has to know you are who you say you are. That your PIN is yours. That this transaction was authorised by you.

Two seconds of verification sitting between you and fraud.

Next week: The Two-Second Journey. What actually happens in the moment between pressing “Pay” and seeing “Success.”

Word count: ~2,500 words Arc 1 · Week 5 · How Money Moves

Imagine walking into a restaurant where everything is free.

The food is good. The service is fast. The waiters are polite. You order, eat, pay nothing, and leave. You come back the next day. And the day after. Thousands of people do the same, every single day.

The restaurant never charges anyone. It never closes. It keeps getting bigger.

You’d eventually ask: who is paying for all of this?

That’s the question at the heart of UPI.

Subscribe now

Every time you tap your phone to pay the autorickshaw driver, or split a dinner bill with friends, or pay your electricity bill at midnight — you pay nothing. The merchant pays nothing. The banks charge nothing.

UPI is free. Completely, stubbornly, policy-mandated free.

In May 2025 alone, UPI processed 18.68 billion transactions worth ₹25.14 lakh crore. That’s more transactions in a single month than Visa processes globally in the same period. The infrastructure running this — servers, engineers, security systems, fraud detection, customer support — costs real money.

So where does the money come from?

The answer involves a government policy decision, a ₹1,500 crore annual subsidy, a group of companies bleeding quietly, and one of the most important unresolved debates in Indian fintech.

Welcome to Week 4 of How Money Moves. This week: the economics of free.

What Is MDR and Why Does It Matter?

To understand why UPI being free is remarkable, you first need to understand how payment systems normally make money.

When you swipe a credit card at a shop, the merchant doesn’t receive the full amount you paid. A small fee — typically 1.5% to 3% — is deducted before the money reaches them. This fee is called the Merchant Discount Rate, or MDR.

That 1.5–3% isn’t going to one place. It’s split between several parties: the bank that issued your card, the bank that the merchant uses, the card network (Visa or Mastercard), and the payment processor. Each takes a slice.

This is how the global payments industry makes hundreds of billions of dollars a year. It’s the invisible tax on every card transaction you’ve ever made. Every time you tap your Visa card at a coffee shop, a fraction of a percent flows through a quiet distribution system that most people never think about.

India’s UPI was designed to be different.

Since January 2020, the MDR on UPI transactions has been set at exactly zero. By law. The government amended the Payments and Settlement Systems Act to make it so.

Zero for the user. Zero for the merchant. Zero for everyone.

Which means zero revenue for the banks processing these transactions. Zero for the fintech companies running the apps. Zero for NPCI maintaining the rails.

The restaurant is full. The kitchen is running at full capacity. And nobody is paying the bill.

Subscribe now

So Who Actually Pays?

The answer is: the government of India. Partially. And banks. Also partially. And fintech companies. Unhappily.

Let’s break it down.

The Government Subsidy

The government doesn’t want UPI to die. It’s one of the most successful digital public infrastructure projects in history. It has formalized hundreds of billions of rupees of economic activity, brought millions of small merchants into the digital economy, and given India a geopolitical calling card — a payments system that now beats Visa in daily transaction volume.

So the government pays for part of it.

In the financial year 2024–25, the Union Cabinet approved a ₹1,500 crore incentive scheme specifically for low-value UPI transactions. Here’s how it works: for every UPI transaction up to ₹2,000 at a small merchant, the government pays the acquiring bank (the merchant’s bank) an incentive of 0.15% of the transaction value. That acquiring bank then shares this with the issuing bank, the payment service provider, and the app company.

In other words: the government is paying the MDR that merchants don’t have to.

But ₹1,500 crore sounds large. Is it enough?

To put it in perspective: UPI processed ₹213.8 lakh crore in transactions through January 2025. The total incentive pool of ₹1,500 crore covers only person-to-merchant transactions under ₹2,000 — a fraction of the total volume. Large merchants, large transactions, and person-to-person payments receive no incentive at all.

The restaurant is receiving a small government voucher. But the kitchen is running 24 hours a day.

The Banks Absorbing the Rest

For everything outside the incentive scheme — and that’s a lot — banks are absorbing the cost themselves.

Banks spend real money processing UPI transactions. Every API call, every fraud check, every customer dispute, every system upgrade — someone pays for it. With zero MDR, banks pay for all of this out of their own pockets, hoping that the data, the customer relationship, or some future monetization opportunity will make it worth it.

This is not a sustainable model indefinitely. And banks know it.

The Fintech Companies

PhonePe, Google Pay, Paytm — the apps you actually use — earn nothing directly from UPI transactions. Zero. They have invested billions in building UPI infrastructure, maintaining apps used by hundreds of millions of people, and running customer support operations at enormous scale.

Their bet is that UPI is a distribution channel. Get the users. Keep them engaged. Then sell them other products — insurance, mutual funds, loans, gold. The payment is the door. The financial product is where the money is.

It’s a logical strategy. But it means UPI itself is a cost center, not a revenue center. And it’s a very expensive cost center.

NPCI’s own CEO acknowledged that the absence of a revenue model on UPI may have deterred new players from entering the market.

The Ripple Effects

The zero-MDR policy has consequences that ripple through the entire payments ecosystem.

Small merchants won. A kirana store owner in Varanasi pays nothing to accept UPI payments. Before zero MDR, accepting digital payments meant giving up 1–2% of every sale. For a business running on thin margins, that was often not worth it. Zero MDR removed that barrier. This is genuinely one of the most pro-small-business policies in modern Indian economic history.

Users won. 300 million users and 50 million merchants use UPI across India. None of them pay a transaction fee. The cognitive friction of “is this worth the fee?” simply doesn’t exist.

Banks are quietly stressed. With zero MDR, banks are presently absorbing the operational cost of the entire UPI system. As transaction volumes grow — and they will keep growing — this cost grows with it. A system processing 20 billion transactions a month costs more to run than one processing 2 billion.

The fintech ecosystem is distorted. With no revenue from transactions, companies compete on everything except the core service. Features, cash rewards, UPI cashbacks, gamification — all funded by investors hoping future monetization will arrive. The Payments Council of India has flagged that the ecosystem faces pressing financial sustainability concerns.

Innovation is constrained. Why would a new company invest heavily in building better payment infrastructure if it can’t charge for it? NPCI’s CEO noted that zero MDR had deterred new entrants. The very policy that made UPI accessible also made it unattractive to build on.

Subscribe now

Why Was It Built This Way?

The zero-MDR decision wasn’t accidental. It was a conscious policy choice rooted in a specific theory of change.

The financial inclusion argument. India in 2019 had hundreds of millions of people and merchants who had never used digital payments. They weren’t avoiding it because they lacked access — smartphones were cheap, internet was spreading. They were avoiding it because of cost. A 1–2% MDR meant small transactions were simply not worth digitizing. A ₹50 chai purchase with a 1% MDR means the vendor loses 50 paise every time. Across millions of daily transactions, that adds up to a real income reduction.

Zero MDR removed that barrier permanently. It said: we want digital payments to reach everyone, including people for whom even 0.5% matters.

The formalization argument. Every digital transaction leaves a trace. Tax authorities can see it. Credit bureaus can use it. The government can verify it for subsidy delivery. Cash transactions leave no trace. India has a massive informal economy. Every merchant who switches from cash to UPI creates a data trail that makes the economy more legible, more taxable, more formalizable.

The government gave up MDR revenue in exchange for a larger formalized economy. It’s a policy bet.

The adoption flywheel argument. Network effects in payments are brutal. A payment system only works if both sides — payers and receivers — are on it. You need merchants before users will come. You need users before merchants will come. By making it free for everyone, India broke this chicken-and-egg problem. Zero friction on both sides meant both sides adopted simultaneously.

This strategy worked. UPI now accounts for 84% of all digital retail payments in India.

But the question remains: now that the flywheel is spinning, does it need to be free forever?

The Debate — Can Free Last Forever?

This is the most live policy debate in Indian fintech right now. And it has no clean answer.

The case for keeping it free:

UPI’s success is inseparable from its zero-cost model. The moment you introduce any fee — even 0.1% — you create friction. Small merchants in tier-3 cities start calculating. Customers start thinking twice about small transactions. The government’s financial inclusion goals retreat.

The Ministry of Finance has repeatedly and firmly dismissed any suggestion of MDR on UPI, calling such speculation “false, baseless, and misleading.” The political economy is clear: UPI is free, UPI will stay free, and any politician who suggests otherwise will hear about it from 300 million users.

The case for introducing some form of MDR:

The current model has a structural problem. The government subsidy covers only a fraction of the true cost. Banks are absorbing the rest indefinitely. Fintech companies are burning investor money hoping for future monetization.

This works in a growth phase. But as the system matures, investor patience runs out, banks face margin pressure, and the infrastructure starts aging without the revenue to upgrade it.

Industry bodies like the Payments Council of India argue that without a sustainable revenue model, the long-term reliability and innovation of UPI is at risk. The April 2025 outage — triggered partly by banks not investing enough in proper API rate-limiting infrastructure — is one data point suggesting that the cost-cutting is already having consequences.

The most likely middle path: a tiny MDR on large-value transactions only, exempting small merchants and low-value payments entirely. A surgical fee that doesn’t touch the financial inclusion use case but creates a revenue stream for the ecosystem.

But even this is politically difficult. Once you open the MDR door, it’s hard to close.

The Bigger Lesson

The UPI zero-MDR experiment is a fascinating case study in what happens when you treat a market service as public infrastructure.

Roads are free to drive on. The government builds and maintains them because the economic value they create — commerce, mobility, connectivity — far exceeds the cost of building them. You don’t pay a toll on every street.

India has made a similar bet with UPI. The argument is: the economic value of a fully digital, fully connected payment system — the GDP growth, the tax revenues, the financial inclusion, the data infrastructure — far exceeds the ₹1,500 crore annual subsidy.

It’s a reasonable bet. And so far, the numbers suggest it’s paying off.

But every public good faces the same long-term question: who pays for maintenance? Roads need repair. Bridges need inspection. And payment infrastructure needs constant investment in security, capacity, and resilience.

The April 2025 outage was a small preview of what happens when infrastructure runs on subsidized goodwill rather than sustainable revenue. The banks and fintechs maintaining UPI are doing so at a loss. People working at a loss eventually cut corners. And the corners they cut tend to be the invisible ones — the rate limiters, the redundant systems, the failsafe protocols.

Free is a powerful force. But free has a cost. Someone always pays for it.

The question is whether India figures out who that is before the bill comes due.

Subscribe now

The Mind-Blown Moment

Here’s the number that gets me every time.

UPI now processes more daily transactions than Visa. Not more than Visa in India. More than Visa globally.

A system built in India, run by a non-profit, charging exactly zero fees, is outpacing the largest card network in the world — a company with a market capitalisation of over $500 billion.

Visa’s business model is MDR. Every transaction generates revenue. That revenue pays for Visa’s engineering, security, global network, and $18 billion in annual revenue.

UPI’s business model is: the government pays a subsidy, banks absorb the rest, and fintechs hope for the future.

And yet UPI is bigger. By transaction count, it’s the largest real-time payment system in the world.

This is either the most impressive public infrastructure story of the 21st century. Or it’s a balloon that looks magnificent right now but needs someone to figure out the physics before it gets too high.

Possibly both.

The Takeaway

UPI is free because India made a deliberate choice: adoption matters more than revenue.

That choice worked. Spectacularly. 84% of digital retail payments. 50 million merchants. Financial inclusion at a scale no card network ever achieved in India.

But “free” is not a permanent state of nature. It’s a policy choice. And policies can change — or they can break under their own weight.

The zero-MDR debate will define the next decade of Indian fintech. It will determine whether UPI can keep attracting investment, whether banks will keep absorbing costs without complaint, and whether the infrastructure will keep scaling without cracks.

For now, the restaurant is open. The food is good. And the bill is somewhere in a filing cabinet at North Block, quietly accumulating interest.

Next Week

We’ve now covered what UPI is (Week 1), how clearing works (Week 2), what happens when it fails (Week 3), and who pays for it (Week 4).

But we’ve been treating UPI as a single thing. It isn’t.

There’s UPI. And then there’s NEFT, IMPS, and RTGS. Four completely different systems, each with different speeds, different purposes, and different costs.

Most people have no idea which one is actually moving their money — or why it matters.

Next week: UPI vs NEFT vs IMPS vs RTGS. Think of it as four different types of trains on the same railway network. Same destination. Very different journeys.

Word count: ~2,500 words Arc 1 · Week 4 · How Money Moves

Leave a comment

Share Thinking Out Loud

It’s a Saturday evening. March 26, 2025. 7 PM.

Across India, millions of people are trying to pay for things.

A sabziwala in Pune taps his QR code screen toward a customer. Nothing. A college student in Bengaluru tries to split dinner with friends. Declined. A delivery rider in Delhi finishes a long shift and tries to collect his payout. The app just spins.

In less than an hour, DownDetector — a platform that tracks app outages — logs 2,750 complaints about UPI. Google Pay, PhonePe, Paytm, HDFC Bank, State Bank of India, Bank of Baroda, Kotak Mahindra Bank. All affected. All at once.

NPCI posts on X: “sporadic technical challenges.”

The internet reacts differently. Memes flood Twitter within minutes. Users write, half-joking: “UPI is down for the first time and I don’t know how to exist.”

By 8:40 PM, services are restored. The outage lasted about 100 minutes.

But then it happened again. On April 12, it lasted nearly five hours — the longest disruption in UPI’s history. Success rates fell to 50% for two hours. Then crawled back to 80% for three more.

For a system that processes 18 billion transactions a month — that’s roughly 6,900 transactions every second — even 100 minutes of downtime is not a technical hiccup. It’s a national event.

So what actually happened? And why does a system this large have a way of failing this completely?

The answer has a name. Engineers call it the single point of failure.

What Is a Single Point of Failure?

Imagine a city with one bridge.

Just one. Over a wide river. Every car, every truck, every bus — everything that needs to cross uses this bridge.

On most days, it works beautifully. Traffic flows. The city functions.

But what happens when the bridge needs maintenance? Or a pillar cracks? Or there’s a three-car pile-up in the middle?

Everything stops. The entire city, on both sides of the river, grinds to a halt. Not because the city is broken — but because the one thing everything depended on stopped working.

That bridge is what engineers call a single point of failure (SPOF).

A single point of failure is any component in a system where, if it stops working, the entire system stops working with it.

It doesn’t matter how good everything else is. The bridge can be beautifully engineered, perfectly maintained, and used flawlessly for years. The moment it fails, none of that matters.

NPCI is India’s bridge.

Every UPI transaction — whether you’re paying ₹10 for chai or ₹10 lakh for a car — flows through NPCI’s infrastructure. Your bank talks to NPCI. The merchant’s bank talks to NPCI. NPCI talks to everyone.

There is no other bridge.

The Technical Deep-Dive

To understand what actually broke, you need to understand one small but critical piece of how UPI works.

When you make a UPI payment, here’s what happens in the background:

1. You initiate a payment on your app.

2. Your bank sends a payment request to NPCI.

3. NPCI routes it to the recipient’s bank.

4. The recipient’s bank confirms. NPCI sends confirmation back. Done.

Simple enough. But here’s where it gets complicated.

What if the confirmation never comes back?

Maybe the recipient’s bank server is slow. Maybe the network hiccuped. Maybe NPCI itself took a moment to respond. Your bank sends a payment request — and hears silence.

So your bank does the logical thing: it sends a “Check Transaction Status” API call. Essentially asking NPCI: “Hey, did that payment go through?”

This is normal. This is expected. This is how the system is designed.

But on March 26, and again on April 12, something went wrong with this mechanism.

Banks didn’t just send one “Check Transaction” request. They sent thousands. Repeatedly. For the same transactions. For old transactions. Without waiting for a response before sending another.

Imagine calling someone on the phone. They don’t pick up. So you call again. And again. And again. Fifty times a minute. Now imagine every bank in India doing this simultaneously. Millions of calls. All hitting NPCI’s servers at once.

The April 12 outage was caused by payment service provider banks sending an excessive number of these “Check Transaction Status” API calls, which overwhelmed the system’s capacity and led to instability.

NPCI engineers tried to fight back. They attempted to isolate the problem — blocking certain nodes, cutting off the flood at specific points. Standard crisis protocol. But the requests kept coming from too many directions at once. The dam held in some places. Leaked in others.

The success rate of UPI payments fell dramatically to approximately 50% for nearly two hours and stayed at approximately 80% for the subsequent three hours.

The system wasn’t hacked.

No data was stolen. No fraud occurred.

The system simply got flooded — by its own participants, trying to do the right thing.

The Ripple Effects

When UPI goes down, it doesn’t just inconvenience people with smartphones.

It breaks a chain.

The street vendor. Raju runs a chaat stall near a college in Hyderabad. Over 70% of his customers pay by UPI. On April 12 — a Saturday afternoon during IPL season — he loses three hours of peak business. He can’t tell customers to go find an ATM. Most of them don’t carry cash anymore. They simply walk away.

The delivery rider. Meera has completed 14 deliveries by 3 PM on April 12. Her payout is processed through a UPI-linked account. During the outage, her settlement is delayed. She needs that money to refuel her scooter for the evening shift. She waits.

The small business. An online clothing store on Instagram runs a weekend flash sale. Customers try to pay and can’t. Orders are abandoned. By the time UPI recovers, the moment has passed. The sale is effectively over.

The hospital. A pharmacy attached to a mid-sized hospital in Chennai processes hundreds of transactions daily through UPI. During the outage, patients queue at the counter. Staff scramble to find a working payment method. The line grows.

None of these people made a mistake. None of them did anything wrong. But they all paid the price for a decision made years ago — to route everything through one system, one organisation, one set of servers.

During the UPI outages, users had little choice but to wait for services to recover, underscoring the need for more resilient alternatives. Though cash is always available as an option, many customers today avoid handling cash and prefer the speed and ease of digital payments.

This is what concentration risk feels like at the ground level.

Why Was It Built This Way?

Here’s a fair question: if centralisation is so dangerous, why did India build UPI this way?

The answer is that centralisation wasn’t a mistake. It was a deliberate, rational choice — made for very good reasons.

Speed. A centralised system is faster to build and faster to update. When RBI wants to add a new feature or fix a security vulnerability, they talk to one organisation: NPCI. Done. A distributed system would require coordinating dozens of banks simultaneously — a nightmare of governance and version control.

Standardisation. Before UPI, every bank had its own payment format, its own protocols, its own quirks. NPCI created one common language. Every bank speaks it. Every app uses it. Interoperability — the magic that lets a PhonePe user pay a Google Pay merchant — exists because of this central standard.

Trust. When something goes wrong, there’s one number to call. One organisation to hold accountable. One RCA (Root Cause Analysis) to publish. Accountability is cleaner when there’s a single throat to choke.

Cost. Building competing payment rails is expensive. India chose to invest in one excellent infrastructure rather than five mediocre ones.

These are not small benefits. They’re the reason UPI scaled from near zero to 18 billion monthly transactions in under a decade. No other country has done this at this speed.

But every design choice has a shadow side.

The same centralisation that made UPI fast to build, easy to standardise, and simple to govern — is also what makes it vulnerable to exactly the kind of cascading failure we saw in April 2025.

The Reserve Bank of India had conceptualised the idea of a National Umbrella Entity (NUE) to reduce the risk of concentration on NPCI — a competitor to NPCI, a second bridge. They invited bids in 2020. But in April 2023, RBI officially scrapped the idea. The proposals received weren’t innovative enough to justify building a parallel system.

The decision to stick with one bridge was reaffirmed just two years ago.

The bridge was designed to carry this load. But no one built a second bridge.

What’s Being Built Now

The April 2025 outage wasn’t ignored. It triggered a serious response.

Immediate fixes. NPCI issued new guidelines directing payment service provider banks to limit the usage of “Check Transaction Status” APIs — the first check must now be initiated only after 90 seconds of the original transaction. Banks can no longer flood the system with status checks for old transactions.

Rate limiters. NPCI is considering introducing rate limiters on certain APIs which would restrict how many times a particular call can be made within a specific time frame. Think of this as a bouncer at the door — you can only enter so many times per minute.

IP-based controls. NPCI now has TPAP-specific IPs which can be blocked, giving NPCI control to stop transactions from a particular source without affecting the flow of other apps or banks. Surgical intervention instead of shutting everything down.

Annual audits. PSP banks will now be required to undergo yearly audits assessing their API usage and system configuration. The equivalent of mandatory vehicle inspections for anyone allowed on the bridge.

UPI Lite. UPI Lite allows users to make small payments without internet access, using nearby device-to-device NFC communication. It can prove useful during short network outages, but it only works for small amounts and is not widely used. A partial bypass road — for light traffic only.

But the deeper structural question remains unanswered.

Should India build a second bridge?

The NUE (New Umbrella Entity) framework — proposed by RBI in 2019, shelved in April 2023 — is now under renewed spotlight. The idea was to create competing payment infrastructure parallel to NPCI. A second bridge. RBI killed it two years ago. The 2025 outages have reopened the conversation.

The argument for it is simple: two bridges are more resilient than one. If one is under maintenance, traffic moves to the other. The city doesn’t stop.

The argument against it is also simple: building a second bridge costs money. Coordinating two bridges is complex. And India’s first bridge — despite its flaws — is one of the most impressive pieces of financial infrastructure ever built.

This tension — resilience vs. efficiency, distribution vs. standardisation — is one of the oldest problems in system design. There is no clean answer. Only trade-offs.

The Bigger Lesson

UPI’s April 2025 outage is a story about scale.

When a system handles 6,900 transactions per second, even small design decisions have enormous consequences. A missing rate limiter. A missing wait-time between API calls. Banks behaving individually-rationally but collectively-destructively.

This is what economists call a tragedy of the commons. Each bank, looking out for its own customers, sends more “Check Transaction” requests to get answers faster. Reasonable. But when every bank does this simultaneously, they collectively destroy the very system they were trying to use.

No single bank caused the outage. All of them did.

This pattern — individual rationality producing collective failure — shows up everywhere in complex systems. Traffic jams. Financial crashes. Social media misinformation. The internet’s spam problem.

The solution isn’t to blame individual actors. It’s to redesign the rules of the commons.

That’s exactly what NPCI is doing with its new API guidelines. Not punishing banks. Changing the game.

But the deeper lesson is this: resilience is not free. It costs money. It costs complexity. It costs the elegance of having one clean, simple system.

India chose elegance and speed when it built UPI. That choice gave 1.4 billion people access to instant payments. It also created a bridge that, on three days in 2025, the whole country discovered they couldn’t live without — and couldn’t use.

The Mind-Blown Moment

Here’s what still gets me.

The April 12 UPI outage wasn’t caused by a cyberattack. It wasn’t caused by a natural disaster or a power failure.

It was caused by banks doing exactly what they were supposed to do.

When they didn’t get a confirmation, they asked again. And again. And again. That is correct behaviour for a bank managing your money. You would want your bank to keep checking until it gets an answer.

The system failed not because someone did something wrong — but because everyone did the right thing, at the same time, on a system that wasn’t designed for that scenario at that scale.

That’s the paradox of complex systems. The failures aren’t usually caused by malice or stupidity. They’re caused by the gap between how each individual part was designed to behave and how the whole system actually behaves when everything runs at once.

Industry payment executives voiced concerns about the frequent outages, calling the UPI system “completely broken” and lacking in transparency. Some disclosed that downtimes cause unprocessed customer and merchant transactions, and pointed to a capacity issue with banks.

The bridge didn’t crack because someone hit it with a hammer. It cracked because everyone tried to cross at the same time.

The Takeaway

UPI is one of the most impressive digital infrastructure projects in human history. 18 billion transactions a month. Nearly instant. Nearly free. Available to anyone with a smartphone and a bank account.

But it has one bridge.

The outages of 2025 were a stress test — and the system passed, barely. NPCI responded quickly. Services were restored. Fixes were implemented. The system is better today than it was in March.

But the structural question remains open: as India’s economy becomes more dependent on UPI every year, how much concentration risk is acceptable?

That’s not a technical question. It’s a policy question. A values question. And the answer will shape the next decade of India’s financial infrastructure.

For now, the bridge stands. The engineers are watching it more carefully. And somewhere, in an RBI filing cabinet, there’s a proposal for a second bridge — waiting.

Next Week

This week we talked about what happens when the infrastructure fails.

But here’s a question we haven’t answered yet: who actually pays for all of this?

UPI is free for users. Free for merchants. Free for nearly everyone.

But running 18 billion transactions a month is not free. Servers cost money. Engineers cost money. The entire NPCI operation costs money.

So where does the money come from? And is “free forever” actually sustainable?

Next week: Who Pays for Free? The economics behind India’s zero-MDR experiment — and why it might be the most important policy debate in Indian fintech right now.

Word count: ~2,400 words Arc 1 · Week 3 · How Money Moves

You’re at a restaurant with friends.

The bill arrives: ₹4,000.

Everyone opens their payment app and sends you their share.

Sankalp (HDFC Bank) → You (ICICI): ₹1,000
Yash (Axis Bank) → You (ICICI): ₹1,000
Santosh (SBI) → You (ICICI): ₹1,000

Your phone buzzes three times.

“Payment received.”
“Payment received.”
“Payment received.”

Two minutes. Done. Everyone’s settled.

It just works.

But here’s what I still don’t understand:

How does ICICI Bank know that HDFC, Axis, and SBI actually sent the money?

What if HDFC is lying?

What if the message got lost somewhere between Mumbai and Bangalore?

What if someone hacked the message and changed ₹1,000 to ₹1?

Last week, we learned that money is just a ledger. Numbers in databases getting updated.

This week, we’re tackling the obvious follow-up question:

If my money is just a number in HDFC’s database, and your money is just a number in ICICI’s database... how do these databases talk to each other without everything exploding?

This is called The Clearing House Problem.

And it’s way more paranoid than you think.

The Naive Idea: “Why Don’t Banks Just... Talk?”

Okay, so money is just updating ledgers (we learned this last week).

Why don’t banks just call each other?

HDFC calls ICICI: “Hey, our customer just sent you ₹1,000. Please credit them.”

ICICI says: “Cool, done.”

Problem solved, right?

Wrong.

Let me show you why this breaks immediately.

Problem #1: The Trust Issue

Banks are competitors.

HDFC and ICICI are literally competing for the same customers. They run ads against each other. They poach each other’s employees.

Now imagine HDFC calls ICICI and says: “We just debited our customer ₹1,000. Please credit yours.”

Why should ICICI believe them?

What if HDFC is lying to make their customer happy?

What if HDFC doesn’t actually have the money?

What if HDFC’s database crashed and they’re sending duplicate messages?

You need proof. But how do you prove you updated a database?

Screenshots? Those can be faked.

API responses? Those can be forged.

Trust doesn’t scale in a competitive environment.

Problem #2: The Volume Issue

Let’s do the math.

India has approximately 100 banks that participate in digital payments.

If every bank needs to talk to every other bank directly...

That’s 100 × 99 = 9,900 connections to maintain.

And we’re not talking about a few transactions.

As of early 2025, UPI processes approximately 20 billion transactions per month, averaging 690 million transactions per day.

If every bank had to verify every transaction with every other bank directly...

Messages would get lost.

Systems would crash under load.

Nobody would know who owes what to whom.

It would be complete chaos.

Problem #3: The Timing Issue

Here’s another problem.

Let’s say HDFC sends a message to ICICI at 2:00 PM: “We’re sending you ₹1,000.”

But ICICI’s server is down for maintenance.

The message bounces. Gets lost in the void.

HDFC’s customer sees: “Payment Successful ✓”

ICICI never received anything.

Now what?

Who’s responsible?

How do you prove the message was sent?

How do you retry without accidentally sending the money twice?

This is when you realize:

You can’t have 100 entities trying to coordinate directly.

You need a middleman.

Someone neutral.

Someone everyone trusts.

Someone who keeps track of EVERYTHING.

You need a Clearing House.

The Coffee House Solution (Well, Sort Of)

This problem isn’t new.

In the 1770s, London had the same issue.

Not with digital payments—with paper checks.

Imagine you’re a London bank in 1770. Your customers write checks to customers at other banks. Every day, you receive checks drawn on other banks.

Instead of sending a clerk to each of the other banks individually to settle up...

Ten London banks came up with a genius solution in 1773:

They all met at a single office in Lombard Street every day.

Each bank brought a clerk with a ledger.

They’d lay out all the checks:

“I have a check from Barclay’s customer for £100.”
“I have a check from your customer for £75.”
“Net: You owe me £25.”

They’d calculate all the net positions.

Then—and this is the genius part—only the net moved. Not every individual transaction.

Instead of exchanging 500 checks and moving money 500 times...

They’d calculate: “At the end of the day, Barclay’s owes Lloyds £1,000 net.”

Then Barclay’s would send £1,000 to Lloyds.

Done.

This is called CLEARING.

And it only works because:

1. Everyone shows up (no hiding)

2. Everyone brings their real ledger (no lying—everyone can see everyone else’s numbers)

3. Everyone trusts the guy running the meeting (neutral party)

The London Bankers’ Clearing House became the model for clearing houses worldwide.

Fast forward 250 years.

Same problem. Same solution.

Just digital.

How Modern Clearing Houses Work: Enter NPCI

Fast forward to 2025.

India has a clearing house.

It’s called NPCI (National Payments Corporation of India).

Every single UPI transaction in India goes through NPCI.

Every IMPS transfer. Every NEFT transaction. Every RuPay card swipe.

Approximately 20 billion transactions per month.

Let me show you how it works.

The Journey of ₹100: Step-by-Step

Step 1: You Send ₹100 to Your Friend

You open Google Pay. Scan their QR code. Hit “Pay.”

But you’re not sending money directly to them.

You’re sending a message to NPCI.

You → HDFC Bank → NPCI → ICICI Bank → Friend

Step 2: NPCI Receives the Message

HDFC tells NPCI:

“Our customer (Account #12345) wants to send ₹100 to ICICI customer (Account #67890).”

NPCI logs this in its database:

Transaction ID: #47382991
From: HDFC Bank, Customer A
To: ICICI Bank, Customer B
Amount: ₹100
Timestamp: 2:34:17.392 PM
Status: PENDING

Step 3: NPCI Tells ICICI

NPCI sends a message to ICICI:

“Hey ICICI, you’re receiving ₹100 from HDFC for your customer B (Account #67890).”

ICICI checks: Does Account #67890 exist? Yes.

ICICI updates their database:

Account #67890
Old Balance: ₹500
New Balance: ₹600

Step 4: ICICI Confirms

ICICI sends a message back to NPCI:

“Confirmed. Customer B has been credited ₹100.”

NPCI updates the transaction:

Transaction ID: #47382991
Status: COMPLETE ✓

Step 5: You Get Confirmation

NPCI tells HDFC: “Transaction successful.”

HDFC tells you: “Payment Successful ✓”

Your friend’s phone buzzes: “You received ₹100”

Done. Two seconds. Across four organizations.

But wait.

There’s a critical detail I haven’t mentioned yet.

The Big Secret: Nothing Actually Moved Yet

Here’s what just happened:

HDFC decreased their customer’s balance: ₹1,000 → ₹900

ICICI increased their customer’s balance: ₹500 → ₹600

But no actual money moved between HDFC and ICICI.

Only ledgers updated.

HDFC now owes ICICI ₹100.

This is the distinction that breaks most people’s brains:

CLEARING ≠ SETTLEMENT

Let me explain.

Clearing vs. Settlement: The Most Important Distinction

CLEARING = Updating the ledgers (happened in 2 seconds)

SETTLEMENT = Actually moving money between banks (happens later)

Here’s the genius part:

NPCI doesn’t settle every transaction individually.

It batches them.

Over the course of one day, thousands of transactions happen between HDFC and ICICI:

HDFC customers → ICICI customers:

• 10,000 transactions

• Total: ₹1,00,00,000 sent

ICICI customers → HDFC customers:

• 8,000 transactions

• Total: ₹80,00,000 sent

Net: HDFC owes ICICI ₹20,00,000

At the end of the day (or for UPI, in batches throughout the day), NPCI calculates the net position.

NPCI tells HDFC: “You owe ICICI ₹20,00,000 net. Transfer it through your settlement account at RBI.”

HDFC’s account at RBI is debited: -₹20,00,000

ICICI’s account at RBI is credited: +₹20,00,000

Done.

This is called NETTING.

Instead of moving money 18,000 times, you move it once.

This is what makes the whole system scalable.

Real-Time vs. Batch: The Evolution

Old System (NEFT, launched 2005):

Batch processing.

Your transaction sits in a queue.

Every 30 minutes or 1 hour, NPCI processes all pending transactions at once.

Settlement happens at end of day.

Result: Your money takes 2+ hours to show up.

New System (UPI, launched 2016):

Real-time clearing.

Your transaction is processed immediately.

Settlement happens in batches throughout the day (typically every 30 minutes to 2 hours).

Result: You see “Payment Successful” in 2 seconds.

But here’s the nuance:

The clearing happened in real-time (your friend sees the money immediately).

The settlement happens soon after (banks settle their net positions in batches).

For you, the user, it feels instant.

For the banks, there’s a small lag between “we updated the ledgers” and “we actually moved the money.”

This is why UPI is considered “real-time” even though technical settlement happens in batches.

The Paranoia That Makes It Work

Okay, but wait.

We just moved the trust problem.

Now instead of trusting 99 other banks...

Everyone trusts ONE organization: NPCI.

What if NPCI makes a mistake?

What if NPCI gets hacked?

What if NPCI’s database crashes and we lose track of who owes what?

This is why clearing houses are extremely paranoid.

Let me show you the layers of paranoia.

Paranoia Layer 1: Redundancy

NPCI doesn’t have one server.

It has multiple data centers.

Primary and backup systems running simultaneously.

If one server crashes, the backup takes over.

Instantly.

You never notice.

The system is designed to have no single point of failure.

(We’ll see in Week 3 why this sometimes still fails.)

Paranoia Layer 2: Reconciliation

Every night, NPCI does something called reconciliation.

It checks:

“Did HDFC’s records match NPCI’s records?”

“Did ICICI’s records match NPCI’s records?”

“Did the money actually move from HDFC’s RBI account to ICICI’s RBI account?”

If there’s a mismatch—even ₹1—alarms go off.

Someone investigates.

They hunt down the discrepancy.

Usually they find it (a duplicate entry, a delayed message, a typo).

Sometimes it takes days to resolve.

This is why payment companies have entire teams dedicated to reconciliation.

It’s not glamorous. But it’s critical.

Paranoia Layer 3: Cryptographic Signatures

Every message between banks and NPCI is cryptographically signed.

HDFC doesn’t just send a text message saying “We sent ₹100.”

They send a message with a digital signature that proves:

1. The message came from HDFC (authentication)

2. The message wasn’t tampered with (integrity)

3. HDFC can’t later deny sending it (non-repudiation)

If someone tries to fake a message or modify it in transit, the signature won’t match.

The message gets rejected.

Paranoia Layer 4: Dispute Resolution

What if something goes wrong?

You sent ₹100.

Your bank says it left.

Your friend’s bank says it never arrived.

Who’s lying?

NPCI has the receipts.

Every transaction is logged.

Timestamped down to the millisecond.

Cryptographically signed.

If there’s a dispute, NPCI shows the evidence:

“Here’s the message HDFC sent at 2:34:17.392 PM.”

“Here’s ICICI’s confirmation at 2:34:19.108 PM.”

Case closed.

This is why you can’t just call your bank and say “I sent money but they didn’t receive it” and expect them to believe you without checking the NPCI logs.

The logs are the source of truth.

Paranoia Layer 5: Regulation

NPCI isn’t just a private company doing whatever it wants.

It’s regulated by RBI (Reserve Bank of India).

RBI audits NPCI constantly.

Checks the code.

Checks the security.

Checks the financial stability.

Tests disaster recovery.

Because if NPCI fails, the entire Indian payment system fails.

The paranoia is justified.

What Could Go Wrong (And Sometimes Does)

Let’s talk about the nightmare scenarios.

These aren’t hypothetical. These actually happen.

Scenario 1: The Bank Runs Out of Settlement Money

HDFC has been sending more money out than receiving all day.

Their net position with NPCI goes deeply negative.

NPCI: “Hey HDFC, you owe us ₹500 crore in settlement. Pay up through your RBI account.”

HDFC: “Uh... we’re a bit short right now. Can we settle tomorrow?”

NPCI: “No. We’re blocking your outgoing transactions until you settle.”

Suddenly, every HDFC customer trying to send money via UPI gets:

“Transaction failed. Please try again later.”

This actually happens.

Banks have to maintain minimum balances in their settlement accounts.

If they run low, their transactions get queued or blocked.

This is why sometimes UPI randomly fails with “Bank server issue.”

It’s not always a server issue. Sometimes it’s a liquidity issue.

The bank is temporarily out of settlement funds.

Scenario 2: NPCI Goes Down

NPCI’s servers crash. For even a few minutes. Every UPI transaction in India stops. Millions of people suddenly can’t pay. Street vendors panic. Twitter explodes: “UPI DOWN!”

This has happened. In March and April 2025, NPCI experienced multiple partial technical outages. UPI faced intermittent transaction declines, IMPS infrastructure was impacted, and for those brief windows, the digital economy stuttered. This is the fragility of centralized systems. One chokepoint. Massive impact.

Scenario 3: The Reconciliation Nightmare

End of day reconciliation runs.

NPCI’s log says: 1,000,000 transactions processed today.

Banks’ combined logs say: 999,999 transactions.

One transaction is missing.

Where did it go?

Did someone get charged but not credited?

Did someone get credited but not charged?

Is there ₹100 floating in the void?

This triggers an investigation.

Teams hunt through logs.

Check timestamps.

Cross-reference transaction IDs.

Usually, they find it within hours (it was a delayed confirmation message, or a duplicate entry that was already corrected).

Sometimes it takes days.

Rarely, very rarely, they don’t find it.

The money is temporarily “unaccounted for” until the discrepancy is resolved.

(Though to be clear: these cases are extremely rare and almost always resolved. The system is very good at this.)

Think About What We’ve Built

Every time you tap “Pay,” here’s what happens behind the scenes:

1. Your payment app sends a message to your bank

2. Your bank validates and forwards to NPCI

3. NPCI logs the transaction

4. NPCI routes the message to the receiver’s bank

5. Receiver’s bank validates and updates their customer’s ledger

6. Receiver’s bank confirms back to NPCI

7. NPCI marks transaction complete

8. NPCI confirms to your bank

9. Your bank confirms to you

9 steps.

Across 4 organizations.

In 2 seconds.

And this happens approximately 690 Million times per day in India alone.

Without a centralized clearing house like NPCI, none of this works.

Banks would still be calling each other.

Transactions would take hours.

Disputes would be unsolvable.

Trust wouldn’t scale.

We take this for granted.

But it’s a miracle of coordination.

The Takeaway

THE LESSON:

Trust doesn’t scale.

You can’t have 100 entities trusting each other directly.

You need a middleman everyone trusts.

In payments, that’s the Clearing House.

In India, that’s NPCI.

NPCI is one of the most important organizations you’ve probably never heard of.

It processes more transactions than Visa and Mastercard combined (in terms of transaction count, though not value).

And it does it in real-time.

For free. (Zero MDR, remember from last week?)

This is infrastructure at scale.

But this creates a new problem.

A scary problem.

The Single Point of Failure

If NPCI is so important... And if the entire payment system depends on it... What happens when NPCI goes down? What happens when the servers crash? What happens when there’s a cyberattack?

As we saw with the outages in early 2025, the entire country realizes we’ve built our payment system on a single point of failure.

So the obvious questions: How did this happen? Why don’t we have better redundancy? And most importantly: How do we prevent this from happening again?

That’s another week.

2 seconds later: “Payment Successful ✓”

You didn’t think about it. It just worked.

But in those 2 seconds, 7 different computer systems woke up, 12 companies got involved, and your money somehow traveled from your bank to the merchant’s bank without anything actually moving.

I have a confession to make.

I work in payments. I spend my entire day building the systems that make this happen. And yet, until recently, if you had asked me “What actually happens when I tap my phone to buy coffee?”... I would have mumbled something about “electrons” and “the cloud” and changed the subject.

I didn’t actually understand the fundamental thing I was working with: Money.

So I did what any rational person would do when they realize they don’t understand their job.

I spent 6 months going down a rabbit hole.

I read central bank reports. I interviewed payment engineers. I traced transactions through databases. I learned about limestone discs in the Pacific Ocean and SQL queries in Mumbai.

And I realized something wild:

Money is not what you think it is.

This is Week 1 of How Money Moves — a year-long journey into the invisible plumbing that runs the global financial system.

We’re going to start by breaking your brain a little bit.

Ready? Let’s go.

The Intuition Trap: The “Thing” Theory

Most of us grow up thinking of money as a Token.

A token is a physical object. If I have a gold coin, and I give it to you, I have one less coin, and you have one more. The value is inside the object.

This makes sense. It’s intuitive. It’s how we trade Pokemon cards.

But if you try to build a modern economy on “Tokens,” you run into problems immediately.

Let me show you what I mean.

The Great Dematerialization

Let’s start with the oldest form of money: Barter.

Imagine you’re a chicken farmer in ancient Mesopotamia. You need shoes.

You find the shoemaker. He doesn’t want chickens. He wants wheat.

Fine. You find the wheat farmer. She doesn’t want shoes. She wants pottery.

You find the potter. He doesn’t want wheat. He wants... goat milk.

You’d have to find a chain of people willing to trade until someone eventually wants your damn chicken.

Economists call this the “Double Coincidence of Wants.” I call it trading hell.

So humans tried to find something everyone would accept.

Cows: Everyone needs food, right? But cows die. And you can’t give half a cow for a haircut. (Well, you could, but it’s messy.)

Gold: Doesn’t die. Doesn’t rot. Everyone wants it. Perfect! Except... a house-worth of gold weighs literally a ton. Moving money meant moving metal. Your net worth required a cart and a donkey.

Paper: Someone had a genius idea: Just leave the gold in a vault. Trade pieces of paper that represent the gold. Much lighter. Much more portable.

**[Visual: Timeline showing:

• 3000 BC: Stick figure struggling under weight of giant cow

• 1000 BC: Stick figure dragging heavy gold bars

• 1900 AD: Stick figure with paper in wallet, smiling

• 2025 AD: Stick figure with smartphone, looking relaxed

Caption: “The 5,000-year quest to make money lighter”]**

This worked great for a while.

But then we did something wild.

We realized we didn’t even need the paper.

We didn’t even need the gold.

We realized that money was never the object at all.

The Village Notebook

Imagine a small village where everyone trusts each other perfectly.

I give you a banana. You don’t have anything to give me right now. So, we just... remember it.

“Aklank gave Priya one banana.”

If our memory was perfect, we wouldn’t need coins or paper at all. We would just need a giant notebook in the town square.

VILLAGE LEDGER - Page 47

Drishty:    -1 banana
Aklank:   +1 banana

When you eventually do some work for me, we just update the notebook.

Drishty:    0 bananas
Aklank:   0 bananas

In this village, money is not a “thing” you carry.

Money is Information.

Money is a Ledger — a record of who owes what to whom.

This is not a metaphor. This is literally how modern banking works.

Your bank account is just a row in a giant ledger. When you “send” money, no physical thing moves. Your bank just updates two numbers in a database.

But I know what you’re thinking: “That’s a nice theory. But real money isn’t like that. Real money is... real. I can touch it. I can see it.”

Can you?

Let me tell you about the Island of Yap.

The Island of Stone Money

This is a true story.

On the Island of Yap in the Pacific, the locals used giant limestone discs called Rai stones as money.

Some of these stones were 12 feet wide and weighed 4,000 kg.

Obviously, you couldn’t put that in your wallet. You couldn’t even move it.

So the stones just... stayed in the forest.

If I wanted to buy your house, I’d point to a stone in the forest and say, “That one is yours now.”

The stone didn’t physically move. But everyone in the village updated their mental ledger. The ownership changed.

Okay, that’s interesting. But here is the really crazy part.

One time, a crew was transporting a giant stone across the ocean on a raft. A storm hit. Waves crashed. The raft was sinking.

To save their lives, they cut the ropes, and the stone sank to the bottom of the Pacific Ocean.

Gone. Forever. Unreachable.

Did the owner lose his money?

No.

The crew went back and told the village elders what happened. The elders convened. They discussed. And they decided:

“The stone was there. It is still there. It just happens to be underwater.”

So the family who owned the stone continued to be wealthy.

They bought things. They traded. They used the value of the stone.

A stone that nobody could see.

A stone that nobody could touch.

A stone that was sitting at the bottom of the ocean covered in barnacles.

That family was wealthy because of a Collective Delusion.

The stone couldn’t be seen.

It couldn’t be touched.

It couldn’t be verified.

But everyone agreed it was there. And because everyone agreed, it had value.

This is not primitive. This is exactly how your bank account works.

The only difference between the underwater stone and your ₹50,000 is the technology we use to track the delusion.

Yap Island used oral tradition — village elders remembering who owned what.

You use a SQL database in Mumbai.

Same concept. Better infrastructure.

You Are Living on Yap Island

If you think that’s silly, do this right now:

Open your banking app.

You see a number. Maybe ₹50,000. Maybe ₹5 lakh.

Now ask yourself: Where is that money?

Is there a vault somewhere with your name on it? A locker with ₹50,000 in cash sitting inside?

No.

That number is a row in a SQL database on a server somewhere in Mumbai.

sql

SELECT balance FROM accounts WHERE user_id = 'you';
-- Returns: 50000

That’s it.

That’s your wealth.

A number in a spreadsheet.

Your money is exactly like the underwater stone.

It doesn’t physically exist. It exists because a ledger says it does. And you trust the ledger.

When you “withdraw cash” from an ATM, you’re not taking your money out. There’s no box with your name on it. The ATM just dispenses random bills and updates the database to reflect that you now have less digital money.

The cash isn’t yours. The cash is just paper.

What’s “yours” is the number in the database.

The Coffee Transaction (Revisited)

Let’s go back to that coffee you bought this morning.

You tapped your phone. ₹100 moved from your account to the coffee shop’s account.

Here’s what actually happened:

Step 1: Your bank (let’s say HDFC) opens its database and runs:

sql

UPDATE accounts 
SET balance = balance - 100 
WHERE user_id = 'you';

Your balance: 50,000 → 49,900

Step 2: HDFC sends a message to the coffee shop’s bank (let’s say ICICI):

"Hey ICICI, we just debited our customer ₹100. 
Please credit Cafe Coffee Day."

Step 3: ICICI receives the message and runs:

sql

UPDATE accounts 
SET balance = balance + 100 
WHERE user_id = 'cafe_coffee_day';

Coffee shop balance: 2,000 → 2,100

Nothing physically moved.

No atoms shifted.

No physical rupee traveled from Mumbai to Bangalore.

No electrons “carried” value.

Only information changed.

The ledgers updated.

Done.

Think About How Weird This Is

You have ₹50,000 in your account.

That money doesn’t exist in any physical form. It’s just a number in HDFC’s database.

The coffee shop has ₹2,000 in their account. Also just a number in ICICI’s database.

You tap your phone.

HDFC changes your number: 50,000 → 49,900

ICICI changes their number: 2,000 → 2,100

And we call this “moving money.”

But nothing moved!

We just updated two spreadsheets!

It’s like we’re all playing a massive multiplayer game where the points only matter because everyone agrees they matter.

Which is... exactly what money has always been.

The Yap Islanders had a stone at the bottom of the ocean.

You have a number in a database in Mumbai.

Same energy.

The Takeaway

This is the fundamental mental model for this entire series:

Money is not a Token. Money is a Ledger.

• Cash is a physical token that proves you have value.

• Digital payment is a message that updates the ledger.

This explains why digital payments can be so fast (it’s just data!) but also why they can be so fragile (what if the database crashes? What if the message gets lost?).

Once you understand this, everything else about payments makes sense.

UPI, credit cards, SWIFT transfers, cryptocurrency — they’re all just different ways of updating the ledger.

But this creates a massive, terrifying problem.

The Problem Nobody Thinks About

If my money is just a row in HDFC’s spreadsheet, and your money is a row in ICICI’s spreadsheet...

How do the spreadsheets talk to each other?

Think about it.

If HDFC just sends a message saying “Hey ICICI, I owe you 100 rupees,” why should ICICI believe them?

What if HDFC is lying?

What if HDFC doesn’t actually have the money?

What if the message gets lost in transit?

What if someone intercepts the message and changes 100 to 100,000?

What if HDFC sends the same message twice by accident, and now the coffee shop gets paid double?

How do thousands of banks — who don’t trust each other, who are competitors, who have different systems — constantly update each other’s ledgers without descending into chaos?

This is called The Clearing House Problem.

And it is way harder than it sounds.

Next week, we’re going to see how humans solved it.

(Spoiler: It involves a lot of paranoia, some very careful accounting, and one organization in India that somehow processes 14 billion transactions per month without everything exploding.)

The Invisible Underwater Rock What Are Payments

2.72MB ∙ PDF file

Download

Download