DLT

DLT in one paragraph that survives an audit

DLT stands for Distributed Ledger Technology, and in Indian telecom it names the registration infrastructure that access providers were required to build under the Telecom Commercial Communications Customer Preference Regulations. That is the whole of the definition a marketer needs: a shared registry, operated per circle by the access providers and their appointed platforms, in which a business registers who it is, which sender IDs it uses, which message templates it intends to send, and which recipients have consented.

The name misleads people into expecting a product. There is nothing for a marketing team to install, no ledger to query through a normal API, and no token to buy. What exists is a set of portal records with approval states. When your application hands an SMS to an aggregator, the operator looks up the header and the template, checks the category, checks the consent and the Do Not Disturb preference, and then decides whether the message may be delivered.

So the practical definition is narrower than the acronym. DLT is the precondition for commercial SMS in India: an identity check, a content check and a consent check, performed before delivery rather than after a complaint. Once you hold that definition, most of the confusing behaviour of Indian SMS follows from it, including silent failures, template rejections that appear arbitrary, and headers that work on one operator and fail on another.

Who registers what, and who is accountable

A business that sends commercial SMS is a principal entity. It registers once with an access provider or an appointed DLT platform, submits its legal identity, GSTIN, address and authorised signatory, and receives a principal entity identifier. That identifier is the anchor for everything else. A telemarketer or aggregator sending on your behalf does not replace you as the principal entity; the records stay attached to your identity, and the accountability for content stays with you.

Headers are registered next. A header is the six-character sender ID that appears in place of a phone number, and it must be registered against the principal entity before it can be used. A business commonly holds a small set of headers split by category or by brand, because promotional and transactional traffic should not share a sender identity. Sharing a header across unrelated business units concentrates risk: one bad campaign can affect every message sent under that name.

Templates come third, and they are the part that changes most often. Each template carries content, a category and a set of variables, and it is approved against your registered entity. Consent records sit alongside, either captured as a consent template or as an opt-in log that the scrubbing layer can consult. Four record types, one owner, one place to look when a message does not arrive.

• Principal entity: legal identity, GSTIN and authorised signatory, one identifier for all channels.
• Header: six alphabetic characters, registered per operator, never borrowed from another brand.
• Template: fixed wording with declared variables and a declared category.
• Consent: who agreed, to which purpose, through which template, and when.

The header, and why six characters matter

The header is the most visible artefact of DLT, because it is what a recipient sees instead of a phone number. Six alphabetic characters, tied to one principal entity, registered on each operator separately. A message sent through two operators using a header that exists on only one will fail on the other, and the failure often looks like a routing problem rather than a registration problem.

Operators and their platforms control allocation, and the practical constraints matter more than the theory. Headers are limited, they can take time to appear across all operators, and a new header has no sending history. A business that rotates headers casually loses the recognition it built, and a business that keeps one header for everything cannot separate a promotional complaint from an OTP complaint. The workable pattern is a small, stable set: one header for transactional and service messages, one for promotional messaging, both documented with their category and their owning team.

Header hygiene also has a security dimension. If a header is shared with an agency or a reseller who sends on behalf of other brands, the header stops being an identity and becomes a pipe. Recipients learn to distrust it, operators see complaints rising against it, and the genuine messages lose trust along with the junk. A dedicated header per brand, with access controlled at the aggregator, is the cheapest reputation insurance available in Indian SMS.

Templates are a content contract, not a formality

A template is the exact wording you are allowed to send, with a declared category and declared variables. The operator does not compare meaning; it compares content. Change a word, move a variable, drop the opt-out line, or send a promotional sentence under a transactional template and the message can be rejected or flagged even though the intent was innocent. This is why a template is best treated as a contract between marketing copy and network delivery.

Approval quality depends heavily on how the template is written. Variables should sit where they are unambiguous, ideally not at the very start of the message, because a leading variable makes the message look like a different template to a parser. Links should use a registered domain rather than a chain of shorteners. Category selection should be honest: an OTP is transactional, a delivery update with an upsell is not, and a re-engagement nudge is promotional however gently it is phrased.

The rejection that annoys teams most is drift. A template is approved in March, the copy is edited in July in the campaign builder rather than in the registry, and every send fails quietly. The registry still holds the March text, so the operator compares the July message against the March template and finds a mismatch. Nothing in the campaign tool warns anyone, because the campaign tool never checked.

• Keep variables out of the first characters of the body where possible.
• Use one registered short domain instead of third-party link shorteners.
• Choose the category by what the message does, not by which category is cheaper.
• Re-register a new template rather than editing a live one in place.

Consent, scrubbing and the paper trail

Consent is the layer most teams underestimate, because it is invisible until a complaint arrives. Commercial messaging in India is filtered against the Do Not Disturb preferences that subscribers set with their operators, and against the consent your business claims to hold. Scrubbing happens before the message leaves for the operator, which means a bad consent record produces a drop rather than a delivered message with a warning.

Operationally, consent needs three properties. It needs to be specific, tied to the purpose and the channel rather than a generic tick box. It needs to be evidenced, with the notice version, the collection point and the timestamp stored somewhere durable. And it needs to be revocable through the same channel, with the revocation honoured quickly enough that the next campaign does not touch the person again. Under the DPDP Act this is not a nice-to-have; it is the same evidence you would need for a rights request.

