India gets a lot of spam. If you have an Indian phone number, you already know this. OTPs from apps you barely remember installing, promotional SMS from jewellery stores in states you've never visited, "Dear Customer your KYC is pending" messages arriving at 11pm. TRAI's new SMS traceability rules, built on blockchain-based distributed ledger technology, are supposed to fix all of this. Whether they actually will is a more complicated question.
What TRAI's SMS traceability rules actually say
The rules fall under what TRAI calls the Telecom Commercial Communications Customer Preference (TCCCPR) framework, now in its third amendment for 2026. The underlying technology is a distributed ledger, basically a blockchain, that every major telecom operator in India has to plug into.
Here's how it works in plain terms. Every business that wants to send an SMS to an Indian mobile number has to register three things on the DLT (Distributed Ledger Technology) platform:
- Their company name as a "principal entity"
- The specific SMS header, meaning the sender ID that appears instead of a phone number, like HDFCBK or SBIINB
- The exact message template, word for word, including which parts are variable, like OTP numbers or transaction amounts
When your bank sends you an OTP, the message travels from the bank's system to a telecom service provider (a bulk SMS company), then to your operator (Jio, Airtel, Vi, or BSNL), and finally to your phone. At every handoff, the blockchain checks whether the header and template match what's registered. If they don't match, if someone has forged the sender ID or tweaked the message even slightly, the SMS gets blocked before it reaches you. That's the theory, anyway.
The deadline that kept getting extended
TRAI first introduced the DLT framework back in 2018, but actual enforcement has been a slow burn. The 2026 third amendment tightened things considerably, introducing stricter message scrubbing rules and a new direction requiring telcos to share customer KYC data across networks for AI-based spam detection, as reported by MediaNama.
TRAI extended the compliance deadline multiple times for telecom firms. And honestly, that tells you something about how genuinely complex this is to implement at scale. Small bulk SMS providers had real integration headaches getting their systems talking to the DLT platform properly. (I'm not sure exactly why the larger telcos struggled too, but they did.)
The OTP delay controversy and TRAI's official response
This is where things got messy. When stricter DLT scrubbing rules came into effect, users across India started reporting OTP delays, sometimes 5 to 10 minutes, occasionally longer. Imagine waiting that long for a PhonePe or HDFC Bank OTP while a payment is sitting there, timing out.
TRAI pushed back hard. The regulator officially denied that OTP delays were caused by the new traceability rules, as documented by BOOM Fact Check. Their argument: the DLT verification process happens in milliseconds, so the technology itself isn't the bottleneck. The problem, according to TRAI, was businesses that hadn't properly registered their message templates. Their SMS was being held for manual review or rejected and retried, causing the delay.
Honestly, that's probably half-true. The DLT check is genuinely fast when everything is correctly registered. But the transition period, when thousands of businesses were scrambling to update their registrations, did create real-world delays for end users. The compliance lag was real. The underlying technology wasn't directly to blame, but users paid for it anyway.
What this means if you run a business in India
If you send transactional or promotional SMS to customers, you've likely been through the DLT registration process already. The 2026 amendments add new requirements that catch a surprising number of businesses off-guard.
Message templates now have to pass stricter scrubbing. Variable portions of the message, such as the OTP number, customer name, or transaction amount, must be clearly marked in a specific format. If your registered template says "Your OTP is {#var#}" but your actual system sends "Your one-time password is {#var#}", that's technically a mismatch. Blocked. Just like that.
A few things to check right now if you're sending any kind of commercial SMS:
- Log into your DLT portal (Jio, Airtel, Tata, and Vodafone all run their own DLT interfaces) and verify your entity registration is active and approved
- Cross-check every active template against what your SMS gateway is actually sending. Even small wording differences matter under the new scrubbing rules
- If you use a third-party bulk SMS provider like MSG91, Kaleyra, or Exotel, confirm they've updated their integration to the 2026 format
- Register backup headers and templates, since your primary can get flagged during a review cycle
- Set a quarterly reminder to audit registrations. This isn't a one-time setup task
The businesses hurting most right now are mid-sized e-commerce and logistics companies that set up their SMS workflows years ago and never revisited them. The 2026 amendments are not forgiving about legacy template formats. In my experience, these companies always assume someone else already handled it.
How blockchain actually fits into this
The word "blockchain" is doing a lot of heavy lifting in TRAI's official communications. What they actually run is a permissioned distributed ledger, a database replicated across multiple telecom operators at the same time, so no single party can alter the records without others detecting it. It's not Bitcoin. And it doesn't need to be.
This matters for one specific reason: SMS sender ID spoofing was trivially easy before DLT. A fraudster could send you an SMS appearing to come from "HDFCBK" and you'd have no way to verify it. The DLT registry makes this significantly harder because forging a sender ID now means manipulating records across all the telecoms' synchronized copies of the ledger at once.
Is it foolproof? No. Scammers adapted. They started registering their own entities and headers with names similar enough to real brands to cause confusion (annoying, I know). TRAI reported this as an ongoing challenge and issued separate guidance on header name screening in 2025. The cat-and-mouse continues, as it always does.
The KYC data sharing directive and what it means for privacy
One part of the 2026 rules that hasn't gotten enough attention: TRAI directed telcos to share customer KYC data across networks to power AI-based spam detection. Your telecom already holds your name, address, and Aadhaar-linked verification details. Under this directive, that data can be used, anonymised and aggregated in theory, to train behavioural models that identify spam patterns across the network.
This sits in interesting tension with the Digital Personal Data Protection Act. The DPDP Act requires informed consent for personal data processing, but has carve-outs for national security and legitimate government functions. Whether telecom KYC data sharing for spam detection falls cleanly under those carve-outs hasn't been clearly resolved. I couldn't find a definitive official statement on this question.
TRAI and RBI were also running a Digital Consent Platform pilot together. Reporting from MediaNama indicates it wrapped up trials in early 2026. The concept is a central dashboard where users can manage which commercial entities are allowed to contact them. So instead of blocking at the network level, you'd get actual control over who can message you and about what. That's a more honest solution, if you ask me.
What changes for ordinary users
If you're not running a business, you mostly notice this in two ways: fewer spam SMS in theory, and the occasional delayed OTP during transition periods.
The spam reduction is real. DoT Minister Scindia recently highlighted TRAI and telecom operator actions in cutting down unsolicited commercial SMS volume. BSNL also rolled out dedicated anti-smishing protection for mobile users across India in 2026, flagging sketchy links in messages before they reach your inbox.
But fewer isn't zero. SMS scams haven't disappeared; they've shifted. Fraudsters moved quickly to WhatsApp, Telegram, and iMessage when SMS became harder to abuse. TRAI has proposed removing safe harbour protection for apps that filter commercial calls, hinting at ambitions to extend some version of this framework to OTT messaging platforms. That's going to be a much larger regulatory fight.
TRAI's DLT framework has meaningfully reduced forged-sender SMS fraud in India, but the absence of any equivalent traceability system for OTT messaging apps means scammers have simply shifted channels rather than stopped operating.
If you receive an SMS asking you to click a link to verify your KYC or update your Aadhaar, that's almost certainly a scam regardless of what sender name appears. The DLT system reduces this but hasn't eliminated it. Check our SMS phishing guide for what to look for, and report any fraud at cybercrime.gov.in or on the 1930 helpline.
What to track in the months ahead
There are a few developments worth following. The Digital Consent Platform going from pilot to full production. Any regulatory moves to extend traceability-style rules to WhatsApp and Telegram. And how the DPDP Act's consent requirements end up interacting with the KYC-sharing directive. The numbers here are a bit fuzzy on timelines, but all three are moving.
For businesses: treat your DLT template registry the way you treat your GST filings. It needs periodic review, not a set-and-forget approach. Enforcement is genuinely tightening, and the grace period most businesses quietly relied on is over.
For everyone else: the system is meaningfully better than it was in 2020. Use your telecom's spam reporting features and the Do Not Disturb registry at 1909 to feed the detection systems. The more data these AI models collect, the more accurate the filtering gets. And if you want a broader look at how India's digital identity and consent frameworks are evolving, our tech news section covers regulatory developments as they happen.
