Voice AI Compliance in India 2026: The Complete Map of TRAI, DPDP, RBI, IRDAI and SEBI Obligations

The compliance head at a large insurer asked a question in a vendor review that stopped the room: "When your bot says something it should not have said, who gets the notice from the regulator, you or us?"

The vendor said it would be a shared responsibility. The compliance head said that was not a thing, and she was right. Regulatory obligations in Indian financial services attach to the regulated entity. The vendor has a contract. The insurer has a licence. Those are not the same kind of exposure, and no amount of indemnity language converts one into the other.

That asymmetry is the reason this post exists. Most teams evaluating AI calling in India research one regulation at a time, usually the one their legal team flagged first, and end up with a mental model that covers a quarter of their actual exposure. Voice AI in India sits under five overlapping regimes at once, and they do not agree with each other about basic things like what consent means.

What this post argues

There is no single "voice AI regulation" in India, and looking for one is the first mistake. What exists is five layers that apply simultaneously: TRAI governs whether you may place the call, DPDP governs what you may do with what you collect, RBI and the sector regulators govern how you must behave during it, and an audit-trail requirement runs underneath all of them because every one of the first four is enforced retrospectively through records. This post maps each layer, shows where they conflict, sets out who carries the liability when a vendor's system misbehaves, and gives a compliance architecture that satisfies all five without building four separate systems. Treat it as the hub: each layer links out to the deep dive.

Why a map, rather than another checklist

Checklists fail here for a structural reason. The five regimes were written at different times, by different bodies, with different definitions, and they overlap in ways that produce genuine contradictions rather than mere redundancy.

Consent is the clearest example. TRAI's framework recognises consent registered and tracked through the distributed ledger infrastructure, scoped to commercial communication categories. DPDP requires consent that is free, specific, informed, unconditional and unambiguous, tied to a stated purpose, and withdrawable at any time with the withdrawal being as easy as the giving. These are not the same standard. A customer can be perfectly consented under the telecom framework and inadequately consented under the data protection framework for the same call, which is the situation a large number of Indian outbound programmes are currently in without knowing it. We unpacked this specific clash in DPDP versus TRAI consent for voice recordings.

Retention is the second. Sector regulators require you to keep records of customer interactions for defined periods. DPDP requires you to not keep personal data longer than the purpose requires. A call recording that a conduct rule says keep and a data rule says delete is a real conflict that has to be resolved deliberately, usually by documenting the sectoral requirement as the retention basis rather than pretending the tension is not there.

The point of a map rather than a checklist: you need to see which layer is binding on any given decision, because when they conflict, "we followed the checklist" is not a defence.

The five layers at a glance

Layer	Regulator	Governs	Binding question	Typical failure
Commercial communication	TRAI	Whether you may place the call	Is this number scrubbed, this sender registered, this content classified?	Scrubbing at list build rather than dial time
Data protection	Data Protection Board under MeitY	What you may do with what you collect	Is there purpose-bound consent covering this specific processing?	Onboarding consent stretched to cover unrelated campaigns
Conduct	RBI	How you must behave during the call	Would this call be acceptable if a human had made it?	Calling hours and frequency enforced in policy, not in the dialer
Sector overlay	IRDAI, SEBI, RERA, health authorities	What you may say and must disclose	Has a representation or solicitation been made?	Script changes shipped without reclassification
Evidence	All of the above	Whether you can prove any of it	Can we reconstruct this call from its reference number?	Built last, or never

Read the table by column four. Those five questions, asked of any campaign, will surface most real exposure faster than any document review.

Layer 1: TRAI, or whether you may call at all

TRAI's commercial communication framework governs the act of placing a marketing or transactional voice call. Four mechanisms matter operationally.

Registration and the distributed ledger. Senders, headers and content templates register on the DLT infrastructure. The purpose is traceability: every commercial communication should be attributable to a registered entity through a registered path. For voice, the practical implication is that your telephony partner, your registration status and your consent records are linked, and a gap in any one breaks the chain. Detail in our TRAI DLT compliance guide for AI outbound calling.

