The 11 Questions RBI Will Ask Your NBFC About AI Collections — and the 3 That Disqualify Most Vendors

Summary: Indian NBFCs and banks deploying AI voice bots for collections face a compounding compliance burden: RBI's Fair Practices Code and Recovery Agents guidelines on one side, the DPDP Act 2023 on the other, and an underappreciated third layer of TRAI DND, Section 138 of the Negotiable Instruments Act, and SARFAESI when voice AI intersects with legal recovery. This post maps all six onto an 11-question examiner checklist — the questions an RBI inspection will actually ask — names the three questions where most vendors fail, and adds a 30-day remediation playbook for NBFCs whose deployments are already live. Use it as a procurement filter, a pre-audit self-check, and a board-level compliance brief.

Every NBFC collections head in India has the same quiet fear in 2026: one day a compliance letter lands on the desk, the letter references an AI voice bot the team deployed last year, and nobody can cleanly produce the documentation to prove the deployment was compliant. The technology worked. The recoveries went up. The vendor looked polished in the demo. And yet — no DPIA, no outsourcing contract mapped to RBI guidelines, no audit trail of which borrower said what, no record of whose opt-out request was honoured and whose was not, and no clear answer to the newest and hardest question of all: under which of the six overlapping rulebooks does this deployment actually sit?

This is not a hypothetical. It is the single biggest reason AI voice bot projects get shelved inside Indian banks and NBFCs right now, and it almost always happens after the deployment is already live and generating recoveries. The compliance gap does not kill the pilot. It kills the scale-up. And the gap is widening, not narrowing, as DPDP operational rules, RBI's FREE-AI framework, and TRAI's 2024 amendments to commercial-communication consent all layer new obligations on top of the existing ones.

The fix is to treat compliance as a procurement filter, not a cleanup task. Below is the 11-question checklist we have seen real RBI and internal audit teams use to evaluate AI voice bot deployments in Indian lending, mapped onto the full regulatory stack. The three starred questions are the ones most vendors cannot answer. Use this both to evaluate vendors and to pre-audit a deployment you already have in production.

The six laws that govern AI voice collections in India

Before the checklist, a quick orientation. An AI voice bot deployment in Indian collections does not sit inside a single rulebook. It sits inside six overlapping ones, and an audit conversation can pivot between any of them without warning. A deployment that is compliant under one but silent on another is not compliant — it is partially defensible, which is worse, because it creates an illusion of readiness.

1. RBI's Fair Practices Code for Lenders (FPC). The foundation document. Sets the standards for how borrowers must be treated — tone, language, call windows, non-intimidation, grievance redressal, harassment prohibitions. Applies to automated calls as much as human calls. RBI examiners do not distinguish between a human recovery agent using abusive language and a voice bot generating intimidatory Hindi — both are failures of the same control.

2. RBI Guidelines on Recovery Agents and Code of Conduct. A layer above FPC, these apply to anyone contacting borrowers on behalf of the lender, including outsourced and automated systems. Require training records, background verification, and identifiable agent identity on every call. For AI voice bots, the "agent identity" question is non-trivial: the disclosure that a borrower is speaking to an AI agent must be explicit, in the borrower's language, and at the start of every call. Ambiguity here is a finding.

3. RBI Outsourcing Guidelines for Financial Services. Govern the vendor relationship itself — due diligence, contract terms, monitoring, business continuity, audit rights for both the lender and RBI, exit clauses, and materiality classification. Most AI voice bot engagements qualify as material outsourcing once they scale past a pilot, which triggers board-level reporting obligations and annual risk reviews. Vendors who pitch themselves as "just a SaaS tool" to sidestep these rules are setting the NBFC up for an audit finding.

4. RBI's Digital Lending Guidelines (September 2022, revised 2023 and 2025), and the FREE-AI framework. Expand outsourcing and customer-interaction rules specifically to digital lending touchpoints. The FREE-AI framework, released by RBI in 2024, formally brings AI systems deployed by regulated entities under supervisory review — including AI used for customer interaction, collections, underwriting, and fraud monitoring. Every voice AI deployment in a regulated NBFC now has to answer FREE-AI questions about explainability, human-in-the-loop, and recourse.

