AI Calling Compliance in India (2026): TRAI DLT, DND/NCPR, DPDP & RBI
Last updated:
A practical breakdown of what TRAI calling windows, DLT headers, DND/NCPR scrubbing, DPDP consent, and RBI FPC mean for teams deploying AI auto-dialers in India — and how to enforce each in production.
Deploying an AI auto-dialer in India means navigating four overlapping regulatory regimes: TRAI telecom rules (calling windows + DLT registration), the DND/NCPR registry, the Digital Personal Data Protection Act 2023, and RBI Fair Practices Code for collections. Each regime has distinct requirements. This guide explains what each regime demands operationally, what 'compliant by default' means on a platform level, and where the tenant's responsibility begins.
01
TRAI calling windows: what the rules require
TRAI's Unsolicited Commercial Communications (UCC) regulations prohibit outbound commercial calls before 09:00 and after 21:00 IST (Indian Standard Time). The restriction applies to the called party's time zone. Violations carry subscriber complaints and operator penalties. The key operational requirement is that no dial — including retries — should leave the platform outside this window, regardless of when a campaign is launched or a retry is scheduled.
No outbound commercial call may be placed before 09:00 IST or after 21:00 IST.
The window applies to every dial attempt, including retries and callbacks.
Violations are reportable by subscribers and carry regulator action against the originating operator.
02
TRAI DLT: registration, headers, and template approval
The Distributed Ledger Technology (DLT) framework, mandated by TRAI, requires commercial SMS and WhatsApp messages to carry a registered Sender ID (PE ID and Header) and to be associated with a pre-approved content template. For outbound voice calls, the DLT requirement primarily covers PE (Principal Entity) registration and the registration of the caller-line identity (the "from" number) under an approved sender header — voice calls are not subject to the same per-message content-template gating as SMS and WhatsApp under the DLT framework. Consult your legal counsel and DLT portal on the current voice-specific requirements for your use case.
PE (Principal Entity) ID: your company must register on any of the TRAI-mandated DLT portals (Vodafone Idea, Jio, Airtel, BSNL, or TATA).
Header (Sender ID): the registered caller-line identity (the "from" number) should be associated with an approved sender header under your PE ID.
Content template (SMS / WhatsApp): for messaging channels, the approved content template must match the registered category (transactional, promotional, or service). Voice calls are governed by consent and calling-window compliance rather than DLT content templates.
Telemarketer registration: the originating entity placing calls on your behalf must be a registered telemarketer on the DLT platform.
03
DND / NCPR registry: scrubbing requirements
The National Customer Preference Registry (NCPR), commonly called the Do Not Disturb (DND) registry, is TRAI's opt-out list for commercial communications. Subscribers who register on NCPR must not receive commercial calls. The requirement is mandatory — there is no opt-in override. Scrubbing must happen before each dial, not just at list import, because subscribers can register or update their preferences at any time.
Scrubbing is mandatory before each outbound commercial dial, not a one-time list clean.
Partial DND registrations (e.g. "no financial calls" but allowing service calls) require category-level matching.
Operators are required to update their DND seed from TRAI daily.
There is no "consent overrides DND" exception for most commercial voice categories — NCPR registration takes precedence.
04
DPDP Act 2023: consent, erasure, retention, and data residency
The Digital Personal Data Protection Act 2023 (DPDP) establishes a consent-first framework for processing personal data in India. For AI calling platforms, the most operationally significant requirements are: obtaining a lawful basis (typically consent) before processing a data principal's phone number for commercial outreach, honouring erasure requests, limiting retention to the stated purpose, and keeping data of Indian residents within India or in approved jurisdictions.
Consent record: a consent action with timestamp must be captured and stored before processing personal contact data for outbound calling.
Erasure right: a data principal may request deletion of their data; the platform must support deletion of the contact record, associated call logs, and removal from future dials.
Retention limitation: personal data should not be retained beyond the purpose for which consent was given.
Data residency: the DPDP Act requires that personal data of Indian residents not be transferred to jurisdictions not approved by the government. Cloud infrastructure serving Indian data should be hosted in India.
Significant data fiduciary obligations (for large-scale processors) include DPIA, DPO appointment, and additional safeguards — evaluate based on your processing volume.
05
RBI Fair Practices Code: collections calling
For non-banking financial companies and regulated lenders, the Reserve Bank of India's Fair Practices Code (FPC) and its guidelines on recovery agents impose specific requirements on collection calls. These include restrictions on call timing (broadly aligned with TRAI windows), prohibition of harassment or misrepresentation, requirements on identifying the calling entity, and restrictions on contacting third parties not authorised by the borrower.
Calling windows for recovery agents are broadly aligned with TRAI (no calls before 08:00 or after 20:00 per RBI guidance, stricter than TRAI in some interpretations — consult your legal counsel on the applicable standard).
Recovery agents must identify themselves and the lending institution on every call.
Calls to references, guarantors, or third parties not designated by the borrower are prohibited under most RBI interpretations.
Harassment, abusive language, and misrepresentation of the debt amount are prohibited.
Borrowers who dispute the debt must be given a formal channel to raise the dispute.
06
What "compliant by default" means operationally
A platform claiming compliance-by-default must enforce the above rules at the infrastructure level — not rely on the tenant to remember to check a box before launching. The key distinction is between a compliance checklist (the tenant's responsibility to follow) and a compliance gate (the platform's enforcement that cannot be bypassed). True compliant-by-default platforms enforce the following automatically, regardless of how a campaign is configured:
Calling-window gate: every dial is checked against the 09:00–21:00 IST window before being placed. Retries and callbacks go through the same gate.
DND scrub: every number is checked against the current DND seed before a dial is issued. Numbers flagged DND are skipped, not just logged.
Consent capture: a consent action and timestamp are recorded at call open.
Audit log: every platform action — dial, skip, retry, escalation, consent, opt-out — is written to an immutable, append-only log available for regulator review.
Opt-out detection: in-call opt-out signals (verbal "remove me from your list") are detected and honoured — the contact is flagged and excluded from future dials automatically.
07
How Vaanicall enforces each requirement
The following describes Vaanicall's enforcement of the above requirements as shipped features, verified against the current codebase and docs/STATUS.md. These are not aspirational — they are live and tested.
TRAI calling window: enforced as a hard gate via the `can_dial` function at the orchestrator layer. Every outbound dial, including campaign dials, retries, and inbound-redial callbacks, passes through this gate. A 2,000-case randomized property-style test proves no out-of-window dial can leak through any combination of inputs.
DND scrub: contacts are checked against the DND registry on CSV import (normalised and deduplicated) and again at dial time. DND-registered numbers are hard-skipped.
DPDP consent record: consent action and timestamp are captured at call open and written to the audit log. Per-contact data export (DPDP right to access) and erasure (delete contact record + flag DND + audit trail) are implemented as platform APIs.
Data residency: Vaanicall's infrastructure for Indian customer data is deployed in ap-south-1 (AWS Mumbai region) by default. The platform is India-resident by design for Indian tenant data.
Audit log: every call action — launch, dial, skip, retry, disposition, consent event, opt-out — is written to a monthly-partitioned, append-only audit log. Records are available for regulator or supervisor review.
DLT template manager: Vaanicall includes a DLT template manager (shipped as part of the P12 BYOK + DLT feature set). Tenants register their PE ID, sender headers, and content templates for SMS and WhatsApp messaging channels; the send gate blocks unapproved or template-less sends on those channels. Voice calls are governed by the calling-window gate and DND scrub; they are not subject to per-call content-template validation under the DLT send gate.
Opt-out detection: EN and Hinglish opt-out phrases are detected in-call and converted to a ConsentEvent that sets the contact's DND flag and writes an audit entry.
AI-disclosure enforcement: per TRAI guidance on AI-generated voice, Vaanicall supports optional in-call AI-disclosure. This is a per-tenant opt-in (default off, configurable in the agent builder). Tenants whose licence or legal counsel requires disclosure can enable it without code changes.
08
Tenant vs platform responsibility split
Understanding who is responsible for what is critical before deploying any AI calling stack. The platform can enforce technical gates; it cannot substitute for your legal review of your specific product type and licence.
Platform enforces: calling-window gate (no leaks), DND scrub (hard skip), consent capture, audit log, opt-out detection, data residency, DLT send-gate validation for SMS/WhatsApp channels, DPDP export/erasure APIs.
Tenant responsible for: DLT registration of your PE ID, headers, and templates on the TRAI DLT portal; ensuring your caller-line identity is registered under your PE ID for voice calls; IRDAI compliance for insurance solicitation calls; RBI FPC script review for collection calls; DPDP lawful basis documentation and DPO appointment (if applicable); obtaining underlying consent from contacts before upload; any NCPR category-level distinctions that apply to your use case.
Shared (platform + tenant): script review and approval before launch (tenant controls the agent builder; platform provides the guardrails); in-call AI-disclosure configuration (tenant decides, platform enforces if enabled).
09
How we keep this current
TRAI, DPDP, and RBI guidance evolves. This guide is reviewed quarterly against published TRAI circulars, MeitY DPDP implementation notifications, and RBI Master Directions. The "Last updated" date at the top indicates the last review. For time-sensitive regulatory questions, consult your legal counsel — this guide is educational, not legal advice.
Regulatory content is reviewed periodically. For time-sensitive compliance decisions, consult the originating regulatory body and your legal counsel.
Not legal advice. This guide is for informational and educational purposes only and does not constitute legal, regulatory, or compliance advice. Laws and regulations change — verify current requirements with the originating authority and consult qualified legal counsel before deployment.
Questions, answered
An AI auto-dialer can be TRAI-compliant if it enforces the required gates: calls are placed only within 09:00–21:00 IST, numbers are scrubbed against the DND/NCPR registry before each dial, the originating entity is registered on the DLT platform with approved headers and templates, and a consent record is maintained. The platform-level enforcement of these gates is what distinguishes a compliant-by-default AI dialer from one that merely provides a checkbox.
DPDP applies to personal data of individuals. For B2B outreach, if the contact data includes individual employees' phone numbers (as opposed to generic company numbers), DPDP obligations apply. For purely company-level contact data (e.g. a registered business phone), DPDP obligations are more limited but the TRAI and DLT requirements still apply. Consult your legal counsel on your specific contact list composition.
TRAI regulations provide for complaints to be registered by subscribers via the DND app or by contacting their telecom operator. Originating operators are required to act on complaints and can face penalties for systematic violations. Operators with repeated UCC violations can face suspension of bulk SMS/voice privileges. The exact penalty structure is governed by TRAI's current UCC regulations — see trai.gov.in for the current regulatory orders.
AI voice can be used for loan collection calls subject to TRAI window compliance, DND scrub, DLT registration, and RBI Fair Practices Code requirements for recovery agents. The call script must identify the lender and cannot misrepresent the debt amount or use harassing language. RBI has published guidance on the use of technology in recovery — your legal and compliance team should review the current Master Direction on Recovery Agents before deploying. Vaanicall's platform enforces TRAI and DND gates; the RBI-compliant script is the tenant's responsibility.
No — AI-disclosure is a per-tenant opt-in, default off. TRAI has issued guidance on AI-generated voice disclosure, but the specific mandate is evolving. Tenants whose legal counsel requires disclosure, or who choose disclosure as a best practice, can enable it in the agent builder — the platform enforces the disclosure phrase at call open when enabled. Tenants who have not enabled it are responsible for monitoring the regulatory development and enabling it when required.
A DPDP erasure request from a data principal requires deletion of their personal data. On Vaanicall, submitting an erasure request deletes the contact record, flags the number in the DND set to prevent future dials, and writes an audit entry confirming the erasure. Call records (dispositions, duration) that do not contain personal identifiers beyond the pseudonymised contact reference are subject to your data retention policy; your legal counsel should define the boundary.
Yes. Vaanicall's infrastructure for Indian tenant data is deployed in ap-south-1 (AWS Mumbai region) by default. The platform is India-resident by design: Indian PII, recordings, and transcripts are stored in the India region (F-COMP-4). For current deployment details and any tenant-specific options, contact the Vaanicall team.
Yes — the TRAI DLT framework requires the entity originating commercial calls to be registered with a PE (Principal Entity) ID on a TRAI-mandated DLT portal (Vodafone Idea, Jio, Airtel, BSNL, or TATA). The caller-line identity (the "from" number) should be registered as an approved header under your PE ID. For SMS and WhatsApp messaging, pre-approved content templates are also required; voice calls are governed by calling-window compliance and DND scrubbing rather than per-message content-template gating. Vaanicall's DLT template manager supports registration and management of SMS/WhatsApp templates and headers. Your DLT portal registration and PE ID remain the tenant's responsibility. Consult your legal counsel on the current voice-specific requirements for your call category.
The NCPR / DND registry allows subscribers to opt out of specific categories of commercial communication (e.g. banking and insurance calls) rather than all commercial calls. Handling partial opt-outs correctly requires category-level matching — a subscriber opted out of "financial calls" should not receive a loan collection call even if they have not opted out of "service calls". Vaanicall's DND scrub implements the standard DND block; if your use case requires category-level NCPR matching, configure your contact list workflow accordingly and consult your telecom operator for the applicable category codes.
Vaanicall's audit log records every platform action — dial, skip, retry, consent event, opt-out, erasure — with timestamps and call IDs in a monthly-partitioned, append-only format. For a regulatory inquiry, you can export the relevant audit log partition for the period in question. The log is not alterable after write. For DPDP compliance documentation (lawful basis records, DPO appointment, consent receipts), your legal/compliance team should maintain the programme-level documentation alongside the platform audit trail.
A self-hosted deployment path is under evaluation for future releases (roadmap). The current platform is SaaS with India data residency (ap-south-1) as the baseline. For regulated entities with specific data localisation requirements beyond SaaS, contact the Vaanicall team to discuss the roadmap and interim options.