DLT & Compliance

1. TCCCPR and DLT in plain language

The Telecom Commercial Communications Customer Preference Regulations, 2018 (TCCCPR), as amended in 2025 and on 18 September 2026, establish a framework intended to reduce unsolicited commercial communication and make legitimate senders, headers, templates, consents, and delivery participants more accountable.

Distributed Ledger Technology (DLT) is used in the telecom ecosystem to maintain records and validate elements of commercial communication. TRAI describes a Principal Entity (PE) as the business or legal entity sending communication, a header as the registered alphanumeric sender identity, and a content template as the registered fixed and variable message structure.

According to TRAI's Advice to Senders, activities required of a sender can include:

• registration as a Principal Entity;
• assignment or registration of a sender header;
• registration of the content-template structure;
• transmission of the PE ID, header, and content ID to the telecom provider;
• registration of a consent template where applicable; and
• acquisition and management of consumer consent where applicable.

Transactional or service context does not automatically eliminate every registration, header, template, or transmission requirement. Do not assume that an OTP label alone makes a message exempt.

2. Production sender checklist

Complete and verify the steps applicable to your organisation and the shared route before sending production traffic:

1. Define the exact use case. Document the user action that triggers the OTP, why the number is used, the validity period, retry rules, and fallback.
2. Identify the responsible entity or entities. Confirm whether MeraOTP, the Customer, or both must be declared or registered as Principal Entity participants for this shared route.
3. Validate the shared header. MeraOTP must ensure its configured sender header is assigned and authorised for the entity, route, chain, and message category actually used. Customers cannot replace it through the API.
4. Validate the fixed content template. MeraOTP must register and configure the exact fixed copy and two-variable order used by the gateway. Customers provide only a reviewed brand value and cannot insert arbitrary text.
5. Complete consent steps where applicable. Maintain a valid consent basis and registered consent template when required; do not use OTP consent as permission for unrelated marketing.
6. Register the delivery chain or provider relationship. Confirm current requirements with the telecom/DLT provider and any registered telemarketer or aggregator in the chain.
7. Transmit required identifiers. MeraOTP's operator must ensure PE, header, template/content, and other identifiers required by the provider accompany the delivery request in the expected format.
8. Test exact matching. MeraOTP's operator must test with consenting numbers and verify that punctuation, spaces, brand text, variables, and sender data match the registered template.
9. Configure MeraOTP access controls. Add every production server IP with its real domain or application label and keep the allowlist current.
10. Preserve evidence. Retain reasonable records of registrations, template approvals, user requests, consent where applicable, API activity, and complaint handling.

Requirements change. Re-check your telecom/DLT provider's code of practice and recent TRAI regulations or directions before launch and when your sender, template, route, provider, entity, or use case changes.

3. MeraOTP controls and Customer responsibilities

MeraOTP may request proof of compliance, but review or acceptance of documents is not a legal opinion, certification, or guarantee that your use satisfies every obligation.

4. Recommended authentication OTP template

MeraOTP uses one variable only: the numeric OTP. The verification purpose and Codegully signature are fixed text and cannot be changed by a customer.

The operator must submit this exact wording and single variable position to the relevant DLT/provider and configure the corresponding approved Fast2SMS message/template ID. The placeholder syntax shown above must match the syntax accepted for the registered template. Customers cannot change the fixed wording, signature, or template ID.

Template drafting principles

• Use a short, recognisable project brand that was reviewed during onboarding.
• Keep exactly one approved OTP variable; the gateway sends only the numeric OTP as variables_values.
• Do not use a broad variable to insert promotional sentences, URLs, phone numbers, payment instructions, or unrelated content.
• Do not ask the recipient to disclose the code to support, an employee, an agent, a courier, or any other person.
• Do not include passwords, account balances, complete financial identifiers, or unnecessary personal data.

5. Avoiding template and sender mismatch

Operator scrubbing can reject a message when request data does not match the registered entity, header, template, category, or variable structure. MeraOTP support must check the route-level items below; Customers should provide the request reference and reviewed brand without sending an OTP value:

• the sender ID/header is active, belongs to the correct PE, and is entered exactly;
• the content/template ID is current and connected to that header and route;
• fixed text, punctuation, whitespace, casing, and brand references match the approved content;
• variables are in the approved locations and contain only permitted values;
• the PE ID, template/content ID, header, consent details, and chain information required by the provider are transmitted correctly;
• the use category matches the actual message and recipient action; and
• the destination number, format, and route are supported.

Do not repeatedly retry a rejected message without correcting the cause. Repeated retries can create recipient harm, waste credits, and trigger provider or platform controls.

6. Privacy and data protection

An OTP request involves personal and security-sensitive information. Apply data minimisation: send only the recipient number, necessary approved template variables, and the request metadata required by the API. Do not use an OTP message to transmit a password, PIN, government ID, full account number, health information, or other unnecessary sensitive data.

Your privacy notice should explain your identity, the authentication purpose, service providers, retention, security, user rights, and how to contact you. Establish a lawful basis for processing and a process to correct or delete information where required, while preserving records you must legally retain.

India's Digital Personal Data Protection Act, 2023 and the notified Digital Personal Data Protection Rules, 2025 establish a phased framework for digital personal data. Different provisions commence on different dates. Customers must track the provisions currently applicable to their processing and obtain legal advice for their circumstances. See the MeraOTP Privacy Policy for our platform practices.

7. Authentication and API security checklist

• Use MeraOTP's server-generated OTP and never attempt to supply, predict, reuse, or expose the code.
• Respect the MeraOTP expiry and one-time verification result; do not build a parallel client-side OTP verifier.
• Bind the verification to the intended user, session, mobile number, and action so a code cannot be replayed elsewhere.
• Hash or otherwise securely protect OTPs at rest and never place them in URL query strings or client analytics.
• Limit verification attempts and issue requests by user, number, IP, device, and account; add cool-down and bot controls.
• Keep the MeraOTP API key on your backend, outside source control, and rotate it after suspected exposure.
• Use HTTPS, validate inputs and responses, set timeouts, avoid uncontrolled automatic retries, and fail safely.
• Mask phone numbers and remove OTP values from application logs, screenshots, support tickets, and monitoring payloads.
• Review allowlisted server IPs and their labels regularly; remove stale entries and do not use localhost as a production route.

8. Records, complaints, and incidents

Maintain enough evidence to investigate an OTP complaint without collecting excessive data. Useful records can include the user action, time, masked recipient, internal request ID, MeraOTP transaction ID, template/header IDs, source, status, attempt count, and relevant consent or privacy notice version.

If an API key, account, domain, sender, template, or user database may be compromised:

1. stop or restrict affected traffic and revoke/rotate exposed credentials;
2. preserve relevant logs and record the timeline without copying OTPs into new systems;
3. contact MeraOTP support with non-secret identifiers and the affected period;
4. notify your telecom/DLT, hosting, payment, or other providers as appropriate;
5. assess required notifications to affected people and authorities; and
6. correct the cause before resuming production traffic.

9. Primary official references

Use current primary sources rather than relying only on summaries:

• TRAI — Advice to Senders
• TRAI — TCCCPR overview and resources
• TRAI — TCCCPR regulations and amendments, including the Third Amendment, 2026
• TRAI — Current directions, including header and content-template measures
• Government of India — Digital Personal Data Protection Act, 2023
• MeitY — Digital Personal Data Protection Rules, 2025, commencement timeline, and corrigendum

Telecom-provider codes, DLT portal instructions, statutes, rules, and directions can change after this page is published. Confirm the current requirements with your provider and qualified legal/compliance advisers before launch.