Selling cover inside your own checkout? The eight steps, who is allowed to sell, and what changes on 1 January 2027: Embedded Insurance: How to Build It →
Building cash and treasury software for small businesses? The eight steps, the four lines that turn it into a regulated business, and the IRN that makes a receivable real: SME Treasury: How to Build It →
Contacting borrowers who have missed a payment? The eight steps, the contact rules as code, and what the August 2026 Directions change from 1 January 2027: Collections and Recovery: How to Build It →
Every tool for this module, how to use each one, what it costs, the best combinations and three recommended builds: Customer Ops Build Sheet →
What customer operations covers
Three jobs that get lumped together and should not be:
- Support — answering questions. Mostly repetitive, high volume, low stakes individually.
- Complaints — a customer says something went wrong. Regulated, with defined timelines and escalation paths.
- Collections — asking for money that is owed. The most heavily regulated conversation in financial services.
The temptation is to build one AI agent for all three. Do not. The constraints differ so sharply that a system designed for the first will breach the rules governing the third.
The principle that governs everything here
In 2024 a tribunal ordered Air Canada to honour a fare its chatbot had invented. The airline argued the chatbot was, in effect, a separate entity responsible for its own statements. The tribunal rejected that outright.
The award was small — a few hundred dollars. The principle is not.
When your AI tells a customer something, your organisation said it. Legally, financially, reputationally. There is no meaningful distinction between a bot inventing a policy and an employee inventing one, except that the bot does it at scale and with more confidence.
The useful framing is not hallucination — it is authority. The chatbot did not invent a fact in a vacuum. It spoke inside an official channel, in a trusted brand voice, about a real policy affecting a real financial decision. That is what made it binding.
What AI can and cannot do here
| Task | How well AI does it |
|---|---|
| Answer a documented factual question | Very well, if the answer is retrieved rather than generated from memory. |
| Look up account state and explain it | Very well. Deterministic data, natural language presentation. |
| Summarise a long conversation for a human agent | Very well. Among the highest-value, lowest-risk uses. |
| Draft a reply for an agent to send | Well. Human chooses before sending. |
| Interpret a policy edge case | Badly, and dangerously. It will produce a plausible policy that does not exist. |
| Handle a distressed or angry customer | Poorly. In financial services this is a quarter to a third of contacts. |
| Negotiate a repayment settlement | It should not. Regulated speech with legal consequences. |
| Decide a complaint outcome | No. Regulated decision with defined timelines and an ombudsman behind it. |
Published figures put chatbot hallucination rates between 3% and 27% even in controlled environments. For financial services the working threshold for production is below 0.1% — a fabricated answer about a fee, a rate or an account status is a regulatory incident, not a bad customer experience. That gap is why grounding architecture matters more than model choice.
The structural fact: collections speech is regulated speech
Most industries treat a collections message as a marketing problem. In Indian financial services it is a compliance problem with a recording obligation attached.
The RBI responsible business conduct directions on recovery, effective 1 July 2026, set out what may be said, when, by whom, and what must be kept.
Two provisions reshape system design immediately:
- Contact is permitted only between 08:00 and 19:00, unless the borrower has expressly authorised otherwise — and this explicitly covers digital contact. An automated SMS despatched at 22:00 is a reportable violation, not a scheduling inconvenience.
- Recovery calls and visits must be recorded and the recordings preserved for six months, or until the conclusion of any related litigation, whichever is later.
So a generative model on the collections path is, functionally, the regulated entity speaking ’ under a clock, on the record, with the lender vicariously liable for what it says.
Architecture: grounding is infrastructure, not prompt engineering
The model will always be capable of hallucinating. What decides whether hallucinations reach customers is the system around it.
CUSTOMER MESSAGE
|
1. INTENT + RISK CLASSIFY deterministic classifier, not the LLM
| -> high-risk intents never reach generation
|
2. HARD ROUTE complaint | fraud | bereavement | hardship
| | legal threat | vulnerability signal
| -> straight to a human. No generation at all.
|
3. RETRIEVE approved knowledge base + live account state
| -> if retrieval returns nothing above a
| relevance floor, DO NOT GENERATE. Escalate.
|
4. GENERATE (constrained) answer ONLY from retrieved passages,
| with citations to source documents
|
5. RUNTIME VALIDATION post-generation checks BEFORE sending:
| - every factual claim traceable to a source?
| - any number not present in retrieval?
| - any prohibited commitment? (refunds, rates,
| waivers, timelines, legal or financial advice)
| - confidence above floor?
| -> any failure = escalate, do not send
|
6. SEND or ESCALATE
|
7. LOG message, retrieved sources, generated text,
validation result, action taken
The Air Canada question was not "did they use a good model".
It was "did they take reasonable steps to ensure the statements
were accurate". Steps 3 and 5 are those steps.The rule that prevents most incidents
If retrieval returns nothing above a relevance floor, do not generate. Escalate instead.
This feels wasteful and it is the single most effective control available. Almost every fabricated-policy incident follows the same shape: the customer asked something the knowledge base did not cover, and the model answered anyway because answering is what it does.
import re
PROHIBITED_COMMITMENTS = [
r"\bwe (?:will|can) (?:waive|refund|cancel|reverse)\b",
r"\byou (?:will|are) (?:definitely |certainly )?(?:approved|eligible|entitled)\b",
r"\bguarantee(?:d)?\b",
r"\bwithin \d+ (?:hours?|days?)\b", # SLA the agent cannot commit to
r"\byour (?:rate|interest|fee) (?:will|is) (?:be )?\d",
r"\byou should (?:invest|buy|sell|switch)\b", # financial advice
]
def validate_response(text, retrieved_passages, min_conf, confidence):
"""Returns (ok, failures). Any failure means escalate, never send.
This runs AFTER generation and BEFORE the customer sees anything."""
failures = []
if confidence < min_conf:
failures.append("below_confidence_floor")
if not retrieved_passages:
failures.append("no_grounding_available")
# Every number in the reply must exist in the retrieved sources.
# This single check catches the most damaging class of hallucination:
# invented fees, rates, balances and deadlines.
corpus = " ".join(p["text"] for p in retrieved_passages)
corpus_nums = set(re.findall(r"\d[\d,]*(?:\.\d+)?", corpus))
reply_nums = set(re.findall(r"\d[\d,]*(?:\.\d+)?", text))
ungrounded = {n for n in reply_nums - corpus_nums if len(n) > 1}
if ungrounded:
failures.append(f"ungrounded_numbers:{sorted(ungrounded)}")
for pat in PROHIBITED_COMMITMENTS:
if re.search(pat, text, re.I):
failures.append(f"prohibited_commitment:{pat}")
# A reply with no citation is a reply with no provenance
if "[source:" not in text:
failures.append("no_citation")
return (len(failures) == 0), failures
# Design note: this is deliberately conservative and will over-escalate
# at first. That is the correct direction to be wrong in. Loosen it from
# measured data, never from impatience.What containment actually looks like
Vendors quote containment rates. The published reality is more useful.
Contact volume follows a rough power law: about 40% straightforward, 40% moderate, 20% genuinely hard. Realistic trajectories run roughly 40–50% containment in an initial 4–8 week pilot, 55–65% after 8–16 weeks of escalation analysis and knowledge base improvement, with production stability at four to six months. Most teams need six to nine months to reach a steady state.
Pushing containment beyond about 70–75% without human review tends to increase complaint volume as false resolutions compound. And in high-churn sectors including financial services, the share of contacts involving frustration, relationship damage or emotional labour runs closer to 25–35% than the 10–15% quoted for general support.
Containment is measured dishonestly almost everywhere. Most teams count "no escalation" and never track "customer recontacted about the same issue". A conversation the bot closed and the customer reopened tomorrow is not contained — it is deferred. Measure both or your containment number is inflated.
Escalation design
Escalation is not a failure path. It is the product.
Intents that must never reach a generative model
| Trigger | Why |
|---|---|
| Complaint (explicit or implied) | Regulated process with defined acknowledgement and resolution clocks |
| Fraud or unauthorised transaction | Time-critical; wrong advice compounds loss |
| Bereavement | The Air Canada fact pattern exactly |
| Financial hardship | Triggers forbearance obligations and stops collections |
| Legal threat or regulator mention | Anything said becomes evidence |
| Vulnerability signals | Illness, mental distress, coercion, capacity concerns |
| Any request to waive, refund or vary terms | A commitment the agent has no authority to make |
Handoff quality decides customer experience
A bad handoff is worse than no bot. The customer explains the problem, gets told it will be transferred, and explains it again from the start to a human who can see nothing.
What a working handoff carries: the full conversation, an AI-written summary of what was tried, the account context already retrieved, the specific escalation reason, and the customer sentiment. The human opens the case already informed.
This is also the highest-value AI use in the whole module and it carries almost no risk, because nothing generated is shown to the customer. Summarising for the agent rather than answering for the customer is where most teams should start.
Collections under the 2026 conduct rules
Indian recovery conduct became substantially more prescriptive with effect from 1 July 2026. The provisions that change system design:
| Requirement | Design consequence |
|---|---|
| Contact only 08:00–19:00, including digital | A scheduler gate on every outbound channel. Timezone-correct, holiday-aware. |
| Calls and visits recorded, retained 6 months or until related litigation concludes | Recording storage, retention policy, and retrieval by account |
| Agent certification (IIBF) and identification disclosure | Agent identity captured on every contact record |
| No visits without prior consent | Consent state as a first-class field, not a note |
| Ban on intimidation, public shaming, persistent calling | Frequency caps and language vetting on generated and templated text alike |
| Prohibition on remotely disabling financed devices | Removes a control some lenders had built |
| Grievance acknowledged in 24h, resolved in 30 days; recovery suspended while pending | A complaint flag must halt the collections pipeline for that account automatically |
| Vicarious liability — the lender answers for the agent | Outsourcing collections does not outsource the obligation |
from datetime import datetime, time
from zoneinfo import ZoneInfo
IST = ZoneInfo("Asia/Kolkata")
WINDOW_START, WINDOW_END = time(8, 0), time(19, 0)
BLOCKED_LANGUAGE = [
"legal action will be taken", "we will inform your", "your family",
"your employer", "your contacts", "police", "arrest", "defaulter list",
"publish", "shame", "consequences you cannot",
]
def may_contact(borrower, now=None, channel="sms"):
"""Applies BEFORE any message is generated or despatched.
The window covers call, SMS, WhatsApp, push and visit alike - the
directions explicitly include digital contact."""
now = now or datetime.now(IST)
reasons = []
# 1. Time window - an automated SMS at 22:00 is a reportable violation
if not (WINDOW_START <= now.timetz().replace(tzinfo=None) <= WINDOW_END):
if not borrower.get("express_consent_outside_hours"):
reasons.append("outside_permitted_window")
# 2. Grievance pending -> recovery contact suspended for that account
if borrower.get("open_recovery_complaint"):
reasons.append("complaint_pending_recovery_suspended")
# 3. Hardship, dispute or bereavement flags stop automated contact
for flag in ("hardship_declared", "amount_disputed", "bereavement",
"vulnerability_flag"):
if borrower.get(flag):
reasons.append(f"blocked:{flag}")
# 4. Frequency - persistent contact is itself prohibited conduct
if borrower.get("contacts_today", 0) >= 1:
reasons.append("daily_contact_limit_reached")
if borrower.get("contacts_this_week", 0) >= 3:
reasons.append("weekly_contact_limit_reached")
# 5. Visits require prior consent
if channel == "visit" and not borrower.get("visit_consent"):
reasons.append("visit_without_consent")
return (len(reasons) == 0), reasons
def vet_message(text):
"""Second gate: what the message SAYS. Runs on generated and
templated content alike."""
hits = [p for p in BLOCKED_LANGUAGE if p in text.lower()]
return (len(hits) == 0), hitsThe contact-suspension-on-complaint rule deserves particular attention. If a borrower raises a recovery grievance and your automated dunning continues because the flag lives in a different system, you have compounded the original complaint into a regulatory one. Wire the flag into the despatch gate, not into a dashboard.
The registry
Support and agent platforms
Verified May 2026Grounding, guardrails and evaluation
Verified May 2026Compliance expectations to check in procurement
Verified May 2026Registry reflects what was publicly visible in May 2026. Liability allocation in AI CX contracts has been moving toward the deploying firm rather than the vendor — read the indemnity and limitation clauses specifically, and do not assume the vendor carries the regulatory risk.
A prompt for designing your escalation policy
You are a customer operations lead in a regulated Indian lender who
has been through a conduct examination.
My situation:
- Product: [e.g. personal loans / neobank / payments app]
- Contact volume: [per month, and channel mix]
- Current support: [describe, or "none"]
- Do I run collections in-house or through agencies: [describe]
- Languages I must support: [list]
Give me:
1. An intent taxonomy split into three tiers: safe for AI to answer,
AI-drafts-human-sends, and human-only. Be specific to my product.
2. The hard-route triggers that must bypass generation entirely,
including the phrasing customers actually use for each.
3. A runtime validation checklist to run on every generated reply
before it is sent.
4. A realistic containment trajectory for months 1, 3, 6 and 12 for
MY contact mix - and what would make those numbers dishonest.
5. The collections contact rules I must enforce in code, including
time windows, frequency caps, consent state and complaint-pending
suspension.
6. What I must record and retain, and for how long.
7. The three ways this design will fail a conduct examination even
while operating exactly as intended.
Be specific. Where I should verify current RBI requirements with a
qualified adviser, say so rather than stating them as settled.Hallucination prevention is an infrastructure problem
The distinction that matters: a fabricated policy is not a model limitation you tolerate, it is a governance gap you closed or did not.
The Air Canada tribunal did not ask whether the airline used the best available model. It asked whether the airline took reasonable steps to ensure the chatbot’s statements were accurate. That is a process question, and process questions have documentable answers.
The five patterns that create exposure
- Invented policy — return windows, refund conditions, waiver criteria that do not exist. The Air Canada pattern, and the most common.
- Invented numbers — a fee, a rate, a balance, a deadline. Caught by the ungrounded-number check.
- Unauthorised commitment — an SLA or outcome the firm has not agreed to.
- Regulated advice — anything that reads as financial, legal or tax advice without the required framing.
- Confident misdirection — a correct-sounding answer to a question the knowledge base never covered.
What "reasonable steps" looks like in evidence
- Approved knowledge sources with named owners and review dates
- Hard policy boundaries in code, not in the system prompt
- Runtime validation before send, with failures logged
- Confidence-based escalation with a documented floor
- Production monitoring with drift detection between responses and current policy
- Incident logging for every error, reviewed for pattern rather than fixed individually
- Automated alerts when a business rule changes so the knowledge base is updated
System prompt instructions are not a control. "Never promise a refund" in a prompt is a suggestion the model usually follows. The same rule as a regex in the validation layer is a control you can evidence. Regulators and tribunals distinguish between the two, even when the outcome is identical on a good day.
Measuring honestly
Almost every published containment figure is measured in a way that flatters it.
1. TRUE CONTAINMENT
resolved without escalation AND no recontact on the same issue
within 7 days / total conversations
Most teams report only the first half. The gap between the two
numbers is your real quality signal.
2. ESCALATION REASON MIX <- watch this weekly
Tag every escalation. If "wrong answer given" exceeds ~3% of
escalations, stop expanding scope and fix grounding.
Healthy mix: mostly "out of scope" and "policy exception",
very little "wrong answer" or "customer frustrated".
3. CSAT AT RESOLUTION POINT
Measured immediately, not 24 hours later. Delayed surveys miss
the correlation with containment mistakes entirely.
4. ESCALATION HANDOFF QUALITY
% of escalated conversations where the customer had to repeat
information already given. Target: near zero.
This is the number customers actually feel.
5. COMPLAINT RATE PER 1,000 CONVERSATIONS
Rising complaints alongside rising containment is the signature
of over-automation. Track them on the same chart.
6. COLLECTIONS CONDUCT VIOLATIONS
Contacts outside window / total contacts. Target: zero.
Not a KPI to improve - a control to prove.
WHAT NOT TO REPORT AS SUCCESS
- containment alone
- deflection rate (a customer who gave up is not deflected)
- average handling time on AI conversations (meaningless)
- cost per contact without the complaint rate beside itThe signature of over-automation
Containment climbing while complaint rate climbs with it. The bot is closing conversations rather than resolving them, and the dissatisfaction surfaces later through a channel that costs far more than a support contact ’ a formal complaint, an ombudsman referral, a public review.
Put both lines on the same chart and give the chart to whoever owns the automation target. It is remarkably effective at ending arguments about scope expansion.
Vulnerable customers
The category AI handles worst and where getting it wrong costs most.
Vulnerability in financial services is situational as often as permanent: bereavement, job loss, illness, domestic abuse and financial coercion, cognitive decline, language barriers, or simply being in acute distress about money.
Detecting it
Signals worth routing on: explicit disclosure, bereavement language, mentions of illness or hospital, references to being made redundant, repeated confusion across a conversation, distress markers, and third parties speaking on the customer’s behalf.
Classification here should be deliberately over-sensitive. A false positive costs a human conversation that was probably worth having anyway. A false negative puts an automated dunning message in front of someone who has just lost their job.
Then what
- Stop automated outbound contact on that account immediately, across every channel
- Route inbound to a trained human, not a queue
- Record the flag with an expiry and a review, not permanently and not silently
- Make sure the flag is visible to collections, not only to support — this is the integration that is usually missing
The collections system and the support system are typically different vendors with different databases. A hardship disclosed to support that never reaches collections is the most common way a firm ends up sending a legally compliant message that is indefensible in substance.
Complaints as a regulated process
A complaint is not an unhappy customer. It is a defined event with clocks attached.
Under the Indian framework as it now stands: a dedicated cell for recovery-related complaints, acknowledgement within 24 hours, resolution within 30 days, recovery activity suspended for the account while pending, and an Internal Ombudsman at larger institutions to review rejections. Unresolved matters escalate to the Reserve Bank - Integrated Ombudsman Scheme 2026 through the CMS portal.
The hard part is recognising one
Customers rarely say "I wish to make a complaint". They say "this is unacceptable", or "I have called three times", or "I am going to report this".
Under-recognition is a standard examination finding, because a complaint not logged is a clock not started. Err toward logging: classify generously, and let the process close it quickly if it resolves.
COMPLAINT SIGNALS (any of these -> log and start the clock)
Explicit "complaint", "escalate", "ombudsman", "regulator", "RBI",
"legal action", "consumer court"
Dissatisfaction with handling
"I have called X times", "nobody has responded",
"still not resolved", "this is unacceptable"
Alleged detriment
"charged wrongly", "without my permission", "never authorised",
"you have damaged my credit score"
Conduct allegation
"your agent threatened", "called at night", "contacted my family",
"abusive", "harassment" <- IMMEDIATE, recovery suspends
Distress + fault
any vulnerability signal combined with an allegation that
the firm did something wrong
DESIGN RULE
The classifier decides whether it IS a complaint.
A human decides the OUTCOME. Never the reverse.The audit record, and where this module ends
{
"conversation_id": "cx_01HYA...",
"customer_ref": "cust_5521",
"channel": "in_app_chat",
"started_at": "2026-05-23T10:04:11Z",
"classification": {
"intent": "billing_query",
"risk_tier": "ai_permitted",
"vulnerability_signals": [],
"complaint_signals": []
},
"turns": [{
"role": "customer", "text": "why was I charged 499 this month",
"at": "..."
},{
"role": "ai",
"retrieved": [{"doc": "fees-schedule-v12", "section": "2.3",
"relevance": 0.91}],
"generated": "Your account was charged the annual maintenance fee
of Rs 499 [source: fees-schedule-v12 s2.3].",
"validation": {"passed": true, "ungrounded_numbers": [],
"prohibited_commitments": [], "confidence": 0.94},
"sent": true, "at": "..."
}],
"outcome": {
"resolved_by": "ai",
"escalated": false,
"escalation_reason": null,
"recontact_same_issue_7d": false,
"csat_at_resolution": 4
},
"model": {"name": "support-agent", "version": "2.7.1",
"kb_snapshot": "kb-2026-05-21", "policy_version": "cx-policy-v9"}
}
--- collections contact record (separate, stricter) ---
{
"contact_id": "col_01HYB...",
"loan_ref": "ln_8821",
"channel": "voice",
"attempted_at": "2026-05-23T11:12:00+05:30",
"gate": {"within_window": true, "consent_outside_hours": false,
"complaint_pending": false, "hardship_flag": false,
"contacts_today_before": 0, "decision": "permitted"},
"agent": {"id": "ra_2291", "name": "...", "certification_ref": "IIBF-...",
"agency": "...", "identified_self": true},
"recording": {"stored": true, "ref": "rec_77213",
"retain_until": "2026-11-23", "retention_basis": "6_months_min"},
"script_version": "collections-script-v14",
"language_vetting": {"passed": true, "flags": []},
"outcome": "promise_to_pay", "notes": "..."
}Note the two records are separate and the collections one is stricter. That is deliberate. The support record proves you answered accurately; the collections record proves you behaved lawfully, and it must survive a grievance investigation six months later.
Where this module ends
- Fraud reporting by customers starts here and is handled in Module 03.
- Disputes and chargebacks are Module 05 — the customer conversation is here, the money movement is there.
- Tipping-off constraints from Module 04 govern what an agent may say about an account under AML review. The agent must not be able to see the reason, let alone state it.
- Hardship and forbearance decisions touch credit policy in Module 02.
- Model governance for the support model — evaluation, drift, documentation — is Governance.
Illustrative throughout. Customer-facing AI in a regulated lender should not go live without conduct sign-off, a documented escalation policy, and an incident process for the day it says something it should not. Plan for that day, because it arrives.
Sources
Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which are primary-sourced and which are industry reporting.
- officialRBI directions on recovery agents and responsible conduct — the contact window covering digital channels, recording and the prohibition on remote disabling. www.rbi.org.in
- officialRB-IOS 2026 — acknowledgement and resolution timelines, Internal Ombudsman, and award limits. cms.rbi.org.in
- industryAir Canada v. Moffatt (BC Civil Resolution Tribunal) — the finding that a firm is responsible for what its chatbot says, and the reasonable-steps test.
- officialDPDP Act, 2023 — consent and purpose limits on support data sent to a model. www.meity.gov.in
Tooling, pricing and cost sources for this module are on its build sheet: sources →
Checked September 2026. Regulation in this area is actively developing; the date is part of the claim.
Ask an AI about this page
Opens your assistant with this page as the source, and a question rather than a summary. It will ask what you are building before it answers.
Nothing is sent from here. The link carries only this page’s title and address.