5. The Digital Personal Data Protection Act 2023 (DPDP Act). Governs the data layer — consent, purpose limitation, residency, retention, erasure, and breach notification for borrower personal data. DPDP creates a parallel compliance track that is not owned by RBI but is every bit as enforceable, and financial data is among the most sensitive categories in scope. The key operational sections for collections voice AI are:

• Section 6 — consent must be free, specific, informed, unconditional and capable of being withdrawn. Bundled consent in a loan agreement does not qualify for a subsequent AI call recording.
• Section 7 — data principal rights: access, correction, erasure, grievance redressal, nomination.
• Section 8 — obligations of the Data Fiduciary (the NBFC, not the vendor) for accuracy, security safeguards, and breach notification.
• Section 10 — additional obligations for Significant Data Fiduciaries, which most scaled NBFCs will qualify as once DPDP rules are notified.
• Section 11 — the right to erasure, with defined timelines once operational rules are released.

6. TRAI Telecom Commercial Communications Customer Preference Regulations (TCCCPR), DLT registration, and Section 138 of the Negotiable Instruments Act and SARFAESI Act for legal recovery. The most commonly-missed layer. TRAI rules govern commercial voice traffic on Indian telecom infrastructure and require DLT (Distributed Ledger Technology) registration of call templates for automated outreach. Section 138 and SARFAESI become relevant the moment voice AI is used in a pre-legal notice workflow — at which point the call recording becomes potential legal evidence and must meet an evidentiary standard, not just a marketing one. We cover both in dedicated sections below, because they are where most NBFC deployments have unexamined exposure.

An AI voice bot deployment that is compliant under one of these but silent on the others is not compliant. The full stack matters, and RBI examiners ask questions that deliberately cross the boundaries. The checklist below reflects that.

The 11 questions, in the order an examiner asks them

These are not arranged by topic. They are arranged in the sequence a real audit conversation follows — from scope, to data, to controls, to incidents, to vendor management. If you can answer them in order without having to dig for documents, the deployment is ready for scrutiny.

1. What is the full scope of borrower interactions handled by the AI voice bot?

Examiners start here to establish the blast radius. They want to know: which call types, which DPD buckets, which languages, which regions, whether the bot initiates calls or only receives them, and whether any part of the scope has crept since the original board approval. The answer should be a one-page scope document, dated, signed by the collections head and the CISO, version-controlled, and cross-referenced to the board minutes that approved it. No scope document, no audit-ready deployment. Scope creep between the board-approved scope and the production reality is the single most common audit finding we see.

2. Where is borrower personal data stored, and who has access to it?

This is the first disqualifier question. The DPDP Act establishes clear expectations on data residency for personal data generated in India, and financial data — including borrower names, loan numbers, EMI amounts, phone numbers, and call recordings — is among the least forgiving categories. A vendor storing call recordings in Singapore, Frankfurt, or us-east-1 is a vendor whose deployment will have to be migrated under time pressure the moment an examiner asks this question. And the migration is not trivial: it involves physical data transfer, vendor re-contracting, DPIA re-execution, and potentially a disclosure to borrowers whose data crossed the border.

The expected answer: all call recordings, transcripts, embeddings, derived features, training data, and any exports reside in Indian data centres; access is controlled by role with named individuals, not group accounts; every access event is logged with immutable timestamps; and a data flow diagram — not a sales slide, an actual architecture diagram showing ingress and egress — is available on demand. Ask the vendor for this diagram before you sign, not after.

3. How is borrower consent captured for call recording and data processing?

DPDP Section 6 requires explicit, informed, purpose-specific consent for processing personal data, and call recording is a separate processing activity that requires its own consent. The consent must be captured inside the call, in the borrower's language, as a clear question the borrower answers yes or no to. Buried disclaimers in the loan agreement do not satisfy this test — nor does a click-wrap on the loan app that predates the call by 18 months.

The expected answer: a structured consent field logged against each call, with timestamp, borrower ID, language used, the exact wording of the consent ask, the borrower's verbal response, and the workflow path taken if consent was refused. If the vendor cannot produce an example consent log and a matching audio snippet on request, they do not have this control.

