AI Chatbot Governance for Banking: Why Customer-Facing AI Requires Stricter Governance Than Back-Office AI, What RBI FREE-AI Requires, and the Four Prohibited Use Cases Most Banks Are Currently Handling Incorrectly

Customer-facing banking chatbots carry a governance burden that back-office AI simply doesn't. When a credit scoring model misfires, a human reviews the output before it touches a customer. When a chatbot misfires, the wrong answer reaches the customer directly, with no one in between, and it reaches every customer who asks that question that day.

Ask any bank that has shipped a retail chatbot what their worst day looked like. It's usually not an outage — it's a screenshot. A customer asks for the FD interest rate, the bot confidently states a number that was correct eight months ago, and that screenshot is now circulating on social media with the bank's logo on it. Nobody writes an incident report for a model that silently used a stale feature; everyone writes one for a chatbot that said something wrong out loud, in the bank's voice, with a timestamp.

RBI's FREE-AI framework (released 13 August 2025, built on 7 Sutras and 6 pillars spanning Infrastructure, Policy, Capacity, Governance, Protection, and Assurance) applies across customer-facing AI, and the customer-protection expectations embedded in it — fair treatment, accuracy, disclosure — are exactly the ones most chatbot governance programs weren't built to satisfy. This piece covers what that actually requires, the use cases banks are currently routing through chatbots that shouldn't be, and the three-level architecture that keeps a chatbot from inventing facts.

Which chatbot use cases RBI, SEBI, and IRDAI actually permit in Indian BFSI

Most banks don't have a clean list of what their chatbot is allowed to do — they have a feature backlog that grew use case by use case until legal flagged something. That's backwards. Build the permitted/prohibited boundary first, then build features inside it.

The SEBI and IRDAI lines aren't judgment calls — they're licensing law. A chatbot that tells a customer which mutual fund suits their risk profile is giving investment advice, and giving investment advice without an RIA license is a SEBI violation regardless of whether a human or a model said it. The same logic applies to insurance: recommending a specific policy is solicitation, and solicitation requires an IRDAI-licensed intermediary. Banks that let their chatbot "just explain options" routinely cross this line the moment the explanation gets specific enough to function as a recommendation.

The distinction banks get wrong most often, though, is "grievance logging, not resolution." Product teams treat this as a technicality — the bot takes down the complaint, so isn't that progress? It isn't, if the bot also tells the customer their refund is approved, their dispute is resolved, or their complaint is closed, none of which it has the authority to decide. Logging means capturing and routing; resolution means a decision with financial consequence. Collapsing the two is how a chatbot ends up making adjudication calls it was never authorized to make.

The three-level hallucination control architecture RBI's reliability expectations require

A chatbot that's wrong 2% of the time isn't 98% reliable in any sense a bank can defend to a regulator — it's a chatbot that's wrong at scale, consistently, in ways nobody notices until a customer screenshots it. The fix isn't a better model; it's an architecture that doesn't let the model answer from memory when the answer has a regulatory or financial consequence.

Level 1 — Input-level: RAG grounded in verified bank documentation. Every response is retrieved from current bank documentation at query time, not generated from the model's training weights. The model doesn't "know" today's FD rate — it looks it up. The harder design question is what happens when retrieval comes back empty: a bot that silently falls back to the model's general knowledge in that gap is exactly how a stale or fabricated rate gets quoted. The correct fallback response is explicit and bounded — something like "I don't have verified information on that right now; let me connect you with an agent who can confirm it" — not a guess dressed up as an answer. Reliability expectations under the FREE-AI "Safety, Resilience and Sustainability" Sutra, and RBI's draft eMRM guidance (June 2026), both point toward this kind of grounded, auditable retrieval step rather than open generation.

Level 2 — Output-level: numerical verification against live data. Any number the bot states — a rate, a fee, a balance, a date, a deadline — gets checked against the live source system before it's delivered, as a separate step from retrieval. This catches the specific failure mode that burns banks publicly: a document that was accurate when indexed but has since been superseded by a rate change nobody re-synced. A retrieved document is not the same thing as a current fact, and treating it as one is the gap this layer closes. This sits alongside DPDP Act notice-and-consent obligations, since the same accuracy expectation applies to any data the bank surfaces back to the customer.

Level 3 — Behavioral consistency monitoring. The same factual question, asked by different customers on different days, should get the same answer; drift between those answers is a hallucination signal, not a quirk. This is where the eMRM connection stops being a stretch and becomes direct: RBI's draft eMRM guidance explicitly calls for human-in-the-loop review and ongoing monitoring of AI-driven decisions for consistency, and that is precisely what behavioral-consistency monitoring operationalizes for a chatbot. In practice this means logging answer variance across repeated queries and alerting when it crosses a threshold — not waiting for a customer complaint to surface it.

The five disclosures RBI and DPDP require before a customer trusts the bot's answer

Disclosure requirements exist because a customer who doesn't know they're talking to a model can't calibrate how much to trust it — and in BFSI, miscalibrated trust in a wrong answer is the whole risk.

• AI identity disclosure — the bot states it's an AI at session start, not in paragraph nine of the T&Cs. This maps to the FREE-AI "Trust is the Foundation" and "People First" Sutras, which center accountability and transparency toward the customer rather than the institution.
• Limitation disclosure — the bot states what it can't help with, up front, so the customer isn't discovering the boundary mid-conversation on something urgent.
• Source citation — answers reference where the information came from, consistent with the "Understandable by Design" Sutra's expectation that AI-driven outputs be explainable to the person affected by them.
• Escalation pathway — a human agent is always reachable, not gated behind a maze of bot-only menus.
• Data processing notice — under DPDP Act notice-and-consent obligations, the customer is told at session start that conversation data may be retained for regulatory audit purposes, in plain terms, not buried in a privacy policy link.

What the chatbot team should actually do this quarter

Reading the requirements isn't the hard part — operationalizing them before the next audit or the next viral screenshot is. Five concrete steps:

1. Audit every live chatbot flow against the permitted/prohibited table above, and pull anything that drifts into SEBI-licensed investment advice, IRDAI-licensed insurance recommendations, or grievance resolution rather than logging — this quarter, not next audit cycle.
2. Instrument the RAG fallback path explicitly. If retrieval returns no relevant document, the bot must say so and hand off — verify this is actually happening in production, not just in the design doc.
3. Add a live-data verification step for every number class (rates, fees, balances, dates, deadlines) between retrieval and delivery, and treat a mismatch as a release-blocking bug, not a backlog item.
4. Stand up behavioral-consistency monitoring — log answer variance on repeated factual queries and alert on drift, framed explicitly against RBI's draft eMRM human-in-the-loop expectations so Model Risk Management owns it jointly with the chatbot team.
5. Put all five disclosures at session start, in the customer's language, including regional-language variants — a disclosure that only exists in English for a Hindi or Tamil conversation isn't a disclosure.

Zytra's platform runs these controls as policy enforcement rather than documentation: three-level hallucination controls, prohibited-use-case guardrails mapped to SEBI/IRDAI/RBI boundaries, and regional-language parity testing so the same safeguards hold outside English conversations. In Zytra's own internal benchmarking, the guardrail layer covers the OWASP LLM Top 10 at 11.6ms added latency — a Zytra-measured figure for Zytra's pipeline, not an industry-standard number, included here so banks evaluating the tradeoff have it.