Preference registration. Subscribers register preferences about what categories of commercial communication they will accept. Scrubbing against the current preference registry is mandatory before dialling. The failure mode we see repeatedly is scrubbing at list-build time rather than at dial time: a list assembled on Monday and dialled on Thursday has three days of preference changes baked into it as violations. Covered further in the DND compliance breakdown.

The promotional versus transactional distinction. This is where most breaches originate, and rarely deliberately. A payment reminder is service communication. A payment reminder that mentions a pre-approved top-up loan is promotional, and now requires a completely different consent basis. Product and marketing teams add a single sentence to a script without realising they have changed its regulatory character. The control that works is a script review gate where any change to call content is classified before it ships.

The 1600 numbering series. Transactional and service voice calls are moving to a dedicated numbering range, phased across institution categories. This is both a compliance obligation and a deliverability advantage, since customers are being taught to recognise the series as genuine. See the 1600 series phase rollout and deadlines.

Current framework documents sit at trai.gov.in.

Layer 2: DPDP, or what you may do with what you collect

The Digital Personal Data Protection Act, 2023 governs the processing of digital personal data. A voice call generates a lot of it: the recording, the transcript, whatever the customer disclosed, the derived attributes your system inferred, and the metadata around all of it.

Five duties bind most tightly on voice programmes.

Purpose limitation. Consent must be tied to a specified purpose, and processing beyond that purpose needs a fresh basis. The consequence people miss: consent captured at onboarding does not automatically cover a collections call two years later, or a cross-sell campaign, or using the recording to train a model. Each of those is a distinct purpose.

Notice. The customer must be told what is being collected and why, in clear language, with language accessibility that reflects Indian reality rather than an English-only notice.

Withdrawal. Consent must be withdrawable as easily as it was given. If your consent was captured with one tap and withdrawal requires an email to a grievance address, that is a defect.

Retention. Personal data should not outlive its purpose. Where a sectoral rule mandates longer retention, that mandate becomes the retention basis and should be documented as such.

Security and breach notification. Reasonable safeguards, and notification obligations when they fail. Call recordings containing financial detail are a high-value target and are frequently the least protected asset in the stack.

Two further points that catch teams out. Training on customer audio is a separate purpose and needs its own basis. Many vendor contracts quietly grant this. Read the clause. And data residency: where your recordings, transcripts and model inference actually happen matters, particularly if any part of the pipeline routes audio to an overseas endpoint. We covered this in voice AI data residency and sovereignty under DPDP, and the operational checklist is in the DPDP compliance checklist for voice AI.

The Act and subsequent rules are published by the Ministry of Electronics and Information Technology.

Layer 3: RBI, or how you must behave on the call

For banks, NBFCs and regulated lenders, the Reserve Bank governs conduct. Three areas apply directly to automated calling.

Fair Practices Code. Governs collections conduct: permitted calling hours, prohibition on harassment and intimidation, the requirement that the customer be able to escalate, and grievance redressal routes. Nothing in this framework says "unless a machine made the call". A bot that calls outside permitted hours, that calls repeatedly after being asked to stop, or that adopts a coercive tone is a Fair Practices breach attributable to the lender. Our RBI compliance guide for NBFC collections goes deeper.

Outsourcing and third-party risk. Where a regulated entity uses a service provider, the regulator's position is that the entity retains responsibility for the outsourced activity. This is the answer to the insurer's question at the top of this post. Contractual indemnity may recover money from the vendor. It does not move the regulatory obligation.

Authentication. For flows that touch payment authorisation, authentication requirements apply. The design consequences are set out in our companion post on OTP verification and payment reminder calls, including why an AI agent should deliver codes but not collect spoken ones.

Master directions are indexed at rbi.org.in.

Layer 4: Sector overlays

Sector regulators do not replace the layers above. They add obligations on top, and they are usually the ones that turn a script decision into a licensing question.