4. How are RBI-mandated call windows enforced, and what happens when they are violated?

RBI's 08:00–19:00 local-time window is not a guideline; it is a control. The expected answer is a hard-coded policy in the voice AI platform that prevents outbound dialling outside the window, with campaign-manager overrides blocked by role and all override attempts logged. Violations should be impossible by design, not merely discouraged by policy.

Ask the vendor what happens if a campaign manager in the UI tries to launch a campaign at 19:30, or sets a schedule that would cause dials to land in a timezone-ambiguous region at 06:45 IST. If the answer is "the system warns the user," the control is not sufficient. The answer should be "the system blocks the dial and logs the attempt as a policy violation event that escalates to the compliance dashboard."

5. How are borrower opt-out requests captured and honoured?

Opt-outs are where most deployments leak. A borrower says "do not call me again" mid-call. The bot acknowledges. The call ends. And then — because the opt-out is captured as a note in a call log rather than as a structured field in the CRM that the next dialler consults — the same borrower gets called two days later by a different campaign, which is a textbook FPC violation and potentially a harassment finding.

The expected answer: opt-outs are detected by the bot in real time across multiple linguistic variants ("do not call," "mat karo call," "band karo," "stop calling," "remove my number"), written to a structured opt-out field at the borrower level, propagated to the dialler within minutes, and honoured across all future campaigns — including campaigns run by different collections sub-teams — until a structured re-consent event. Ask the vendor to demonstrate the end-to-end flow from in-call utterance to blocked future dial.

6. What is the grievance and escalation path when a borrower objects to the automated call?

RBI's Fair Practices Code requires a clear grievance mechanism for every borrower interaction, and DPDP Section 13 adds a parallel grievance channel for data-related complaints. For AI voice bot deployments, this means every call must give the borrower a way to reach a human, every grievance must be logged, and every resolution must be trackable back to the original call.

The expected answer: in-call warm transfer to a human with full context preservation, out-of-call grievance number announced at the start of every recording, a separate DPDP grievance channel for data-related objections, and a unified grievance register that examiners can audit quarterly. No grievance register, no deployment.

7. How is language and tone governed to ensure non-intimidation and cultural appropriateness?

This is where the intersection of RBI rules and voice AI gets interesting. The Fair Practices Code prohibits intimidatory language. Voice AI systems can generate intimidatory language unintentionally — either through a badly phrased prompt, a TTS voice that sounds threatening in Hindi even if the script is neutral in English, or a regional code-switching failure that lands as sarcasm to a Patna borrower even though it was polite in Delhi Hindi.

The expected answer: the vendor can show prompt review logs, language testing records, a process for reviewing random call samples with native speakers across each region where the bot runs, and a harassment-detection model that flags calls exceeding defined tone thresholds for human review. No native-speaker review, no non-intimidation control.

8. How can a borrower's data be erased on request, and what is the SLA?

This is the second disqualifier question. DPDP Section 11 establishes a borrower right to erasure, and for an AI voice bot deployment this means the vendor must be able to delete every trace of a specific borrower — call recordings, transcripts, derived features, training data, vector embeddings, model caches, dashboard views, exported reports, backup snapshots — end to end, within a defined SLA.

Most voice AI vendors cannot do this. They can delete the recording, but the transcript lives in an analytics pipeline. They can delete the transcript, but the derived features live in a vector store used for conversation memory. They can delete the vector, but the call appears on a dashboard view that was exported last week and sits in someone's email. They can delete the export, but a backup from 30 days ago still contains the data, and the backup lifecycle is owned by a third-party cloud provider.

The expected answer: a single erasure API that deletes every artefact across every system, with a documented 7–30 day SLA depending on artefact class, an audit log of every erasure event, and a backup purge cycle mapped to the erasure SLA so that data cannot resurface from restore. Ask for a live demonstration before you sign, using a test borrower, and verify by attempting to retrieve the data afterwards.

9. What is the full, timestamped audit trail available for a specific borrower on demand?