The consent template is the DLT-specific part. Where consent is captured by SMS, the opt-in message itself may need to be a registered template, and the reply is the record. Many teams store that reply in a helpdesk tool and never join it back to the contact record, which is how a person who opted in three years ago cannot be distinguished from a person who opted out last week.

What actually happens to unregistered traffic

Unregistered traffic does not arrive with a polite explanation. The access provider filters at the network edge, and the message is dropped or rejected before it reaches the handset. Your application may see a submit success followed by a delivery failure, or nothing at all if the aggregator only reports on final status. The recipient sees silence, and the team concludes that SMS is unreliable.

The common causes are mundane: a header registered on three operators but not the fourth, a template approved for one category and used for another, a variable left unfilled so the body no longer matches, a URL that was shortened in the campaign tool, or a consent record that was never joined to the phone number. Each looks like a different bug and each is the same class of bug: a record in the registry does not match the message being sent.

TRAI also provides escalation remedies rather than only filtering. Its regulations set out consequences for principal entities and telemarketers that send unauthorised commercial communication, including financial disincentives and, in serious or repeated cases, disconnection of telecom resources. Those remedies are aimed at the entity that owns the traffic, which is why an agency cannot absorb the risk on your behalf. If your OTPs stop because your header was misused, the outage is yours.

Categories, timing and the rules people forget

Commercial communication in India is split by intent, and the split has operational consequences. Promotional messages are subject to time restrictions, so a campaign scheduled at two in the morning will be queued or rejected depending on the path. Transactional messages, such as an OTP or a payment confirmation, are treated differently because the recipient is waiting for them, and service messages sit in between, tied to an existing relationship rather than to a sale.

The category is not a marketing label, it is the claim you make about the message. Sending a discount inside a delivery notification to avoid the promotional window is the classic violation, and it is exactly what the content comparison is designed to catch. If a message contains an offer, it is promotional regardless of the template it travels in, and the safe design is a separate template for the offer rather than an appended line.

Timing also affects deliverability in a subtler way. OTP latency is a product requirement, not a marketing metric, and it degrades when OTPs share a header or a route with bulk promotional traffic. Splitting transactional and promotional routes, with separate headers and separate aggregator connections, is the practical way to keep a login flow from inheriting the queue position of a festive campaign.

DLT versus WhatsApp template approval

Teams migrating from SMS to WhatsApp, or running both, usually ask whether the WhatsApp template is enough. It is not, and the confusion costs real money. WhatsApp template approval is a review performed within the WhatsApp Business Platform, run against Meta policies, with categories such as marketing, utility and authentication, and with its own 24-hour customer service window governing free-form replies. DLT is a national registry run by Indian access providers with statutory backing.

The two systems differ in who approves, what is approved, and what happens when the record is wrong. A WhatsApp template is rejected before it can be sent, with a policy reason in the platform. A DLT template is registered, and a mismatch is discovered at delivery time, in the network, often as a silent drop. WhatsApp approval is per business account and per language; DLT registration is per principal entity, per operator and per header.

That difference shapes migration projects. Moving a WhatsApp number between BSPs does not touch your DLT records, and adding SMS as a fallback channel does not reuse your Meta templates. A channel fallback ladder, WhatsApp first and SMS second, needs both registries populated, both template libraries maintained, and a mapping table that says which approved artefact corresponds to which message intent.

Wiring DLT into a product team

The engineering answer is to stop treating DLT as an operations chore and start treating it as configuration with a schema. Templates live in a repository, not in a campaign spreadsheet. Each record has a stable key, the approved body, the variable list and order, the category, the header, the operator scope and the approval date. The sending code resolves a key to an approved record and refuses to send if the key is missing or the variables do not match the declared arity.

That single change removes most incidents. Copy changes go through the registry first and the campaign second. A pull request that edits a template body without a new approval state fails validation. A campaign that references a template not approved on the target operators fails at build time rather than at 9 pm on a launch day. Variables are rendered from typed values, so a missing name cannot quietly become an empty string in a transactional message.

Ownership completes the picture. Someone must own headers, someone must own the template library, and both need a review cadence aligned with campaign planning. In practice one person in lifecycle marketing and one engineer is enough, provided the registry is the only source and the portals are never edited by hand without a corresponding change in the repository.

• Store templates as data with a stable key, category and variable schema.
• Validate variable arity at build time, not at send time.
• Map each operator to the headers that are actually live there.
• Keep a dry-run path that renders the exact body for review.
• Log the template version and header on every send event.

Measuring DLT health, with a worked example

Four measures tell you whether the registry is healthy. Delivery rate by operator catches the header that is missing on one network. Template rejection rate catches copy that keeps failing review. Mismatch errors catch drift between the registry and the campaign builder. Opt-out rate by template catches categories that are being stretched, because promotional content in a service template shows up as complaints rather than as rejections.

Take a mid-sized team sending 1,20,000 SMS a month: 80,000 OTP and transactional, 30,000 service updates, 10,000 promotional. Suppose delivery is 96 percent on two operators and 71 percent on a third, and that third network carries about 12,000 messages a month. A 25 point gap on that volume is roughly 3,000 messages that never arrive, and it is invisible because the dashboard averages the three networks into one number. The cause is almost never routing; it is one header that was never registered on that operator.

The fix is unglamorous: break delivery down by operator and header, alert when any cell drops more than a few points week on week, and keep the registration date for each header so a new network launch triggers a checklist rather than a surprise. Teams that do this stop discovering DLT during outages and start treating it as part of release management, which is what the regulation effectively asks for.