RBI Draft Recovery Norms Effective 1 July 2026: The AI Collections Call Flow Rebuild Checklist for Indian NBFCs and Banks
The VP of Collections at a Bengaluru-headquartered consumer-lending NBFC walked into her Monday review on 26 May 2026 with one slide on the screen: 1 July, RBI go-live, call flow rebuild required. Her existing dialler runs 1.2 million outbound calls a month across DPD 0–30, 31–60 and 61–90 buckets. Roughly 8 percent of those calls fire outside the 9am–7pm window today, 3 percent are second or third calls to the same borrower on the same day, and exactly 0 percent currently open with the agent disclosing their name and the company's grievance redressal number in the first 12 seconds. Under the existing FPC interpretation she has plausible deniability. Under the draft recovery norms going live in five weeks, every one of those calls is a regulator-reportable incident. The question on her slide was not "what does the regulation say" — her policy team had already read it. The question was: what do we change in the call flow, in the dialler, in the script, and in the audit trail, by Sunday 30 June 2026, to be compliant the day after?
This post is the rebuild checklist. It is written for a Head of Collections, a CTO at an Indian lender, or an ops lead who runs the dialler stack — not for a policy team. We will walk through what the July 2026 norms actually constrain at the call-flow level (not the regulatory-text level), how each constraint maps to a specific change in the dialler, the script, and the audit trail, the five failure modes that show up in audit, the numbers that "good" looks like, and a 5-week implementation plan that lands the rebuild before 1 July. By the end you have a call flow that survives RBI scrutiny, an FPC-aware AI voice agent script, and an operations dashboard that will tell you in real time whether you are about to breach.
Why the July 2026 rebuild is different from past FPC updates
Three things make the draft recovery norms harder than any prior RBI compliance refresh on collections calls.
First, the rules move from guideline to operational hard-constraint. The 9am–9pm window from the older FPC interpretation was a script-level guideline — ops would put a banner in the supervisor dashboard and trust the team. The 8am–7pm window in the July 2026 draft is a dialler-level constraint. A call placed at 7:45pm is a regulatory breach, not a coaching opportunity. The dialler must refuse to fire outside the window. The same logic applies to the per-customer frequency cap: 2 calls or 3 calls per day is not a recommendation, it is a hard ceiling that the dialler enforces at the time of dial. Ops cannot override it because there is no override.
Second, the agent identification requirement collapses the difference between human and AI calling for compliance purposes. Under the new norms, every collections call must open with the agent's identifier, the lender's name, the loan account reference (in a privacy-safe form), and the grievance redressal number. For human telecallers this is a script change. For AI voice agents this is an architecture change: the agent must consume the borrower's account context before the call connects, must deliver the disclosure verbatim in the first 12–15 seconds in the borrower's preferred language, and must log the disclosure with audio timestamp into the audit trail. Most AI voice deployments live in India today do not open with this disclosure — they open with a friendly greeting and ask "is this Mr Sharma?" That pattern is non-compliant on 1 July.
Third, the third-party-contact restriction reshapes the escalation flow. Existing recovery practice often involves calling a guarantor, a co-signer, a reference number, or a known employer when the borrower is unreachable. Under the July norms, third-party contact is permitted only in narrowly defined circumstances and must be logged with explicit borrower consent at origination. For AI voice deployments this means the "warm-transfer to a human, who then dials the reference" pattern needs an explicit consent-check gate. Many existing deployments allow the human to dial a reference at their discretion — that has to change.
These three operational shifts — dialler-level constraints, mandatory in-call disclosure with audit timestamp, restricted third-party contact — are what require a call flow rebuild rather than a script tweak.
The unified call flow under the July 2026 norms
Here is the canonical compliant flow for a DPD 0–30 EMI reminder call in Hindi, written as a state machine an engineer can implement. The same skeleton applies to DPD 31–60 and DPD 61–90 with tone and content adjustments, and to credit card, BNPL and consumer durables EMI with minor content variation.
0. PRE-DIAL GATE - Customer in 8am-7pm local-time window? --> No: do not dial - Daily call count for this customer <= 1 (for 2-cap) or <= 2 (for 3-cap policy)? --> No: do not dial - DND scrubbed at dial-time (live NDND)? --> No: do not dial - DLT header + content template valid? --> No: do not dial - Consent purpose code = "collections"? --> No: do not dial 1. CALL OPENS (0-12 seconds) Voice agent says: "Namaste, main [agent ID] bol raha hoon [lender name] se. Aapka loan account number [last 4 digits] ke liye yeh ek payment reminder call hai. Hamare grievance redressal number par aap [number] dial kar sakte hain. Kya aap call jaari rakhna chahenge?" Audit trail logs: disclosure_timestamp_ms, language_used, agent_id 2. CONSENT GATE (12-25 seconds) - Borrower assents? --> proceed to step 3 - Borrower says "later" --> log callback request, schedule within window - Borrower opts out --> log opt-out, propagate to suppression list within 60 seconds, end call politely 3. REMINDER CONVERSATION (25-90 seconds) - State EMI amount and due date - Capture promise-to-pay (PTP): amount + date - Offer UPI Autopay setup or one-time pay link - No threats, no implication of legal action - No reference to credit score consequences unless previously disclosed - No raised voice, no harassment patterns 4. ACTION + DISPATCH (parallel to step 3) - If PTP captured: fire UPI pay link via SMS + WhatsApp template - Confirm receipt before call ends - Write disposition to LMS within 60 seconds of call end 5. CLOSE (90-120 seconds) - Repeat grievance number - Confirm call is recorded - Thank borrower; end call
The flow is shorter than a 2025-era collections call. That is the point. Under the new norms, longer calls are not better — they raise the harassment-detection risk and they push the borrower into the second or third daily call sooner. Target average handle time on a DPD 0–30 reminder is 60–90 seconds.
The five state machine guards in step 0 are the hard-constraint gates. None of them are negotiable, none of them are runtime-overridable by ops, and all of them must be enforceable by the dialler — not by the script.
The dialler-side rebuild — five hard constraints
These are the five dialler-level changes that must ship before 30 June 2026. Each one is non-negotiable; each one fails as a regulator-reportable breach if the dialler permits even a single violation.
Constraint 1: 8am–7pm local-time window enforcement at dial. The dialler's call-fire decision must reference the borrower's local time, not the campaign's launch time. For a pan-India lender this means time-zone awareness per pin code — Patna and Pune are both IST, but a campaign launched from Pune at 6:55pm IST can lawfully dial Patna at 6:55pm IST and not lawfully dial Pune at 7:05pm IST. Build the time-of-day check at dial decision, not at queue decision.
Constraint 2: per-customer per-day frequency cap. The dialler maintains a count of dial attempts per borrower per calendar day, resets at midnight local time, and refuses to fire when the cap is reached. The cap is 2 or 3 depending on the final notification — most NBFCs are sizing for 2 to be conservative. The state machine handles re-attempts inside the day (a customer who didn't pick up at 11am can be re-attempted at 3pm) but not after the cap.
Constraint 3: dial-time DND scrub. Scrub against the live NDND registry at the moment of dial, not at the moment of queue. A campaign that queued at 10am and fires at 4pm must re-check NDND immediately before dial. This is a 20-millisecond API call to your DLT partner or the NDND endpoint — it is cheap, do it every time.
Constraint 4: DLT principal-entity header and content template validation. Every campaign references a registered DLT header and a registered content template. The dialler verifies both are active and not expired before firing. Expired DLT templates fire calls that look legitimate but are technically uncompliant — this is one of the most common audit fails in practice.
Constraint 5: consent purpose-code match. The dialler checks the borrower's most recent consent record carries a purpose code that includes "collections" or the equivalent. A borrower who has opted out of promotional calls but retained transactional consent must still be reachable for EMI reminders — but the consent record must be present in the system, not assumed.
All five constraints are state-machine gates, not script reminders. They must fire on every call without exception. If any of them is implemented as an "alert the supervisor" pattern, it will breach in production.
The script-side rebuild — opening, language, escalation
Beyond the dialler constraints, three call-script changes must ship.
The opening disclosure script must be language-localised and audit-timestamped. The Hindi version is one script; the Tamil version is another; the Marathi version is a third. Every language version must contain the same five elements: agent identifier, lender name, account reference (privacy-safe — last 4 digits or masked), purpose of call, grievance redressal number. The disclosure timestamp must be logged into the audit trail with millisecond precision so a regulator audit can verify the disclosure happened in the first 15 seconds.
The mid-call language patterns must align with no-harassment guidelines. The script vocabulary excludes any reference to legal action, garnishment, credit-score impact, social embarrassment, or family contact unless the lender has documented authority and the borrower has been previously informed in writing. The AI voice agent's underlying language model must be constrained to these patterns — this is where many existing deployments fail, because the LLM occasionally generates a turn that mentions legal recourse when the borrower pushes back. The fix is constrained generation with a content filter, not a prompt instruction.
The escalation flow to a human must be explicit. When the AI cannot handle a borrower's objection (genuine dispute, hardship case, regulatory complaint), the warm-transfer to a human supervisor includes the full transcript and the consent disclosure timestamp. The human cannot then dial a third party — guarantor, reference, employer — without consulting the consent record and confirming the original loan documentation authorised that contact. This is the cleanest place to add a hard guard in the human workflow: the human's CRM workflow asks "is third-party contact authorised under the loan documentation" before any guarantor number is dialled.
What goes wrong on 1 July — the five recurring failure modes
We have audited dozens of collections deployments through 2025 and into early 2026. Five failure patterns repeat.
Failure 1: a campaign overruns the 7pm cutoff for late-pickup customers. The classic pattern is a campaign that launched at 5:30pm finishes its dial queue at 7:15pm because some customers took longer. The dialler kept firing because the cutoff was a campaign-level setting, not a per-call gate. Fix: every individual dial decision checks the borrower's local time, regardless of when the campaign launched.
Failure 2: the second-and-third-call-of-the-day rule is violated by a re-attempt logic. Many diallers re-attempt on busy or no-answer. If the campaign hits a no-answer at 10am, an 11am re-attempt, and a 3pm follow-up from a different campaign, the customer has now received three calls in a day. The fix is a per-customer counter that aggregates across campaigns, not per-campaign counters.
Failure 3: agent-ID disclosure is in the script but never spoken. AI voice agents sometimes skip script lines under timing pressure or LLM hallucination. If the disclosure is not spoken word-for-word, the audit trail's text says it was spoken but the audio recording proves it was not. The fix is constrained generation for the first 15 seconds — the agent must read the disclosure verbatim, with the audio file's first 15 seconds matching the script. This is enforced by structuring the prompt as a fixed string for the disclosure block.
Failure 4: opt-out propagation lags. A borrower opts out at 11:30am; another campaign fires at 11:55am, before the opt-out has propagated through the suppression list. The 25-minute gap is a regulator-reportable breach. Fix: the opt-out cascade hits every campaign queue within 60 seconds — event-driven, not batch-driven.
Failure 5: the LLM generates a harassment-adjacent turn. When a borrower argues with the AI ("I can't pay this month, leave me alone"), the LLM occasionally generates something like "we will have to take further action" or "this will affect your credit score" even when the prompt prohibits it. The fix is a two-stage content filter: the LLM generates the candidate turn, a smaller filter model scores it against the FPC vocabulary, and the system substitutes a safe template if the candidate fails. This catches roughly 95% of unsafe generations and the rest are caught by post-call audit.
What "good" looks like in the numbers
Five operational metrics tell you whether the rebuild is working.
| Metric | Pre-rebuild baseline | Post-rebuild target | What it proves to the regulator |
|---|---|---|---|
| Call-window violation rate | 4–8% | 0% | Hard-constraint enforcement |
| Per-customer daily cap breach | 2–4% | 0% | Aggregated frequency counter works |
| Agent-ID disclosure presence (first 15s) | 5–25% | ≥99% | Audit-grade scripted disclosure |
| Opt-out propagation time | 4–24 hours | < 60 seconds | Real-time suppression cascade |
| Harassment-adjacent language rate | 1–3% | < 0.1% | Two-stage content filter active |
You will not hit zero on every metric immediately; the goal is zero on the first three and near-zero on the last two within four weeks of go-live. Instrument these as production SLOs and page the on-call when any of them breach.
The secondary metrics worth tracking are RBI-collections-call outcome metrics that the rebuild does not directly control but which the new constraints will move: average handle time should drop from 110–150 seconds to 60–90 seconds; PTP capture rate may dip 2–4 percentage points initially as the shorter call format settles; dispute-rate may rise short-term as borrowers test the new patterns; first-attempt connection rate is unchanged. Track these as canaries — a large move in any of them means a script or flow assumption is broken.
Build, buy, or rebuild — three paths to 30 June
You have five weeks. The realistic options compress to three.
Path 1: rebuild in-house. Take your existing dialler stack, your existing AI voice platform, and your existing CRM, and add the five state-machine gates, the localised opening disclosure, the two-stage content filter, and the opt-out cascade. Feasible only if you have an internal voice AI platform team of 4 or more engineers with collections-flow expertise. Cost: 4–6 weeks of focused engineering, plus 1 week of regression testing on a synthetic-call corpus. Risk: tight on the calendar; one regression delays the whole rebuild.
Path 2: switch to or augment with a unified voice AI platform that ships FPC-aware out of the box. Caller Digital is the established pattern here — the FPC enforcement (dialler gates, disclosure scripting, content filter, opt-out cascade) is shipped on day one, no engineering required on the customer side. The lender's work narrows to script-tone calibration and CRM integration. Time to go-live: 2–3 weeks from contract signature, which fits the 5-week window with margin. See the voice AI for NBFC use case for the production pattern, and the comparison vs Bolna, Knowlarity and Ozonetel for the platform alternatives.
Path 3: hybrid — keep the dialler, swap the AI voice layer. For lenders running 5–25 million calls a month on a legacy dialler stack they cannot rip out in five weeks, the surgical move is to swap only the AI voice layer (the conversational agent, the script and the content filter) while keeping the dialler. This works when the dialler can be configured to enforce the five gates. Risk: the time-window enforcement and the per-customer counter are often dialler-side concerns, so you may still need a small dialler change.
Most Indian lenders running 5–50k DPD 0–30 calls per day will pick path 2 — the calendar is too tight for an in-house rebuild and the platform alternative collapses the risk.
Five-week implementation plan to 30 June 2026
This is the calendar a Head of Collections drops into a tracker on Monday.
Week 1 (26 May – 1 June): audit + decide. Audit the existing dialler for the five hard-constraint gates; map current campaigns to current FPC compliance; identify the gaps. Confirm path 1, 2 or 3 with the CTO. Begin vendor evaluation if path 2 or 3.
Week 2 (2–8 June): dialler-side hard constraints. Implement or configure the 8am–7pm window enforcement, the per-customer daily cap, the dial-time DND scrub, the DLT validation, and the consent purpose-code match. Test with synthetic traffic — 5,000 calls across pin codes covering all four Indian time-of-day patterns.
Week 3 (9–15 June): opening disclosure scripting. Build the localised opening disclosure scripts (Hindi, Hinglish, plus the four to six regional languages your book uses). Set up the audio-timestamp logging. Constrain the LLM generation for the first 15 seconds of the call. Test that the audio recording for the first 15 seconds matches the script verbatim across all languages.
Week 4 (16–22 June): content filter + escalation. Wire the two-stage content filter (LLM generates → filter model scores → safe-template fallback). Build the FPC vocabulary list (legal-action terms, credit-score terms, family-contact terms, harassment-adjacent terms). Re-route the escalation-to-human flow with the explicit third-party-contact consent gate.
Week 5 (23–29 June): regression + soft launch. Run the rebuilt flow on 10–15% of production traffic. Audit the first 1,000 calls against the five metrics. Fix any breaches found. Page the regulatory-affairs team on every metric above zero. On 30 June, flip the entire book to the new flow at midnight local time.
This sequence is tight but feasible. Lenders that start before Friday 30 May 2026 finish with a week of buffer. Lenders that start in June 2026 land on 1 July with a partial rebuild and visible compliance risk.
What changes after 1 July
Three forward-looking signals will shape the next 12 months of collections-flow design.
The RBI will publish enforcement guidance in Q3 2026 once the first audit cycle completes. Early signals from the policy circles suggest the enforcement focus will be on the time-window and frequency-cap metrics in the first quarter, with the agent-disclosure metric becoming the second-quarter focus. Lenders that hit zero on the first two metrics will buy time on the third.
The TRAI Third Amendment will land in the same operational space. AI/ML-based UCC detection at the ASP level will catch pacing patterns — call velocity per number, answer-seizure ratios, sub-1-second disconnect rates — that historically did not flag. A campaign that fires 200 calls per minute from one DLT header will be flagged regardless of whether the FPC constraints are satisfied. Pace conservatively from now.
The DPDP Consent Manager framework operational date of 13 November 2026 will require the consent purpose code that the dialler reads to flow from the Consent Manager, not from the lender's internal LMS. Plan the integration in Q3 2026 to avoid a Q4 scramble. See the unified India voice AI compliance stack for the full multi-regulator picture.
Bottom line
The RBI draft recovery norms effective 1 July 2026 are not a script tweak. They are an architecture change to the collections call flow. The five dialler-level hard constraints (time-window, frequency cap, dial-time DND scrub, DLT validation, consent purpose-code match), the three script-level changes (opening disclosure, no-harassment language patterns, escalation-to-human with consent gate), and the audit-trail tightening (disclosure timestamp, opt-out propagation, harassment-language filter) must ship by 30 June for the lender to be compliant on day one. The five-week implementation plan is tight but feasible if you start the rebuild this week — path 2 (unified voice AI platform with FPC pre-built) collapses the calendar risk for most Indian lenders. The lender that opens 1 July with the rebuild done has a quarter of operational stability; the lender that does not has a quarter of regulator-reportable incidents and the loss of the next audit cycle. Pick the path and start the rebuild.
For the unified multi-regulator view across DPDP, TRAI, RBI, IRDAI and Account Aggregator, see the India voice AI compliance stack. For the broader RBI Fair Practices Code context, see RBI Fair Practices Code for AI collection calls in India 2026. For the production NBFC use case, see the EMI payment reminders use case and voice AI for BFSI in India. For NBFCs in specific metros, see voice AI for Mumbai and voice AI for Delhi NCR.
Frequently Asked Questions
Tags :