This is the third disqualifier question. RBI examiners — and internal audit teams — will ask for a complete history of a specific borrower: every call, every consent, every opt-out, every data access event, every grievance, every campaign the borrower was included in, every exclusion, with timestamps that are tamper-evident and cryptographically verifiable. The deployment must be able to produce this as a single report within hours, not days.

Most vendors cannot produce this cleanly because their data is fragmented across three or four systems with no common identifier — a call ID in the telephony layer, a conversation ID in the AI layer, a customer ID in the CRM, and a transaction ID in the core banking system, none of them joined. The expected answer: a single audit report, generated on demand from a unified borrower timeline, with tamper-evident timestamps, and a data model that lets the compliance team reconstruct any borrower's complete interaction history from a single query. If the vendor says "we can put that together for you in a week," they have failed the question.

10. What is the outsourcing contract, and how is it mapped to RBI's outsourcing guidelines?

An AI voice bot vendor relationship is an outsourcing arrangement under RBI rules, and once it scales past a pilot it is almost always material outsourcing — which triggers board-level reporting obligations, annual risk reviews, and named incident escalation to the RBI itself under defined circumstances. The contract must meet specific standards: due diligence records, clear service definitions, monitoring rights, business continuity plans, tested disaster recovery, exit clauses with data-return SLAs, and audit rights for the lender, the lender's internal audit, and RBI itself.

The expected answer: a signed contract that cross-references each relevant clause of RBI's outsourcing guidelines, with the vendor's specific obligations mapped to each. This is a document your compliance and legal teams own, but it should be ready before the deployment, not after, and it should be reviewed annually. Ask the vendor for their standard template — if they do not have one pre-mapped to RBI clauses, they are not ready for Indian NBFC deployments.

11. How are material incidents reported, and what is the notification SLA?

DPDP Section 8(6) requires breach notification within defined timelines once operational rules are released, and RBI requires material outsourcing incidents to be reported to the board and potentially to the regulator. The deployment must have a defined incident classification (what constitutes a P0 vs. P1 vs. P2), a named incident response owner on the vendor side, a written runbook, and a documented notification SLA that is tested through tabletop exercises at least annually.

The expected answer: a written incident response plan, tested annually, with escalation paths to the lender's CISO within hours of detection; a pre-agreed communication template for borrower notification if one is triggered; and a joint lender-vendor war-room protocol for material incidents. No incident plan, no production-ready deployment.

The TRAI DND and DLT reality check most NBFCs forget

Every NBFC collections head knows about RBI rules. Most of them also know about DPDP. The layer that consistently gets missed is TRAI's Telecom Commercial Communications Customer Preference Regulations (TCCCPR) and the associated DLT (Distributed Ledger Technology) registration requirements, which govern commercial voice traffic on Indian telecom infrastructure.

The practical obligations for a voice AI deployment:

• DLT registration of call templates. Any automated outbound commercial voice content — which includes EMI reminders and collection calls — should be registered on the DLT platform operated by the telecom service providers. Unregistered automated content risks being filtered as UCC (Unsolicited Commercial Communication) and flagged to TRAI. NBFCs whose voice AI vendors have not registered their templates on the DLT are exposed to both regulatory action and reduced call deliverability.
• DND scrubbing against the NCPR. Borrowers registered on the National Customer Preference Register (NCPR) for commercial calls must be scrubbed from any outbound voice campaign that does not have a legitimate existing relationship exemption. Collections on an existing loan qualifies as a relationship exemption, but the exemption is narrower than most NBFCs assume and does not extend to cross-sell or renewal pitches delivered inside a collection call.
• Sender ID and caller ID integrity. TRAI rules prohibit caller ID spoofing and require that outbound commercial calls display a verified caller line identification (CLI). Voice AI platforms that rotate CLIs for answer-rate optimisation without proper registration are creating a TRAI exposure on top of the RBI one.

Ask your vendor four questions to close this gap: are our call templates registered on DLT? how do you scrub against NCPR before every campaign? what CLIs are we dialling from, and are they registered to us or to you? what is our compliance posture if TRAI asks for a log of every call we placed last month? If any answer is "we do not own that layer — your telephony provider does," you have a joint-responsibility gap that will become a finding.

