Issue 3 · June 2026
The headline, and the real story
The Reserve Bank of India’s draft Guidance on Regulatory Principles for Model Risk Management will be read, by many, for a single phrase: the AI kill switch. The attention is understandable. It is vivid, immediate, and easy to picture. Yet it is also the smallest part of what the guidance is really asking for.
RBI is not simply asking regulated entities to fit an emergency brake to their AI. It is inviting a more mature operating discipline around the models that now sit behind much of modern finance: credit and pricing decisions, customer engagement, fraud detection, risk and compliance, collections, cyber defence, and a fast-growing layer of vendor-led automation. To my mind, that is the part worth our attention.
Across the sector, models have quietly become part of everyday business. Some are statistical. Some are rules engines. Some are machine-learning systems. Some are spreadsheets nobody quite calls a model. Some sit inside vendor platforms, and a growing number are now AI or generative AI. The guidance recognises that reality and asks a fair question of all of them: who owns this, how is it validated, how is it watched, and what happens when it stops behaving as expected.
The kill switch will earn the headline. Model accountability is the story.
From model use to model discipline
Financial institutions have used models for years to improve speed, consistency, risk detection, customer service, and operational efficiency, and that progress deserves recognition. Models have helped institutions scale decisions, reduce manual friction, surface suspicious behaviour, sharpen credit assessment, and respond faster to customers and markets. The task ahead is not to slow any of that down. It is to govern it well.
Once a model supports a business decision, it stops being only a technical asset. It becomes part of the institution’s control environment. It shapes outcomes, affects customers, and underpins risk choices, and it usually depends on data, assumptions, vendor logic, system integrations, and ongoing monitoring. That combination calls for a disciplined way of managing it.
| From | To |
|---|---|
| Model usage | Model discipline |
| A technical asset | Part of the control environment |
| Awareness of risk | Evidence of control |
| Vendor trust | Vendor assurance |
The practical question for leadership is a calm one. Do we know which models matter to this institution, who owns them, how they are validated, how they are monitored, and what happens when they do not behave as expected? It is the kind of question a mature institution prefers to ask early, before pressure builds.
You cannot govern what you cannot see
The conversation about the kill switch is useful, but it should not become too narrow. A switch assumes you already know what to switch off. In practice, the first piece of work is visibility: understanding where models live and how they are used. That is often harder than it looks.
A formal inventory may already cover credit, risk, or treasury models. But model behaviour also hides in business spreadsheets, pricing calculators, rule-based workflows, fraud engines, AML monitoring, collections tools, customer-service bots, cyber risk platforms, marketing systems, vendor products, and the AI features now arriving inside everyday enterprise applications. This is not a sign of carelessness. It is what happens when the model landscape expands faster than the map of it.
| Models you are likely tracking already | Usage that tends to sit outside the inventory |
|---|---|
| Credit and pricing | Business spreadsheets |
| Fraud detection | Pricing calculators |
| AML monitoring | Rule-based workflows |
| Treasury and risk | Embedded vendor AI |
| Collections | |
| Customer-service bots | |
| Cyber risk platforms | |
| Marketing and propensity |
Good governance begins with knowing what you actually own.
A sharper conversation in the boardroom
The Board and the Risk Management Committee do not need to step into the detail of every model. Their role is to be sure the institution has a dependable framework for managing model risk, and to direct attention where it is most needed. At that level the questions can stay clear and business-oriented.
Questions worth asking at the table
- Which models are material to this institution?
- Which of them affect customers directly?
- Which are AI or machine-learning based?
- Which depend on third-party vendors?
- Where is explainability limited?
- Which have been independently validated?
- Which carry open exceptions today?
- Which have a tested fallback arrangement?
None of these is an adversarial question. They are governance questions, and a confident management team should welcome them, because they bring structure, priority, and accountability to an area that has grown quietly complex. Asked regularly, they turn model risk from something discussed after an incident into something managed before one.
The kill switch is a governed fail-safe
The phrase invites a picture of one technical button. A more useful reading is broader. A good kill switch is a governed fail-safe: it sets out when a model may be suspended, who has the authority to act, how the model or workflow is disabled, what process takes over, how customers are looked after, what evidence is captured, and how the model is restored, revalidated, restricted, or retired.
The fail-safe, as a sequence
Consider a customer-facing AI assistant that starts giving unreliable answers. The right response does not end at switching it off. Customers move to trained human support, the incident is logged, the cause is examined, and the system comes back only once the issue is understood and fixed. A fraud model with a sudden rise in false positives may need a temporary review path. A credit model whose decisions cannot be explained well enough may warrant escalation and manual review. A vendor model that changes behaviour may need its use limited until the change is assessed. This is controlled degradation: the business keeps running in a safer mode while the problem is addressed, which is far more useful than a single off switch.
When the model belongs to someone else
Many regulated entities now rely on vendor systems that carry models, scores, rules, analytics, AI features, or automated decisioning. That is normal in a modern financial ecosystem, and it lets institutions move faster and reach specialised capability they could not build alone. The governance task is to make sure this dependency never quietly reduces the institution’s own understanding.
If a third-party model influences a regulated entity’s decisions or customer outcomes, the institution still needs appropriate assurance about it. That assurance is built from practical things: documentation, validation support, audit rights, change notification, performance reporting, continuity arrangements, exit options, and enough clarity to know how the model behaves. Procurement and vendor-risk teams may therefore need a sharper model-risk lens than the one they use today.
When the model belongs to someone else, the accountability still belongs to you.
What to ask of a third-party model
- What does the model do, and which decisions does it influence?
- What data does it use, and what are its limits?
- How is it validated, and how are changes communicated?
- Can we test or challenge it ourselves?
- Is it explainable enough for this use case?
- If the system is unavailable, what is the fallback?
Make AI governance operational
Many institutions have already begun the responsible-AI conversation, which is a sound foundation. The next step is to turn those principles into controls people actually operate. Depending on the use, AI and machine-learning models may need explainability thresholds, bias and fairness checks, hallucination controls, adversarial-input testing, prompt-injection safeguards, monitoring for data and concept drift, human oversight, override mechanisms, incident review, and control over automatic updates.
The right control set depends on the use case, and the difference is real. A generative assistant for employees is not a customer-facing chatbot. A fraud model is not a marketing propensity model. A credit decisioning engine is not an internal productivity tool. A vendor black box is not an internally built rules engine. Mature governance reads these differences and applies effort where the risk sits.
| Heavier oversight | Lighter, proportionate touch |
|---|---|
| Customer-facing AI and chatbots | Internal productivity tools |
| Credit decisioning engines | Marketing propensity scoring |
| Fraud and AML models | Internal rules engines |
| Vendor black-box decisioning | Low-impact analytics |
That balance is the aim throughout: innovation with discipline, speed with oversight, automation with accountability.
A practical readiness agenda
Regulated entities do not need every detail finalised before starting the foundational work. The direction is clear enough to act on now, in steps that are sensible whatever the final wording turns out to be.
Six steps to begin
- Run a model census. Sweep every business unit, from credit, fraud, and treasury to operations, marketing, cyber, procurement, and audit.
- Refresh the inventory. Give each material model an owner, purpose, type, lifecycle status, risk tier, customer impact, dependencies, and control status.
- Tier by risk. Classify on materiality, customer impact, autonomy, explainability, data sensitivity, and third-party dependency.
- Strengthen validation. Independently test the high-risk and customer-facing models for soundness, performance, fairness, and limits.
- Design the fail-safes. Put human oversight, override, suspension triggers, fallback workflows, and incident evidence in place.
- Report to the board. Give leadership a clear, regular view of the estate, the high-risk models, the gaps, and remediation progress.
Maturity you can show
A well-governed institution can demonstrate, not just assert, that its material models are known, owned, classified, validated, monitored, and managed through defined lifecycle controls. It can say which models affect customers, where AI is in use, which depend on third parties, where explainability is limited, which carry open validation findings, which have fallback arrangements, and which risks need the board’s attention.
The thread running through all of it is evidence. Awareness is comfortable, but evidence is what holds up under scrutiny, and it tends to already exist in the course of doing the work well.
The evidence that does the talking
- Model documentation
- Validation reports
- Approvals and sign-offs
- Exception records
- Monitoring results
- Change logs
- Vendor assessments
- Incident reviews
- Kill-switch test records
- Internal audit findings
In a board conversation, evidence is what turns awareness into assurance.
The Elytra view
I read RBI’s draft guidance as a maturity signal for the sector, not a warning shot. Models are now part of the operating architecture of finance. They support better decisions, faster processes, stronger detection, and more scalable operations, and as their role grows the governance around them has to grow with it.
The institutions that move early will gain clarity. They will understand their estate, sharpen their vendor discipline, protect their customers more reliably, and give their boards a truer view of risk. They will also be better placed for whatever supervisory expectations follow.
The aim is not to create fear around AI or models. It is to build trust in how we use them, and that trust comes from visibility, ownership, validation, monitoring, fallback, evidence, and accountability at the top.
The closing signal
The kill switch will earn the headline. The quieter work, model governance, is what lets a financial institution use AI with confidence.
Sources and references
- Reserve Bank of India. Draft Guidance on Regulatory Principles for Model Risk Management.