TL;DR

  • Every AI collection call must begin with right-party verification
  • DND scrubbing must run against a current registry, not a stale list
  • Three mandatory disclosures must complete before collection dialogue starts
  • Multi-language compliance applies to every script variant independently
  • Audit artifacts must be inspection-ready at the individual call level

A surgeon who is technically brilliant but untrained in pre-operative consent protocols creates a specific kind of legal exposure. The procedure might be flawless. The clinical outcome might be excellent. But if the patient was not properly informed before the incision, the entire intervention is legally compromised regardless of its quality. Skill does not cure a consent failure.

AI collection calls in India carry the same structure. The propensity model might be accurate. The timing might be optimal. The recovery rate might be strong. But if the call itself started without right-party verification, without the required disclosures, or without valid consent, every interaction in that campaign is a compliance liability. Platform performance and platform compliance are separate questions, and in 2026, under India’s three-layer regulatory framework, getting the compliance question wrong has quantifiable consequences.

This blog is a practitioner’s guide to building a compliant AI collections call flow under RBI’s 2025 Directions, TRAI’s telecom conduct rules, and the DPDP Act 2023. It covers what must happen before the call is placed, what must happen during it, and what audit evidence must be generated when it ends.

The Three Regulatory Layers Every AI Collections Call Operates Under

Before mapping the call flow itself, it helps to be clear on which regulation governs which part of the interaction. Three distinct bodies of rules apply simultaneously to every AI collection call placed in India.

RBI’s Fair Practices Code and Digital Lending Directions 2025 govern how regulated entities and their LSPs conduct recovery. The operational obligations include calling hour restrictions, mandatory disclosures, grievance redressal access, consent requirements, and recording obligations. These apply to AI agents with the same force as human agents.

TRAI’s Telecom Commercial Communications Customer Preference Regulations (TCCCPR) govern calling conduct from the telecom infrastructure side. DND registry compliance, caller ID registration, and the classification of calls as transactional or promotional all fall under TRAI’s framework. Collections calls are generally classified as transactional under TRAI, but that classification does not remove calling hour and registration obligations.exotel

The Digital Personal Data Protection Act 2023 (DPDP Act) governs how borrower personal data is collected, processed, stored, and disclosed. Every call initiates a data processing event. Every account detail disclosed during a call is personal data subject to DPDP obligations. Consent architecture, retention limits, and data principal rights all operate in the background of every outbound collections interaction.

A compliant AI collections call must satisfy all three frameworks simultaneously. None of them overrides the others, and a clean record under two of them does not provide a defense against a violation under the third.

Before the Call: DND, Caller ID, and Pre-Dial Checks

Every dial attempt must clear a set of mandatory pre-call checks before any outreach is initiated. These are not campaign-level setup steps. They are per-attempt checks that run at the account level before each individual dial.

DND scrubbing against a current registry snapshot: TRAI’s National Customer Preference Registry (NCPR) updates continuously. An AI platform that scrubs its contact list once at campaign build and considers the task done is using stale data from the first hour of the campaign onward. The scrub must run against a current snapshot, and every suppressed attempt must be logged with a timestamp, a reason code, and the date of the NCPR snapshot used.exotel

Registered and traceable caller ID: RBI’s 2025 Directions require that collections calls be made from nominated, disclosed contact numbers traceable to the regulated entity. TRAI requires caller IDs to be registered with the relevant telecom operator. An unregistered, masked, or rotated number that cannot be traced back to the NBFC creates a simultaneous TRAI violation and an RBI attribution problem: if the caller cannot be identified as the RE’s agent at the point of contact, the mandatory identity disclosure at call start has already failed before the AI spoke a word.

Calling hour check at the account level: The permitted window is 8 AM to 7 PM in the borrower’s local time zone. This check must run at the account level, not the campaign level, because a campaign covering borrowers across multiple states and time zones cannot use a single national calling window without generating violations at the edges. The Northeast, for example, operates at IST +30 minutes. The system must account for this. If an ongoing call extends toward the 7 PM cutoff, the AI must be capable of gracefully concluding the interaction before the window closes.

Consent verification per channel: The 2025 Directions require purpose-specific consent before initiating any digital communication channel. The consent record for each channel, voice call, SMS, WhatsApp, and email, must be checked and logged before each attempt. A borrower who consented to voice calls at origination but not to WhatsApp must not receive a WhatsApp message even if a voice call failed to connect.

Pre-call compliance checklist for AI collections systems covering DND scrubbing, registered caller ID confirmation, account-level calling

Right-Party Verification: The Gate Before Any Account Information

Once the pre-dial checks pass and the call connects, the first obligation before any account-level information is disclosed is verifying that the AI is speaking to the authorised borrower.

Standard verification logic for collections calls uses a two-factor approach: name confirmation plus one additional identifier such as date of birth, registered mobile number, or last four digits of the loan account. Both factors must be confirmed before the conversation moves past the identification stage.

This gate is mandatory under two separate frameworks simultaneously. Under RBI’s confidentiality obligations, account information must not be disclosed to an unverified party. Under the DPDP Act, disclosing personal financial data to an unauthorised individual is a data principal rights violation. A single failed gate can therefore produce exposure under both frameworks from a single call.

For AI voice agents, the verification exchange must be structured, recorded, and part of the call’s mandatory flow. If verification fails, the call must be terminated cleanly. The failed attempt must be logged with a timestamp, the verification factor that was not confirmed, and the disposition code. The account must not be dialled again on the same campaign cycle on the assumption the borrower will answer more cooperatively on the next attempt.