Section 138 NI Act and SARFAESI: when voice AI becomes part of legal recovery

The most underestimated compliance exposure in AI voice bot collections is the point at which a call becomes part of a legal recovery workflow — and the recording becomes legal evidence rather than just an operational artefact. This happens at two trigger points most NBFCs have not mapped.

Section 138 of the Negotiable Instruments Act governs cheque bounce proceedings, and the pre-legal notice is often delivered via a call before the formal written notice. If that pre-legal call was placed by an AI voice bot, every aspect of the call — the consent, the recording quality, the timestamp integrity, the chain of custody from the vendor platform to the lender's legal team, the language in which the notice was delivered, and the borrower's response — becomes a potential evidentiary issue if the matter proceeds to a Section 138 complaint. A call recording that cannot be authenticated with a tamper-evident timestamp, or a transcript that cannot be reconciled to the audio, is weaker evidence than a human recovery agent's contemporaneous notes.

SARFAESI Act proceedings for secured loans trigger a different set of notices, but the same evidentiary principle applies. Any voice bot interaction in the window between default and SARFAESI Section 13(2) notice is part of the pre-enforcement record and may be cited by the borrower in a Debt Recovery Tribunal or a high-court writ challenging the enforcement action. NBFCs have been surprised in DRT proceedings by the discovery that their voice AI vendor retained recordings for 90 days and then overwrote them — meaning the record of what the borrower was told at DPD 75 no longer existed when it was needed at DPD 180.

The operational fix is to build a legal hold workflow into the voice AI deployment from day one. When a borrower crosses a defined DPD threshold — typically 90 or 120 days depending on loan class — all voice interactions with that borrower should automatically switch to a long-retention legal-hold bucket with tamper-evident hashing, extended retention (typically 7 years), and a documented chain-of-custody to the lender's legal team. Ask your vendor whether this workflow exists. If they do not understand the question, they are not ready for legal-recovery-adjacent deployments.

The three disqualifiers, summarised

If a vendor cannot answer questions 2, 8, and 9 comfortably — data residency, programmatic erasure, and complete audit trail on demand — they are not deployable for Indian NBFC or bank collections under current regulatory expectations. Not because the other questions do not matter, but because these three are where your legal exposure concentrates and where most vendors have structural gaps.

Use these three as the first filter in any voice AI RFP. Send them in writing. Ask for evidence, not assurances. The vendors who can produce it immediately are the ones worth investing demo time on; the rest are consuming your evaluation cycle.

The pre-audit self-check for existing deployments

If you already have an AI voice bot in production, run this 90-minute self-check before your next internal audit cycle. Fifteen checkpoints, grouped by theme:

Scope and governance

• Can you produce the board-approved scope document, dated and version-controlled, in under 10 minutes?
• Does the production scope match the board-approved scope? List every instance of creep.
• Can you name the grievance owner and produce the grievance register for the last quarter?

Data and consent

• Can you produce a full, timestamped borrower timeline for a specific borrower within two hours?
• Can your vendor honour an erasure request end-to-end within 30 days, backups included?
• Can you demonstrate that every call in the last 12 months was captured with explicit in-call consent?
• Where do your call recordings physically reside? Name the data centre.

Operational controls

• Can you show a call-window policy that is technically enforced, not just documented?
• Can you demonstrate the end-to-end opt-out flow from in-call utterance to blocked future dial?
• Have your call templates been registered on the DLT platform, and is the evidence retrievable?
• Do you scrub against NCPR before every outbound campaign, and what is the log?

Legal and incident

• Do voice interactions with borrowers beyond 90 DPD automatically enter a legal-hold bucket?
• When was the last tabletop exercise of your incident response runbook?
• Is your outsourcing contract mapped clause-by-clause to RBI's guidelines, and was it reviewed in the last 12 months?
• If a TRAI, RBI, or DPDP Board information request landed tomorrow, what is your SLA to produce the requested evidence?

If any answer is "we would need to check with the vendor," the control is not operational. Fix it before the examiner — or your own internal audit — gets to it. The gap between "we think we are compliant" and "we can prove we are compliant" is exactly the gap a regulator will land in.

The 30-day remediation playbook