Insurance. IRDAI conduct requirements govern solicitation, disclosure and record-keeping. Sales and renewal calls carry disclosure obligations, and recording requirements are stricter than the general case. The specific trap for automated flows is the line between servicing and solicitation: a renewal reminder is servicing, and the same call becomes solicitation the moment it recommends a different product or a higher sum assured. Detail in the IRDAI-compliant AI calling guide, and the operational view in our insurance industry playbook. The regulator publishes at irdai.gov.in.

Securities. SEBI-regulated intermediaries carry obligations around client communication, suitability and record retention. Automated calls that touch anything resembling advice are a category to approach carefully, because a bot cannot assess suitability and the obligation does not disappear because the recommendation was generated rather than spoken by a person. The safe design keeps automated securities calls strictly informational: confirmations, reminders, document requests, and nothing that could be read as a recommendation.

Real estate. RERA governs representations about registered projects. A bot that overstates a completion timeline or a possession date has made a representation the developer owns, and the record of it is sitting in your own call archive. See the RERA-compliant AI calling field guide.

Healthcare. Patient information carries confidentiality expectations independent of DPDP. Appointment and diagnostic flows should be designed on the assumption that disclosure to the wrong person is the primary risk, which in practice means no clinical detail before identity is confirmed, and no clinical detail to voicemail at all.

Lending. For banks and NBFCs the conduct layer above is the binding one, but the sector-specific reading of it matters: see the BFSI industry view for how these obligations land on collections and servicing programmes specifically.

What enforcement actually looks like

Worth being concrete, because "compliance risk" as an abstraction does not move budgets.

Data protection carries the largest headline numbers. The DPDP Act sets financial penalties running to hundreds of crores for the most serious categories, with failure to take reasonable security safeguards attracting the highest tier. For most organisations, though, the realistic exposure is not the maximum penalty. It is the sequence that gets you there: a customer complaint, a regulator query, a request for records, and then a finding based on what you could and could not produce.

Telecom-side enforcement is more routine and more immediate. Preference and registration breaches attract financial disincentives and, at the sharper end, disconnection of telecom resources. A programme whose numbers get disconnected is not facing a fine, it is facing an outage.

Conduct enforcement in financial services typically arrives through the grievance and ombudsman route rather than as a direct penalty, and its cost is usually remediation and supervisory attention rather than a single payment. Supervisory attention is the expensive part.

The pattern across all three: the trigger is almost always a complaint, and the outcome is almost always determined by your records. Which is why the evidence layer, not the model, is where a compliance programme should start.

Layer 5: The audit trail underneath everything

This is the layer that gets built last and should be built first, because every regime above is enforced retrospectively through records. A regulator or an ombudsman does not observe your call. They ask you to produce it, months later, alongside proof that you were entitled to make it.

The test worth running: pick a call reference number at random and ask whether your team can produce, from that number alone:

Artefact	Question it answers
Consent record with purpose and timestamp	Were we entitled to make this call, for this purpose?
Preference scrub result at dial time	Did we check the registry, and when?
Script version and classification	What was the bot permitted to say, and was it promotional or service?
Full recording and transcript	What was actually said?
Disposition and outcome	What did the customer agree to?
Downstream actions	What did we send, and on what channel?
Access log for the recording	Who has listened to this, and were they entitled to?
Retention basis and deletion date	Why do we still have this?

If any row cannot be produced within an hour, that is your highest-priority gap. Not the model, not the latency, not the voice quality.

Where the layers conflict, and how to resolve it

Four genuine conflicts, and the resolution that holds up.

Retention: sectoral mandate versus DPDP minimisation. Resolve by documenting the sectoral requirement as the lawful retention basis, applying it narrowly to the records the mandate actually covers, and deleting everything outside that scope on schedule. Do not apply the longest retention period across all data because it is simpler.

Consent: TRAI category versus DPDP purpose. Resolve by capturing DPDP-grade purpose-bound consent as the primary record and treating telecom-side registration as an additional obligation rather than a substitute. The stricter standard governs.

Recording: conduct requirement versus minimisation. Some sectors require recording; DPDP wants you to hold no more than necessary. Resolve by recording what the mandate requires, redacting what it does not (payment credentials being the obvious case), and controlling access tightly.

