DLT registration, and why your first invoice has a line for it

DLT stands for Distributed Ledger Technology, which is a misleading name for what it actually is: a registry each telecom operator runs, recording who is allowed to send commercial SMS, under what sender name, and with what message text. It exists because of TRAI’s TCCCPR regulations, which were written to stop unsolicited commercial messaging.

Three things get registered, and in this order — each one hangs off the one before it:

1. Your principal entity. Your business, with its PAN and GST. You get an entity ID.
2. A sender ID (a “header”). Six characters, like ACMEIN, registered against that entity and against a declared purpose.
3. Each message template. The exact text, with {#var#} where a value will go.

The carrier drops the message, and you are still charged for it. Not an error, not a bounce, not a delivery report saying why — the message is accepted by the aggregator, billed, and never arrives. That asymmetry is the whole reason this product behaves the way it does.

The same is true of a message whose text does not match its registered template exactly. Change a word, add a space, send a body you composed by hand — the carrier compares it against the registration and discards it. Which is why a template here is a frozen format you fill in, never a draft you edit at send time, and why an approved template’s text cannot be changed: changing it means registering a new one.

The operator’s registration charges for your principal entity, and our work submitting your sender IDs and templates and chasing their approval. It is per year and mandatory on every plan, which is why it is a separate invoice line rather than folded into a plan fee — it is not our revenue and pretending otherwise would be dishonest about what you are buying.

It is also why there is no free tier. A free account would still cost a real registration, and a free tier that cannot send teaches nobody anything.

A few working days, usually, and it is the operator’s decision rather than ours — we cannot promise a timeline we do not control. A sender ID is reviewed by a person at the operator; so is each template. A rejection comes back with their reason, which we show you verbatim so you can fix the thing they actually objected to.

You can set everything up while you wait. Add your entity ID, draft your sender ID and templates, import your contacts — nothing can be sent until the operator approves, and the app says which step you are waiting on rather than failing silently.

A template is registered under a category, and the category decides who it can reach:

• Transactional — one-time passwords, and nothing else. Reaches every subscriber including those on DND.
• Service (implicit) — a fact about something the recipient did: an order update, a delivery alert.
• Service (explicit) — to recipients who gave this sender explicit consent.
• Promotional — marketing. Blocked for DND subscribers, and time-restricted.

Sending promotional text on a transactional header is dropped by the carrier, so we refuse the mismatch at the point you register the template rather than at the point you send. And a promotional campaign here skips DND contacts automatically — they are reported as skipped rather than failed, because that is the system obeying the regulation rather than something going wrong.

International numbers. DLT is an Indian regime for Indian subscribers, and we send to +91 mobile numbers only — a different country means a different registration, a different price and a different compliance story. Offering it on this one would be pretending otherwise.