Skip to content

New: BD, IN and PK Voice OTP capacity now live, test routes issued same day.

India DLT Registration for Senders

India requires every entity, header and template to be registered on a blockchain-based DLT platform before A2P messages will deliver. Here is how the pieces fit together.

We write about A2P SMS Compliance Integration Voice OTP VoIP
Illustration of the India DLT chain from entity to header to registered message template

India will not deliver commercial A2P SMS to a subscriber unless the sender, the header and the message template are all registered in advance. This comes from the telecom regulator’s framework for commercial communications, and it is enforced at the operator, which means a supplier cannot route around it.

For an international sender, the practical question is not whether to comply but who does each registration step and how long it takes.

What DLT is

Indian operators maintain a shared registration system, generally referred to as DLT after the distributed ledger technology it is built on. Every party involved in commercial messaging registers there, and the operators check incoming traffic against those registrations before delivering it. Traffic that does not match a registration is rejected.

Registration is not one action. It is a chain, and each link must exist before the next one is usable.

The registration chain

1. Entity registration. The business sending the messages registers itself and receives an entity identifier. This requires company documentation and is done once.

2. Header registration. The header is the sender ID that appears on the handset, typically six alphanumeric characters. Headers are registered against the entity and classified by message type. A header approved for transactional use cannot be used for promotional traffic.

3. Template registration. This is the part that surprises people. The actual message content is registered as a template, with variable fields marked. A message that does not match a registered template for the header it is sent from will not deliver, even if the entity and header are both valid.

4. Consent and scrubbing. Operators check traffic against registrations and, for promotional categories, against subscriber preferences. This happens on the operator side in real time.

Message categories

Categories differ in what they permit and when they can be sent. Broadly, transactional and service messages relating to an existing relationship are treated differently from promotional messages, which are subject to subscriber preference and time-of-day restrictions.

Getting the category wrong is a common cause of delivery failure that looks like a routing problem. A one-time password sent from a header registered for promotional use is not an OTP delivery issue; it is a registration mismatch.

Templates in practice

Templates are where most operational pain lives, for three reasons.

First, variable fields have rules about length and placement, and a message that overflows a variable can fail to match. Second, changing your message wording means registering a new template and waiting for approval, so copy changes are no longer a same-day decision. Third, the number of templates multiplies quickly, a service with several notification types, in several languages, needs a template for each combination.

Plan for this. Register templates with generous variable fields, keep an inventory of what is registered against what, and build the approval wait into your product timelines rather than discovering it during a launch.

How international senders actually connect

An overseas business generally does not hold its own Indian operator interconnects. Traffic reaches Indian networks through an Indian aggregator, and the registration work is done either by you directly on the DLT platform or by that aggregator on your behalf.

The division of labour is the thing to settle before you sign. Ask specifically: who registers the entity, who registers headers, who registers and maintains templates, what the turnaround is for a new template, and what happens when one is rejected. A supplier who treats template management as your problem is a supplier whose delivery numbers will look poor for reasons that are technically your fault.

Diagnosing failures

When Indian traffic fails, work through the chain before blaming the route:

  • Is the header registered, active, and in the right category for this message?
  • Does the message text match a registered template exactly, including punctuation outside variables?
  • Do the variable values fit within the registered field lengths?
  • Is the traffic promotional and being sent into a restricted window?
  • Only then: is the route itself the problem?

Ask your supplier for the operator-level rejection reason rather than a generic failure. In India that reason usually names the registration problem directly, which turns a routing investigation into a five-minute fix.

The framework and its operational details are revised periodically. Confirm current requirements with your Indian aggregator and the operator DLT platforms before building against anything described here.

Related: sender ID registration across markets and India route status.

Share

Keep reading

Related insights

Compliance

A2P SMS in Bangladesh: Routing and Rules

How A2P traffic reaches Bangladeshi subscribers, what the BTRC aggregator regime means for international senders, and why licence status is now a…

4 min read
Compliance

A2P SMS in Pakistan: Rules and Routing

What international senders need to know about masked sender IDs, operator-level filtering and grey-route enforcement when sending A2P traffic into Pakistan.

4 min read

Start in 24 hours

Test a live route before you commit a single dollar

Send us your destinations and traffic profile. We return a costed route plan and a free test account, usually the same business day.

Chat on WhatsApp