The Three Mandatory Disclosures, in Sequence

After right-party verification and before any collection dialogue begins, three disclosures must be completed in a defined sequence. These are hardcoded, non-skippable elements of every compliant AI collections call flow.

Regulated entity identity and loan reference: The name of the NBFC or bank on whose behalf the call is being made, along with the relevant loan reference number. The LSP’s name alone does not satisfy this requirement. The borrower must know which regulated entity is contacting them before any collection conversation begins.

Nature of the call: The purpose must be stated clearly. This is a call regarding outstanding repayment. Vague or indirect openings that lead into collection dialogue without stating the purpose first are a Fair Practices Code violation.

Grievance redressal mechanism: The borrower must be informed of how to raise a complaint, the contact channel or number, during the interaction. This disclosure is not optional when the borrower has a grievance. It is mandatory in every interaction, regardless of whether the borrower indicates a complaint.

For AI call flows, if a borrower interrupts or speaks over the disclosure sequence, the system must be designed to complete the disclosure, reattempt it, or escalate to a human agent. A borrower who talks over the identification statement does not release the AI system from the obligation to complete it.

Flowchart showing the compliant AI collections call process, including consent checks, right-party verification, identity disclosure, call purpose disclosure, and grievance redressal before collections dialogue begins

Multi-Language Compliance

India’s borrower population communicates across 22 scheduled languages and dozens of regional dialects. RBI’s Fair Practices Code requires that loan communications be in a language understood by the borrower. For AI collections calling, this means the mandatory disclosure sequence and the collection dialogue must be delivered in the borrower’s preferred language.

The compliance implication that most teams underestimate is this: script compliance does not transfer across language variants automatically. A Hindi call script that has been reviewed, approved, and cleared by the compliance team covers Hindi calls. A Marathi variant of the same script has not been compliance-approved simply because the Hindi version was. Each language variant must go through the same compliance review and approval workflow independently, because translation introduces the possibility of tone shifts, omissions, or constructions that the source language review would not have caught.

For AI systems, multi-language compliance requires:

  • Language detection or pre-set language preference applied at the account level before call initiation
  • Separate compliance-reviewed scripts for each language in the calling universe
  • Version control for every language variant so that when a regulatory change updates the mandatory disclosure language, the update is applied and re-approved across all variants
  • Post-deployment monitoring that confirms the language variant deployed for each account matches the account’s language preference record

Call Recording, Audit Artifacts, and Inspection Readiness

100% call recording under the Fair Practices Code covers every interaction type: connected calls, partial connections, automated message deliveries, unanswered attempts, and voicemails. The recording obligation does not apply only to calls where a conversation occurred.

Recordings must be stored in tamper-proof infrastructure. For regulatory defensibility, this means cryptographic integrity checks or immutable storage that prevents post-hoc modification. A recording that can be altered is not evidence.

The audit artifact for each call must be constructed automatically as a routine output of every interaction, not assembled under examination pressure. Each artifact must include:

  • Timestamp of attempt and outcome code (connected, not connected, voicemail, DND match, consent not verified)
  • Duration of connected interaction
  • Language used for the interaction
  • Verification outcome (confirmed, failed, escalated)
  • Compliance checkpoints completed: each of the three mandatory disclosures logged individually as completed or incomplete
  • Grievance lock check result at time of attempt
  • Recording file reference with integrity hash

An RBI inspection team examining AI collections operations will request call-level evidence for specific accounts. If producing that evidence requires manual extraction from multiple systems, cross-referencing spreadsheet logs, and pulling recordings from a separate archive, the audit infrastructure was built for operations, not for inspection. Those are different requirements, and a compliant platform satisfies both simultaneously.

Quote explaining that RBI inspections require call-level evidence and that compliant AI collections platforms must automatically generate inspection-ready audit artifacts for every call

Consent Architecture Across the Loan Lifecycle

Consent obtained at loan origination covers the specific purposes disclosed at that time. It does not automatically extend to all downstream collections activity.

Under the DPDP Act, each processing purpose requires its own legal basis. For collections, the loan agreement typically provides a contractual necessity basis for core recovery activity. For channels or purposes not covered by the loan agreement, explicit consent is required.

The practical implications for AI collections platforms are:

  • A borrower who consented to voice calls at origination but not to WhatsApp contact requires fresh, purpose-specific consent before a WhatsApp collection message is sent
  • Consent is revocable at any time. The AI system must process revocation in real time, removing the borrower from all active outreach on the relevant channel immediately upon the revocation signal being received, not at the next batch cycle
  • Consent records must be retained and producible. If a borrower disputes consent for a specific channel, the platform must be able to produce the record of when, how, and for what stated purpose consent was obtained

How iTuring Approaches This

The compliance infrastructure described throughout this blog, call-level audit trails, consent verification, script governance, multi-language compliance review workflows, and continuous monitoring, maps to the governance architecture iTuring provides as platform-level functionality.

Every model and outreach workflow deployed through iTuring carries immutable audit trail generation at the individual interaction level. Maker-checker approval workflows ensure that every script variant, in every language, is reviewed and documented before deployment. Consent verification runs as a pre-condition of outreach actions, not as a post-run check. Continuous monitoring tracks compliance metrics across 60 parameters post-deployment, with alerts triggered before findings reach examination stage.

For NBFC collections teams building or scaling AI infrastructure for 2026, the compliance requirements described in this blog are the engineering specification, not a policy overlay on top of it.

Book a discovery session with iTuring to see what a fully governed, RBI-compliant AI collections call architecture looks like in a live deployment.