If the self-check surfaced more than three gaps, you are not alone — most NBFC voice AI deployments in India today would fail between three and six of the fifteen checkpoints above. The remediation window is short but not impossible. Here is the 30-day playbook we have seen work:

Days 1–5: Stabilise. Pull the board-approved scope document. Compare it to the production scope. Write a one-page addendum covering every instance of creep, signed by the collections head and the CISO. Confirm data residency with the vendor in writing, not by email — an addendum to the contract. If data is outside India, begin a migration plan immediately and narrow the production scope to read-only until migration completes.

Days 6–12: Close the disqualifier gaps. Demand a live erasure demo from the vendor using a test borrower. Demand a sample unified audit report for a real borrower, generated on demand. If either fails, stop the outbound campaigns on high-DPD buckets until the controls are fixed — the exposure on an untracked call to a legal-recovery-adjacent borrower is not worth the recovery it generates.

Days 13–20: Fix the operational controls. Register every call template on DLT if not already done. Run an NCPR scrub audit on the last 90 days of outbound campaigns. Test the call-window enforcement with a deliberate out-of-window campaign attempt and verify it is blocked, not just warned. Review a random sample of 50 calls with a native speaker in each active region for tone and non-intimidation.

Days 21–26: Refresh the contracts and incident plan. Review the outsourcing contract against RBI's guidelines. Add missing clauses. Run a one-hour tabletop exercise of the incident response runbook with the vendor's named incident owner on the line.

Days 27–30: Brief the board. Present a one-page remediation summary to the audit committee: what was found, what was fixed, what is still outstanding, and what the residual risk is. This is not optional. The board owns material outsourcing risk under RBI rules, and the documentation of the remediation is itself an audit artefact that strengthens the deployment's standing in any subsequent examination.

Thirty days is enough to take a deployment from "would fail an audit" to "has a defensible paper trail of active remediation" — which is not the same as fully compliant, but is materially better than the position most NBFCs are in today.

Where Caller Digital fits

We built Caller Digital's voice AI platform to be deployable in Indian lending without a compliance cleanup after the fact. That means Indian data residency by default, a single erasure API that propagates to every artefact including backups, unified borrower timelines for audit, call-window enforcement as a hard control, structured consent and opt-out logging tied to every call, DLT template registration as part of onboarding, automatic legal-hold bucketing for borrowers past 90 DPD, and an incident response runbook we tabletop-test with every NBFC customer within the first 30 days of deployment.

We also maintain a DPIA template, an outsourcing contract template mapped to RBI's guidelines clause by clause, a grievance-register schema that our NBFC customers plug into their existing compliance workflows, and a DPDP readiness checklist our compliance advisors update as operational rules are notified.

We are not a legal advisory firm, and nothing in this post is legal advice — your compliance and legal teams remain the final authority on what is and is not acceptable for your specific deployment. But we are the vendor most likely to answer all 11 questions with evidence on the first call, which is the only thing that matters when procurement asks.

If you are evaluating voice AI for collections and want to pressure-test your vendor shortlist against this checklist, the fastest path is to book a free custom demo. We will walk through each of the 11 questions live, show the evidence, and share the template documents your compliance team will need.

For deeper reading on BFSI economics and deployment strategy, see our DPD-bucket playbook for NBFC collections, Voice AI vs IVR for Indian Banks: A ₹47 Lakh/Year Decision, and Why ₹3/Minute Voice AI Is More Expensive Than ₹9/Minute. For a quick ROI read, plug your own numbers into the EMI Collections ROI Calculator.

The bottom line

Compliance is not a slide at the end of a vendor deck. It is a procurement filter at the start of an RFP, a stack of six laws rather than one, and a 30-day remediation plan rather than a quarterly review. An Indian NBFC or bank that treats it as anything less will, eventually, find themselves reverse-engineering an audit-ready deployment under time pressure from a regulator — and that is the most expensive kind of migration in Indian financial services. Run the 11 questions. Start with the three that disqualify. Layer on the TRAI DND, Section 138, and SARFAESI questions most vendors have never heard. The vendors who survive the filter are the ones who were already building for the regulator from day one.