DLT — Distributed Ledger Technology registration in India
Commercial messaging in India runs on a shared registry the telecom operators maintain between them. A business registers itself, then its sender header, then every message template it wants to send, and anything that does not match a registration is rejected by the operator. Connect holds the registration data; the registration itself is a process with the operators and cannot be completed in Connect.
Why a ledger is involved at all#
The regulator's problem was that each access provider held its own record of who was allowed to send what, and a sender blocked by one could keep working through another. A distributed ledger shared between the operators makes one registration visible to all of them, and makes a revocation visible just as quickly.
For a business the technology is largely invisible: you deal with an operator's registration portal, not with a ledger. What is visible is the consequence — registration is not per-operator, a rejection follows you, and the state of your registration is shared rather than local.
Four registrations, in this order#
- Entity. The business itself registers, with its legal identity and documents, and receives an entity identifier. Nothing else can be registered until this exists.
- Header. The sender identity recipients will see — a short alphanumeric string in the Indian format — registered against the entity and classified by the kind of traffic it will carry.
- Template. Every message body, registered with its fixed text and its variable fields, and approved individually. Approval is of the exact wording.
- Consent and preference. Recipient preferences live on the operator side, and promotional traffic is filtered against them. Consent for the messages you send is the sender's own responsibility to hold and to evidence.
An intermediary that sends on a business's behalf registers separately as a telemarketer, and the chain of who is sending for whom is part of the record rather than a private arrangement between two companies.
Templates are matched, not merely stored#
This is where most first attempts fail. A registered template is a pattern: fixed text with named slots. The operator compares the message you actually send against that pattern and rejects it if the fixed part differs — an added full stop, a changed greeting, a line break in a new place. Registering the template is not permission to send similar text; it is permission to send *that* text.
| What happened | Why it is rejected | The fix |
|---|---|---|
| The fixed wording was edited after approval | The message no longer matches the registered pattern | Register a new template, or restore the approved wording exactly |
| A variable carried more text than the format allows | Variable fields have length limits | Shorten the value, or split the content across fields |
| Promotional content sent under a service header | Classification is part of the header registration | Use the header registered for that traffic class |
| The header was never registered for this entity | There is no approved sender identity to attribute it to | Complete header registration before template registration |
Does Connect use DLT?#
Foundation, and deliberately partial. Connect holds the registration data — entity, header and template identifiers — so that a message can carry the references an operator expects, and the SMS · DLT screen is where that data lives. What Connect does not do is register anything: entity, header and template registration are conducted with the telecom operators, and no setting inside Connect substitutes for them.
The narrowness is compounded by the channel underneath. Outbound SMS is itself foundation here: it depends on a configured provider that carries SMS, and the carrier on the live account carries none. Registration data without a sending route is preparation rather than capability, and saying so is more useful than a screen implying otherwise.
Nothing on this page is legal advice, and Connect holds no certification of any kind. What it holds is the reference data your registrations produce; the obligations remain the sender's.
Where a registered sender still gets blocked#
- Preference filtering
- A recipient's registered preferences can block promotional traffic outright or restrict it to certain categories, regardless of your registration being valid.
- Time-band restriction
- Promotional traffic is confined to permitted hours. A campaign that runs overnight is not delayed so much as discarded.
- Complaint-driven action
- Complaints attach to the entity and the header. Enough of them and the registration itself is at risk, which is why a service header used for promotion is a bad trade.
- Consent you cannot evidence
- Consent is the sender's to hold. A challenge you cannot answer with a record is a challenge you have lost.
The practical reading is that registration removes one class of failure and leaves the others intact. Getting through the portal is the beginning of compliance work, not the end of it.
Questions#
Can Connect complete a DLT registration for me?
No. Entity, header and template registration are done with the telecom operators through their own portals. Connect holds the identifiers those registrations produce so that outbound messages can reference them, and that is the extent of it.
Why was a message rejected when the provider accepted it?
Because the two checks happen in different places. The provider accepts the API call; the operator matches the message against the registered template and the header's classification. A mismatch in the fixed wording is the most common reason, and an edit made after approval is the most common cause of a mismatch.
Does DLT apply outside India?
No — this particular registry is India's. Several other markets run their own sender registration schemes with different rules, and a sender identity approved in one country means nothing in another.