Compliance and data rules for AI in banking and insurance
What are the compliance rules for AI in banking and insurance?
Four rulebooks shape an AI deployment in Indian banking and insurance: RBI directions on IT outsourcing and payment data storage, IRDAI security guidelines for insurers, SEBI's cyber resilience framework for market intermediaries, and the DPDP Act across all of them. Each translates into architecture, not paperwork.
Four rulebooks shape AI in Indian banking and insurance: Reserve Bank of India directions on IT outsourcing and payment data storage, IRDAI information and cyber security guidelines for insurers, SEBI's cyber resilience framework for market intermediaries, and the DPDP Act 2023 across all of them. Each one translates into architecture decisions rather than policy documents.
This article maps each regulator to the specific design choice it forces, answers the residency question honestly, lists the controls a regulated AI system needs before go-live, and is clear about the cases where the rules are a signal not to deploy a model at all.
Regulation shapes the architecture, not the paperwork
The common mistake is to treat compliance as a review gate at the end. In BFSI it is a set of constraints on the first architecture diagram. Where the data sits, which vendor can see it, whether a third party may retain it, how long records are kept and who can reconstruct a decision are all questions with a right answer before anyone writes a prompt.
That is why AI projects in this sector fail late rather than early. A retrieval system built on a hosted vector store passes every functional test and then fails legal review because customer records left the perimeter. Retrofitting residency into a live system costs more than building for it, and the same is true of audit lineage and retention.
The second mistake is assuming regulation forbids AI. It does not. It requires that you can explain what happened, that accountability stays with the regulated entity, and that the customer's data is handled as the customer was told it would be. Systems designed on those three principles clear review comfortably. Our view of how these constraints play out across fintech and BFSI starts from the architecture rather than the policy.
Which regulator changes what in your design?
Each row names the rulebook, what it governs and the concrete consequence for a system that uses machine learning or a language model.
| Rulebook | Applies to | What it changes in your AI architecture |
|---|---|---|
| RBI directions on outsourcing of IT services | Banks, NBFCs, co-operative banks | Vendor due diligence, right to audit, exit plan and continuity for every AI supplier and subprocessor |
| RBI payment data storage requirement | Payment system participants | Payment data stored in India, which constrains where inference and logging may run |
| RBI digital lending guidelines | Lenders and their loan service providers | Data minimisation at collection, no borrower data retained by third-party apps beyond what is needed |
| IRDAI information and cyber security guidelines | Insurers and intermediaries | Board-approved security policy, access control and incident reporting covering AI components too |
| SEBI cyber security and resilience framework | Market intermediaries | Classification of critical systems, logging, testing and reporting obligations that AI services inherit |
| DPDP Act 2023 | Everyone processing personal data in India | Consent and notice, purpose limitation, erasure, retention limits, processor contracts, breach notification |
| Sectoral record retention rules | Banks and insurers | Decision records kept for years, which makes audit lineage a storage design problem |
| Grievance redressal obligations | All regulated entities | Every automated customer outcome needs a human escalation path with context |
Where does the data actually have to live?
The DPDP Act does not impose blanket localisation: it permits transfers outside India except to territories the Central Government restricts. Sectoral rules are stricter and are what usually decides the question. The Reserve Bank requires payment system data to be stored in India, and most large regulated entities extend that posture to customer data generally by policy.
For an AI system the practical consequence is threefold. Model inference must run in an Indian region or inside your own account. Logs, traces and evaluation datasets are copies of the same data and must follow the same rule, which teams routinely forget. And the support tooling, ticketing, monitoring, paging, is a cross-border transfer if it stores content offshore.
When the answer is that nothing may leave the perimeter, open-weight models hosted in your own environment become the design rather than a preference. The trade-offs, including where quality genuinely differs, are set out in our checklist for self-hosted LLMs in BFSI, and the data residency glossary entry defines the terms auditors use.
The controls a regulated AI system needs before go-live
Eight controls come up in every review we have been through in this sector. Build them in; none is expensive at design time and all are painful afterwards.
- Decision lineage. Input, retrieved sources, model and prompt version, output, confidence and the human decision, stored immutably against a case ID for the retention period your regulator sets.
- Human accountability for consequential outcomes. A person approves adverse decisions such as declines, repudiations and account restrictions. The system prepares; it does not decide alone.
- Confidence thresholds with an exception queue. Below threshold, the case routes to a reviewer. The threshold is a documented, board-visible parameter, not a constant buried in code.
- Scoped tool permissions. An agent gets narrow, named capabilities with limits, never a database connection. Anything financial carries a value ceiling and an approval gate.
- Redaction before logging. Identifiers, card fragments and health details are stripped at source, so observability does not become an uncontrolled data store.
- Vendor and subprocessor register. Every party that can see data, with the right to audit and a tested exit path, as the RBI outsourcing guidelines require.
- Model change control. Provider deprecations force re-evaluation. A regression suite and a re-approval path make that routine instead of an incident.
- Grievance escalation with context. A customer disputing an automated outcome reaches a human who can see exactly what the system saw.
What you must be able to explain
Explainability is about the decision, not the weights
No regulator expects you to interpret a transformer's internals. They expect you to reconstruct a specific decision: what data was used, which policy applied, what the system concluded and who signed it. A retrieval system that cites its sources and an agent that logs its tool calls satisfy that. A model that returns a score with no trace does not.
Model risk deserves the same discipline as credit risk
Treat each production model as an inventoried asset with an owner, a documented purpose, a validation record, performance monitoring and a review date. The model risk audit glossary entry covers what that inventory contains, and AI audit trails describes what examiners ask to see in practice.
Fairness testing where outcomes affect access to credit or cover
If a model influences pricing, eligibility or claim outcomes, test performance across the segments your business serves and keep the results. This is defensible practice regardless of whether a specific rule names it, and it is far cheaper than reconstructing evidence after a complaint.
Consent and purpose, stated in the customer's language
Under the DPDP Act, notice and consent must be specific about purpose. Using service transcripts to train or tune a model is a different purpose from handling the call, and our guide to DPDP Act 2023 and AI works through where that line sits.
What compliance adds to cost and timeline
Expect audit lineage, redaction, the exception queue and access controls to add roughly two to four weeks to a first build, and expect a deployment inside your own perimeter to be the larger factor. Eazyware's self-hosted agentic AI starts at $31,500 or ₹20.8 lakh plus infrastructure, against $12,500 or ₹8 lakh for a hosted customer service agent, and the gap is mostly the environment rather than the intelligence. Post-launch, a Care Plan starts at $1,000 or ₹68,000 per month with a $750 or ₹40,000 AI add-on covering evaluation runs, prompt regression and re-indexing, which is how model change control actually gets done. The tiers are on the pricing page.
When the rules mean you should not deploy
Three cases where we advise against it. First, when a decision is fully consequential and cannot be reviewed at your volume. If a model would decline thousands of claims a day and you cannot staff meaningful review, the compliant design is narrower automation, not a bigger model.
Second, when the process is deterministic. Eligibility rules, tariff computation and mandate validation belong in a rules engine that is explainable by construction. Adding a language model creates review burden and buys nothing.
Third, when consent does not cover the use. If customers were told their data would be used to service their account, using it to train a model is a new purpose and needs fresh notice. No architecture fixes a consent gap.
What this looks like in practice
An NBFC we work with needed document intelligence for KYC and loan onboarding without customer documents leaving their control. The system runs inside their own cloud account, redacts identifiers before anything is logged, routes low-confidence extractions to a human queue, and records every decision against a case ID with the model version attached. The build is described in the KYC document intelligence case study. None of those controls slowed the project down, because they were in the first architecture diagram rather than the last review.
A pre-deployment checklist
- Name the regulated entity accountable for each automated outcome
- Map every data store the system touches, including logs, traces and evaluation sets
- Confirm the deployment region and whether any vendor can read production data
- Document the confidence threshold and who may change it
- Build decision lineage before the first user, not after the pilot
- Register every AI vendor and subprocessor with audit rights and an exit plan
- Agree the retention period per record type with compliance
- Rehearse a grievance escalation end to end, including what the human can see
Related reading
Our detailed treatment of RBI guidelines and AI goes deeper on outsourcing, localisation and audit for banks and NBFCs specifically. The Insurance Regulatory and Development Authority of India publishes its regulations and information and cyber security guidance at irdai.gov.in, which is the primary source for insurer obligations rather than any summary. If you want an architecture reviewed against these constraints before you build, bring us the design.
Design for reconstruction: if you can show who decided what, on what evidence, and when, most of BFSI compliance follows from that one property.
Frequently asked questions
Does Indian regulation allow banks to use large language models?
▾
Yes. Nothing in RBI, IRDAI or SEBI rules prohibits language models. What the rules require is accountability with the regulated entity, vendor due diligence with audit rights and an exit plan, control over where data is stored, and the ability to reconstruct a specific decision. Systems designed for those properties clear review.
Does AI data have to be stored in India?
▾
The DPDP Act permits transfers abroad except to restricted territories, so it imposes no blanket localisation. Sectoral rules are stricter: the Reserve Bank requires payment system data to be stored in India, and most regulated entities extend that to customer data by policy. Logs, traces and evaluation datasets count as copies.
What audit evidence do regulators ask for on an AI system?
▾
A model inventory with owners and validation records, decision lineage linking inputs, retrieved sources, model and prompt version, output and the human approver, retention that matches sectoral rules, a vendor and subprocessor register with audit rights, and evidence that adverse automated outcomes have a human escalation path.