Writing Essay

India keeps squeezing the on-ramp. It's the wrong place to squeeze.

The Enforcement Directorate's raids on five Bengaluru crypto payment firms target the one point where rupees become crypto. I think that's a mistake, and I learned what a closed on-ramp does to users the hard way.

On June 17, India's Enforcement Directorate searched six premises in Bengaluru linked to five crypto payment companies. According to the ED's own press release, they were Transak, Carret, Xpat (formerly Remit2any), Onramp.money and Onmeta. The agency says they moved money across borders using crypto without authorization from the Reserve Bank of India, and it puts the alleged FEMA violations at more than ₹2,500 crore. It also froze bank accounts holding about ₹6 crore.

The pattern the ED describes is simple. A customer deposits rupees into a company account. The company buys stablecoins, mostly USDT according to the reporting, and those get sold on an exchange or over the counter, with the proceeds paid out to someone on the other side of the border. Cryptopolitan, the Hindu and the Economic Times report the same details, including a separate allegation that Transak moved operating profits to a related U.S. company as crypto.

These are allegations, and I'm not going to argue the specific cases. If someone was running remittances to dodge the reporting rules, that's a real problem. My issue is with the approach. India keeps going after the on-ramp, and I think that's the wrong place to squeeze.

Why I think this is the wrong move

The first reason is that there's no clear way to do this legally. India taxes crypto heavily. It has a flat 30% tax on gains and a 1% TDS on transfers, and since March 2023 crypto service providers have had to register with FIU-IND under the anti-money-laundering law. But there's still no licence that lets an on-ramp company say, here is the authorization, here is how we report a cross-border transfer, and here is the purpose code we use. When the rules only tell you what you can't do, enforcement ends up being the regulation.

The second reason is that the on-ramp is the most visible part of the system. These are companies with offices, bank accounts and identity checks. That's exactly why they're easy to raid. It's also why they're the best place to watch money move. If the businesses that do KYC and keep records get raided, the demand doesn't disappear. It moves to peer-to-peer trades and offshore apps, where nobody is checking anything.

The third reason is the people who never show up in the press release. Most users of an on-ramp are just trying to fund a wallet, buy a stablecoin or pay for something. When a provider freezes or shuts its rupee rail, those people can't get money in, and nobody explains why. They didn't break any rule, and they still lose access.

And the fourth reason is what it signals to builders. Bengaluru has a lot of crypto infrastructure talent. Raids without a licensing path tell those teams to build somewhere else, or to build for users somewhere else. I don't think that's the outcome India actually wants.

What a closed on-ramp did to us

I have a personal reason to care about this. At Lume the demand was real, but we concentrated users in India and depended on a narrow on-ramp path. When that path shut down, users couldn't fund their accounts.

That was my mistake as much as anyone's. I should have treated funding-path resilience as a core product requirement much earlier. We had growth, we had people who wanted the product, and none of it mattered on the day the money couldn't get in.

Diagram titled One narrow on-ramp versus a path that survives a shutdown. Narrow, what I built: users mostly in India, then bank transfer in rupees, then one on-ramp, marked shut down, so the funded account is never reached; one path closes and nobody can deposit. Resilient, what I would build now: users across markets, then on-ramp A, on-ramp B, or an exchange or wallet transfer, then a live check of whether the path is up and the transfer finished, then a funded account.
A funding path is only as strong as its narrowest point.

That experience changed how I look at integrations. A provider's coverage map is useful only if the path stays available and users can actually complete the transfer. "Supports India" on a slide doesn't tell you what happens when a bank pulls an account or an agency freezes one.

So now I ask different questions. How many independent ways can a user fund, and do any of them share the same bank partner? What does the product do when one path goes down, and does the user see that clearly or just a spinning loader? Can we tell, in real time, whether transfers are finishing, not only whether they're being started? And if a whole country's rails go quiet, is the business still standing?

What I'd want instead

I'd want India to give on-ramps a way to be legal. That would mean a licence with clear cross-border rules, purpose codes and reporting that a crypto payment company can actually follow. Then the companies that follow it can be separated from the ones that don't, and the ones that don't can be prosecuted with a lot less collateral damage.

Until then, I'd tell anyone building for Indian users to assume the on-ramp can disappear on any given Wednesday. Design for it. I didn't, and I watched people who wanted to use the product stand at the door with no way in.

More in the writing hub.