Distributed ledger technology (DLT) is a digital system for keeping and managing the record of sender IDs and template.
TRAI has introduced an advanced extension of the Blockchain – Distributed Ledger Technology (DLT) to prevent spam
Guidelines for Distributed Ledger Technology (DLT) for Enterprises
Enterprises need to register with the Operator's DLT platform by submitting necessary business documents. Enterprises need to select a Registered Telemarketer (RTM) and permit them to perform functions on their behalf.
Enterprises need to acquire consent from consumers (mobile subscribers) through SMS, Web or Mobile App and upload them on the DLT platform.
It is mandatory for any entity that intends to send a communication through messaging and voice gateway on the DLT platforms.
Telemarketers and end-users have to register on the DLT platforms separately.
Header (Sender ID) registration: Messages are classified into promotional, transactional, service explicit and service implicit which are registered and every header gets a unique Header ID that is shared across other DLT platforms seamlessly. All headers and templates on the platform should be registered.
Content Template Registration: Entities are required to register all their templates on the DLT system. Every template gets a unique Template ID that is shared across other DLT platforms uniformly.
To complete your Entity ID registration, you must provide KYC (Know Your Customer) documents, including GST, PAN, and other relevant identification. Upon submission, both businesses and individuals will receive a unique Entity ID.
SMS messages are categorized as Promotional, Transactional, Service Implicit, or Service Explicit. Each message must align with one of these classifications, and each header is assigned a unique Sender ID (Header ID).
Upon creation, an SMS template remains under the reality's power across all platforms. Each template is given a distinct Template ID that integrates easily across Blockchain DLT SMS systems.
We are writing to you in continuation to our earlier communication dated 18th October, 2024 wherein we informed you about compliance of very important Directions issued by Telecom Regulatory Authority of India (TRAI), Government on India on 20.08.2024 and 16.02.2023 to curb the misuse of Headers and Content Templates and to curb unauthorised activities using telecom resources.
The above-mentioned TRAI Directions mandates that all Principal Entities (PEs) shall disclose the entire chain through which the intended commercial communication will reach to the end customer, and that shall include all the involved Registered Telemarketers (Aggregator-Telemarketer and Delivery Function-Telemarketer) between PE and OAP (Originating Access Provider). Para 10 (c) of TRAI’s Direction dated 20.08.2024 stipulates to ensure that “the messages from Principal Entities to the recipients are traceable and, with effect from 01 November 2024, all messages, where the chain of Telemarketers is not defined or does not match, are rejected”.
TRAI Directions will be implemented with effect from 1st November 2024 by all the Telecom Service Providers (TSPs).
We would like to inform you that the facility to create the Principal Entities and Telemarketer Chain Binding is LIVE across all DLT Operators.
Please ensure that your respective chains are duly registered on all Operator DLT Portal, well before November 1, 2024, to avoid any message blocking.
Key Requirements and Timelines:
Approval Process:
SMS Delivery and Scrubbing Compliance:
Below is our telemarketer details for PE-TM Mapping with KDPL:
We have attached the Operator's DLT’s PE-TM chain mapping manual for your reference.
We urge you to begin defining and approving your telemarketer chain as soon as possible to avoid disruptions to your SMS delivery operations.
Note: Telemarketer Aggregators (TMA) are requested to align with their next level (TMD) in the chain, to comply with the new process.
Requesting you to inform the relevant person and forward this mail to them if you are not the relevant point of contact.
We appreciate your attention and cooperation in implementing these changes. If you have any questions or need further clarification, please feel free to contact our support team at Support@kingdigital.in
PE TM Chain Creation Regarding measures to curb misuse of Headers and Content Templates Regarding measures to curb unauthorised activities TCCCPR 2018 TRAI Regulations Principal Entity and Telemarketing Binding USER MANUAL PE-TM Binding
This document provides a step-by-step guide for establishing the PE–TM chain on DLT, applicable for Enterprises, Telemarketers handling Aggregation Functions (TM-AF), and Telemarketers responsible for Delivery Functions.
Measures to prevent misuse of Headers and Content Templates include strict registration and validation processes. This ensures compliance and reduces unauthorized usage under the DLT system.
To curb unauthorized activities, strict registration and monitoring processes are implemented. This ensures compliance and prevents misuse within the system.
The Telecom Commercial Communications Customer Preference Regulations (TCCCPR) 2018, established by the Telecom Regulatory Authority of India (TRAI), are designed to curb unsolicited commercial communications and strengthen consumer protection.
To ensure transparency in SMS transmission, PEs must declare their associated Telemarketer, Aggregator, and Delivery entities. PEs and authorized telemarketers should avoid unregistered telemarketers, and reject messages with an undefined or mismatched telemarketer chain.
To bind a Principal Entity (PE) with a Telemarketer (TM) on the DLT platform, start by selecting the Telemarketer and verifying that all necessary KYC documents are up-to-date. Submit the binding request on the DLT system, ensuring all required identifiers are included. Once approved, the binding will be activated, enabling seamless communication flow within the PE-TM chain.
DLT | Pre DLT | Post DLT | Remarks |
Customer Consent | No | Yes | Verifiable digital records of all customer opt-ins are made available on the platform. Customers can also see all their consents on a single dashboard |
Customer Preferences | Yes | Yes | Consumers can also select specific day(s) and time band to block (or) receive. commercial communication in addition to type of category; viz only DND |
Entity/Enterprise Registration | No | Yes | Entity need to register with originating access provider (OAP) on the platform |
Telemarketer Registration | Yes | Yes | Telemarketer should now register with originating access provider (OAP) and no longer with TRAI |
Header Registration | No | Yes | Entity should register all its SMS Headers and Voice CLIs on the platform |
Type of Messages | Transactional | Transactional | Every template should be registered under one of these classifications: Promotional, Transactional or Service (Implicit or Explicit) |
Promotional | Promotional | ||
Govt | Service (Inferred Consent) | Government messages are classified under Service category | |
Service (Explicit Consent) | |||
Scrubbing | Yes (only DND Check for Promotional SMS) | Yes (Promotional & Service Explicit) | Messages will be scrubbed against multiple parameters like Consent, Preference, Header, Template; and not just DND list |
Complaint Management | Yes | Yes | Telecom operators will now be responsible for complaint resolution |
Interoperability between telecom Service Providers | No | Yes | Registration details of Entity, Telemarketer, Header, Template will be shared across the network to ensure seamless view |
100% Traceability | No | Yes | Everything is recorded and shared on the network using Blockchain technology. |
Delivery Report | Yes | No | Delivery status for promotional messages will not be available post DLT. |
1. Promotional Traffic | |||
2. Transactional Traffic | Yes | Yes | Delivery status for transactional messages will continue to be available post DLT. |
NOTE: TO BE PROVIDE IN LETTER HEAD OF COMPANY
DLT is a decentralized system for securely recording, sharing, and managing data across a network, eliminating the need for a central authority.
Key Features:
Decentralization: Each participant maintains a synchronized ledger copy, enhancing security and reducing risks like tampering.
Transparency: All participants access the same ledger, fostering trust and visibility.
Immutability: Recorded transactions are tamper-resistant and require consensus to alter, ensuring data integrity.
Consensus Mechanisms: DLT uses methods like Proof of Work (PoW) or Proof of Stake (PoS) to validate transactions and keep data accurate across the network.
-Importance of DLT in Telecom
This DLT registration and template approval process offers several advantages:
Spam Reduction: By enforcing pre-approved templates, telecom providers can better control unsolicited messages and minimize spam.
Enhanced Security: Ensuring that only registered entities can send messages builds trust among recipients and reduces the risks of phishing or malicious content.
Standardization Across Platforms: With multiple telecom providers using DLT, there’s a standardized approach for all businesses, promoting transparency and reliability.
DLT’s integration in telecommunications has set a new standard for managing SMS traffic, providing regulatory compliance and safeguarding user experience in mobile communications.
Absolutely. DLT registration is a mandatory requirement for all Telemarketers, Resellers, Companies, and Individual Users to ensure compliance and seamless message delivery.
No, while TRAI (Telecom Regulatory Authority of India) oversees regulations, DLT registration itself is handled by telecom operators. To complete your DLT registration, you’ll need to contact operators such as MTNL, BSNL, Airtel, Jio, Vodafone Idea (VILPOWER), or Videocon (PingConnect).
The DLT Registration process involves three key steps:
Entity Registration – Register your organization as an entity.
Sender ID (Header) Registration – Set up your unique sender ID for message identification.
Template Registration – Register your message templates for content compliance.
Each step is essential to ensure your messages are approved and delivered smoothly.
Yes, an entity can register multiple headers for different communication types, provided each header is compliant with DLT regulations.