Why Your SMS Vendor Can't Own DLT Template Compliance

When TRAI mandates variable pre-tagging on every SMS template, the fix sits upstream of your SMS vendor; in the layer that governs templates before they reach the communication channel.

TLDR

• TRAI's November 2025 Direction requires every variable field in SMS content templates to be pre-tagged with one of six approved types (#numeric#, #alphanumeric#, #url#, #urlott#, #cbn#, #email#). Generic placeholders are no longer valid.

• Your CPaaS vendor delivers messages but does not own or manage your DLT template registry. They will not audit, re-tag, or re-register your templates for you.

• After the 60-day grace period, any message with a non-compliant variable field is rejected outright by the telco. For OTPs and transaction alerts, that means failed authentication and missed customer notifications.

• Banks with 200–500 templates across multiple DLT operators face 900+ individual re-registration actions, each with a 24–48 hour approval cycle.

Fyno's Template Builder enforces variable type declaration at creation, syncs across all DLT operators from a single editor, and flags non-compliant templates without manual portal audits.

Will your SMS vendor handle variable pre-tagging for you?

No. And this is the most important thing to understand before you assign ownership of this compliance task internally.

Your CPaaS provider, whether that is Sinch, Route Mobile, Karix, Gupshup, or any other aggregator, owns the pipe that carries your messages. They do not own your DLT template registry. They cannot log into your DLT account and re-tag your variable fields.

When Airtel's enforcement notice went out to Principal Entities about variable pre-tagging, banks called their SMS vendors. Most vendors responded with a version of: "You need to update your templates on the DLT portal." That is the correct answer. But it is also an unhelpful one.

Why does your vendor have no incentive here?

CPaaS vendors are paid on message volume. A message that fails variable tag validation is a message that was never submitted to them. Their delivery SLA starts after you submit the request. Template compliance upstream of that submission is outside their scope and, frankly, outside their commercial interest.

The banks and NBFCs most exposed right now are those running template management through their aggregator portal or directly through DLT operator consoles. That approach can hold together for a one-time cleanup. It does not hold together as an operating model. New products ship new templates every month, the same customer journey runs across SMS, WhatsApp, and email, and the person who knows which variable was tagged {#url#} versus {#urlott#} eventually moves teams. Without a centralised layer that enforces variable types, whitelisted URLs, and approvals at the point of template creation, every future template is a new compliance exposure, not a managed one.

What does TRAI's Direction require you to do?

The Direction, issued under TCCCPR 2018 and dated November 18, 2025, requires that every variable field in an SMS content template be pre-tagged with one of six approved types. Generic placeholders are no longer valid for new templates registered after the 10-day window from the Direction date.

The enforcement timeline

New templates: must comply within 10 days of the Direction date.

Existing templates: 60-day window from when Access Providers start scrubbing. During this window, non-compliant messages are still delivered, but fault logs are generated.

After 60 days: non-compliant messages are rejected outright. No delivery. No fallback.

Why is this harder for banks and NBFCs than for other senders?

The variable pre-tagging mandate hits BFSI organisations harder than other commercial SMS senders for three reasons.

1. Volume. A mid-sized bank or NBFC typically maintains 200 to 500 active DLT templates. Each must be reviewed, re-tagged if non-compliant, and re-registered. DLT approval for SMS typically takes 24 to 48 hours per template.

2. Multiple operators. Most banks work across Vodafone Idea, Airtel, Jio TrueConnect, BSNL, and Tata DLT. A template must be compliant with every operator portal you use. Without a centralised layer, each correction is a separate login, a separate approval cycle, and a separate sync. This is the same fragmentation problem we covered in our breakdown of Fyno vs traditional CPaaS for BFSI.

3. Regulatory messages cannot fail. OTPs, RBI-mandated UPI alerts, NACH return notices, and KYC expiry messages are not optional. A failed OTP is a failed transaction. A missed UPI alert is a customer complaint or an ombudsman escalation. The 60-day grace period is not breathing room. It is the runway you have to complete remediation before revenue-critical messages start dropping. For banks already managing regulatory requirements across customer communication channels, this adds another compliance surface to cover.

Where does manual DLT template management break under this mandate?

The operational problem is not understanding what the regulation requires. Most IT and compliance teams, once they read the Direction, understand it. The problem is execution at scale with no errors and no disruption to live message flows.

Consider what complying manually looks like for a bank with 300 templates across three DLT operators:

1. Export or document all active templates across all DLT portals.

2. Review each template for variable fields and identify the correct tag type.

3. Edit and re-register on each operator portal. Wait for approval per template.

4. Sync new DLT template IDs back to your SMS aggregator or telco.

5. Ensure your applications are sending correctly typed variable values at runtime.

That is 900 individual re-registration actions for 300 templates across three operators. With a 24-hour DLT approval SLA, running them in parallel is still a multi-week exercise. Any template that does not complete this cycle before enforcement begins will fail at delivery time.

The runtime problem

Variable pre-tagging is not just a registration-time requirement. At send time, your application must pass variables that conform to the declared type. If your OTP template uses #numeric# but your application passes an alphanumeric OTP, the message fails scrubbing and is rejected. Your IT team needs to validate this end-to-end, not just at the DLT portal.

How Fyno handles variable pre-tagging natively?

Fyno's Template Builder enforces variable type declaration at the point of template creation. Untyped variables cannot be submitted to DLT. Compliance is checked inside your workflow, not after a message has been submitted to a telco. Templates sync across all DLT operators from a single editor.

For banks migrating from manual workflows, Fyno supports bulk template import. All templates registered on your DLT account are fetched and synced to Fyno in a single onboarding step. For URL variables, Fyno's transformation layer converts outbound URLs to whitelisted domains at processing time, with no changes required to your core banking or application layer. When RBI's banking URL requirement came into force in 2024, Fyno customers handled it by enabling one processing option, without a single change request to engineering.

For OTP and transaction alert templates specifically, Fyno's intelligent routing and multi-channel failover ensure that even during the transition period, critical messages are not lost if a template fails scrubbing on one operator.