Compliance2 min read
DLT registration for collections messaging, without the mystery
Most delivery failures on collections SMS in India are not network problems. They are registration problems, and they are entirely avoidable once somebody owns the template list.
Commercial SMS in India runs through the distributed ledger registration framework operated by the telecom operators under TRAI direction. Senders register, headers are registered, and message templates are registered. A message that does not match a registered template against a registered header does not get delivered, and the sender usually finds out from a report rather than from a person.
The three things that must line up
- The entity, registered once.
- The header, the six-character sender ID the borrower sees, tied to that entity and to a category of use.
- The template, matching the message body exactly, with variables in defined positions.
Delivery failures almost always come from the third. A template approved with two variables cannot carry three. A full stop added to make the message read better is a mismatch. This is why collections messaging should be composed from a managed template library rather than typed by whoever is running the campaign.
Transactional, service and promotional are not interchangeable
The category a template is registered under governs when it can be sent and whether preference scrubbing applies. Collections messages are not marketing, and registering them in a promotional category is both wrong and self-defeating, because it exposes them to preference filtering that removes exactly the borrowers you need to reach. Getting the category right at registration is worth more than any amount of retry logic afterwards.
Where operations lose time
- Approval lag. New templates take time, so the template list has to be planned ahead of the campaign, not during it.
- Language variants. Each language is its own template, and a ten-language strategy is ten registrations per message.
- Silent drift. Someone edits the copy in the campaign tool and not in the registry, and delivery quietly falls.
- Header confusion across group entities, where a borrower receives messages from a header they do not recognise and treats them as fraud.
Treat delivery receipts as strategy, not diagnostics
The receipt tells you whether the message arrived. In collections that is not a technical detail, it is a branch: a delivered message that went unanswered is a contactable borrower who chose not to act, while an undelivered one is an unreachable borrower, and the next step differs completely. An operation that logs receipts but does not act on them is collecting the signal and discarding the value.
The check to run this week
Pull last month delivery rate by template. If one template is materially below the others, it is a registration mismatch rather than bad luck, and it has been quietly costing you contact for however long it has been live.