Vinny Arora, a finance professor at Delhi University, got two SMS messages from what looked like his own bank. Same wording. Same formatting. Same branding down to the logo.
He almost didn’t bother checking twice until he did. One of them wasn’t from his bank at all. The only difference was a single letter, quietly swapped from uppercase to lowercase.
He posted the discovery on Instagram last weekend, along with tips on how to catch it. The video went viral for good reason.
But buried in the comments under his own post was a more uncomfortable question than the video answered: if telling a real bank text from a fake one takes this much scrutiny, is the problem really the customer’s vigilance or the system that let two nearly identical sender names exist in the first place?
Here’s what most coverage of this story will skip. In India, every business that sends bulk SMS banks included has to register something called a “header,” a six-character sender ID, through TRAI’s DLT (Distributed Ledger Technology) platform.
It’s meant to stop random spam numbers from impersonating trusted brands. And it mostly works. You can look up any header on TRAI’s own portal, smsheader.trai.gov.in, and see who it’s registered to in under two minutes, no login required. There’s also a quicker check: text the sender’s header to 1909, and TRAI will reply within seconds telling you whether it’s registered at all.
But there’s a quiet catch in how that registration works: headers are treated as case-sensitive. Under TRAI’s own rules, “SBIBNK” and “sbibnk” aren’t the same sender ID at all; they’re two entirely separate entities, each technically eligible for its own registration.
To the system, that’s just data hygiene. To a scammer, it’s a door left slightly ajar, not one that swings open easily, since getting a header registered still means going through a telecom operator’s DLT process with business verification and documentation.
But determined fraudsters have been documented working around exactly this, setting up shell entities to obtain a legitimate-looking header in the first place. Once that header exists, it clears every formal check a customer might think to run except the one where they squint hard enough to spot a single lowercase letter sitting where a capital should be.
This is the part the “3 tips” version of this story quietly steps around. Arora’s advice text the sender header to 1909, cross-check it on TRAI’s portal, examine the sender name letter by letter is genuinely useful, and worth doing.
But notice what all three tips have in common: they ask the customer to do the verification work that the registration system was supposed to have already done.
The comments under his own post make that tension impossible to ignore. One person pointed out they’d rather just check their bank’s app directly than decode a sender header. Another called it “complex ways of doing simple things.”
They weren’t wrong. For a system explicitly built to let people trust a sender name at a glance, asking that same person to run a character-by-character audit every time an SMS arrives isn’t really a fix, it’s an admission that the trust layer has a hole in it.
None of this is to say TRAI’s framework is useless. Mandatory header registration has genuinely reduced the flood of random, unregistered spam numbers pretending to be banks. Unregistered senders get blocked by telecom operators before they even reach your phone.
The 1909 lookup and the TRAI portal are real tools, and they do work when someone thinks to use them. The gap isn’t that verification is impossible. It’s that verification is optional, manual, and invisible unless a customer already suspects something is wrong by which point, for many people, the “click here” link has already been tapped.
That’s the deeper story sitting underneath the viral video: scammers didn’t have to break the DLT system to pull this off. They found the one seam in its case-sensitivity treated as a difference substantial enough to warrant separate registration, but subtle enough that almost no human eye catches it on a phone screen at a glance.
They built around it, using registered-but-fraudulent entities to slip a near-identical header past the very system meant to prevent exactly this. It’s a small technical detail with an outsized real-world cost.
That makes it the kind of thing a regulator, not a customer, is actually positioned to close. A simple rule requiring header registrations to check for visual near-duplicates, not just exact string matches, would shut this specific loophole without asking a single additional thing of the people receiving the messages.
Until that happens, though, the advice in the video isn’t wrong, it’s just incomplete. Check the sender header. Use the TRAI portal. Look for the “click here” link that a real bank would never send.
But it’s worth asking, the next time a “3 tips to stay safe” post goes viral, why the tips are always aimed at the person opening the message, and never at the system that lets two banks’ worth of trust sit one character apart.
Subscribe Deshwale on YouTube