Training data: vendor commercial interest versus purpose limitation. Resolve in contract, before signing. Default to prohibiting training on your customer audio unless you have a specific consented basis and a specific reason to allow it.

The compliance architecture that satisfies all five

You do not need five systems. You need five controls in one pipeline.

1. A consent service that stores purpose-bound consent, versioned, with withdrawal handling, and that every campaign queries rather than caches.
2. A dial-time gate that performs preference scrubbing, frequency capping across all campaigns, and permitted-hours enforcement at the moment of dial. Not at list build.
3. A script registry where every version is classified promotional or service, reviewed, and immutably versioned, so you can prove what the bot was permitted to say on any given date.
4. An evidence store that binds recording, transcript, consent reference, script version, disposition and access log to a single reference number.
5. A retention engine that applies per-record-type policies with a documented basis, and actually deletes.

The single most common architectural mistake: frequency caps implemented per campaign rather than per customer. Collections calls on Tuesday, renewals on Wednesday, cross-sell on Thursday, each team inside its own limit, and a customer who experiences harassment and reports it. The shared counter is unglamorous and it is the control that prevents the complaint that triggers the audit.

Implementation playbook

Weeks 1 to 2: Map what you have. Inventory every outbound campaign, who owns it, what consent basis it claims, and what script it runs. Most organisations discover campaigns nobody owns. Classify each script promotional or service, honestly.

Weeks 3 to 4: Close the dial-time gate. Move preference scrubbing from list build to dial. Implement the shared per-customer frequency counter. Enforce permitted hours in the dialer rather than in a policy document.

Week 5: Consent remediation. Identify campaigns operating on onboarding consent that does not cover their purpose. Either obtain a fresh basis or stop the campaign. This week is uncomfortable and is the one that most reduces actual exposure.

Week 6: Evidence store. Bind the artefacts in the audit table above to a single reference number. Test by having someone outside the team reconstruct ten random calls.

Week 7: Vendor review. Re-read the contract for training rights, sub-processing, data location, breach notification timelines and audit rights. Ask where audio physically goes during inference.

Week 8: Dry run. Simulate a regulator request and a customer grievance end to end. Time it. The gap between what you can produce and what you would need to produce is your remaining programme.

What changes in the next twelve months

DPDP operational rules continue to bed in. The direction of travel is toward more specific obligations around notice, consent management and breach handling. Programmes built on blanket onboarding consent will find the ground moving under them.

Caller identity infrastructure matures. The 1600 series plus handset-level caller identification will make outbound provenance visible to customers by default. Legitimate calls from unconsolidated numbers will increasingly be treated as spam by the ecosystem itself.

Attention turns to synthetic voice disclosure. The question of whether a customer must be told they are speaking to a machine is live in multiple jurisdictions. India has not settled it. The defensible position is to disclose anyway: the cost is a few words of script, and the alternative is retrofitting disclosure into a programme built on its absence.

Supervisory expectations shift from policy to demonstrable control. The trend across Indian financial regulation has been away from accepting documented intent and toward asking entities to evidence that a control actually operated. For outbound programmes that means the question stops being "do you have a calling-hours policy" and becomes "show me the dialer rejecting an out-of-hours call". Teams whose controls live in a policy document rather than in the pipeline will feel this first.

Bottom line

Voice AI in India is not governed by one regulation but by five overlapping ones that were not designed to fit together. TRAI decides whether you may call, DPDP decides what you may do with what you collect, RBI and the sector regulators decide how you must behave, and an audit trail underneath determines whether you can prove any of it. Where they conflict, the stricter standard governs and the conflict should be resolved deliberately and documented, not ignored. The controls that matter most are the least interesting ones: scrub at dial time rather than list time, cap frequency per customer rather than per campaign, version your scripts, and be able to reconstruct any call from its reference number. And the question that should settle every vendor conversation: when the bot gets it wrong, the notice comes to the licence holder, not the contractor.