Model risk committees in Indian banks get the same report every quarter, whether the model underneath is a credit scorecard built in 2014 or an LLM-based underwriting assistant deployed last month. That report has a fixed shape: models in inventory, models overdue for validation, open MRM findings by severity, override rates, significant changes. It was built for regression models and gradient boosting — systems with a bounded output space and a validation playbook everyone already knows.
AI systems don't fit that shape, and pretending they do is how committees end up approving things they haven't actually seen. Residual risk by domain isn't a line item in traditional MRM reporting. Fairness testing at the segment level isn't reported. Nobody is monitoring whether an LLM's behavior drifts between validation and production. Agentic systems' authorization scope — what the agent can actually touch — goes untracked. And India-specific proxy variable testing, the thing RBI examiners now ask about directly, is often simply absent from the deck.
The practical effect: the committee approves the AI system on validation status and a performance metric, exactly the basis it would use for a logistic regression. When an examiner later asks "what did this committee actually review before sign-off," the honest answer is often "a Gini score and a clean validation checkbox" — not a defensible governance record. Below is the report structure that closes that gap, section by section, with what each one has to force onto the table and what the committee is supposed to do with it.
1. Executive summary: AI portfolio tiering, not just a model count
This section opens with the AI portfolio by risk tier — Critical, High, Medium, Low — deployment status for each, net change since the last report, and any tier escalations or overdue re-validations flagged at the top, not buried on page six. A model that moved from Medium to Critical because its decision scope expanded belongs in the first paragraph, not the appendix.
The specific thing that matters here: tier migrations need a one-line reason attached, every time. "Moved to Critical — authorization scope expanded to include auto-approval up to ₹2 lakh" tells the committee something an unexplained status change never will. Committees that skip this end up rubber-stamping a tier change they don't understand, because nobody wants to be the one who holds up the meeting asking what it means.
What the committee must do: confirm every tier escalation has an attached reason and an accountable owner before moving past this section.
2. Risk exposure: a residual risk heat map by domain, scored on Zytra's own methodology
This section presents a residual risk heat map across seven domains — Model Accuracy, Fairness, Security, Explainability, Data Governance, Third-Party AI, and Agentic/Autonomous — showing aggregate residual risk level and the count of systems rated Critical or High in each domain, with an appendix breaking out individual system scores.
The scoring convention behind the heat map — "Critical = inherent risk × (1 − control effectiveness) > 12" — is Zytra's own risk-scoring methodology, not a formula RBI or any regulator mandates. Banks are free to adopt it, adjust the threshold, or run their own equivalent; what matters to an examiner is that the bank has a documented, consistently-applied convention, not that it matches Zytra's constant exactly.
Watching a committee see a Critical-tier Agentic score for the first time is instructive. Nobody in the room usually disputes the Fairness or Accuracy numbers — those feel familiar. The Agentic column is where the questions start, because most MRM committees have never had to score "what can this thing do without asking" as a risk dimension before.
What the committee must do: require a documented remediation plan for every domain-system combination scored Critical or High before the system can proceed to its next deployment stage.
3. Validation status: LLM behavioral consistency, not just a pass/fail validation stamp
Beyond the standard open-findings-by-severity and overdue-revalidation-by-tier tables, this section needs LLM behavioral consistency results — evidence that the model's outputs on a fixed test set haven't drifted since the last validation run, since LLMs change behavior with upstream provider updates even when the bank changes nothing. Every Critical finding gets a named owner, a remediation timeline, and an explicit statement of whether deployment is paused pending fix.
The specific thing generic "validation status" reporting misses: a statistical model's validation result is stable until someone retrains it. An LLM behind an API can produce different outputs on the same prompts after a vendor-side model update the bank never approved and may not even be told about. Reporting "validated, no open findings" without a re-run behavioral check is reporting a snapshot that may already be stale.
What the committee must do: block deployment on any Critical finding without a named owner and a dated remediation commitment — no exceptions, no "we'll circle back."
4. Fairness: segment-level FPR/FNR and India proxy variable testing outcomes
This is where India-specific testing has to live: segment-level false positive and false negative rates, and proxy variable testing outcomes for caste, religion, language, and disability — the proxy categories RBI examiners specifically probe for in credit and underwriting models. Threshold breaches get flagged explicitly, not folded into a general "fairness: acceptable" line.
The first time a fairness breach shows up mid-meeting — a segment-level FNR spike the model team didn't catch because they were only watching the aggregate Gini — the tenor of the room changes immediately. Committees that have only ever seen a single blended fairness number treat a segment breakout like it's manufacturing new problems, when it's just surfacing problems the aggregate number was hiding. That reaction is itself a signal the committee hasn't been getting this data long enough.
What the committee must do: treat any threshold breach on a proxy variable as a standing agenda item until closed, not a note that disappears into next quarter's report.
5. Incidents: the AI incident log and its notification triggers
The incident log needs date, system, description, customer impact, classification, status, and root cause for every AI-related incident, with an explicit flag for whether re-validation was triggered and whether the incident crosses a DPDP Act or RBI notification threshold. Critical incidents get an explicit escalation path recorded, not just a mention.
The specific gap in generic incident reporting: "system malfunctioned" tells the committee nothing. "Agentic system auto-approved three transactions outside its authorized ₹50,000 ceiling before the kill-switch triggered" tells them exactly what failed and what the control gap was. The eMRM guidance's emphasis on kill-switch and human-in-the-loop mandates makes this distinction non-optional, not stylistic.
What the committee must do: confirm every incident that crosses a regulatory notification threshold has a documented notification decision — sent, or explicitly determined not required and why — attached before the meeting closes.
6. Changes: pre-production test outcomes for every Critical or Major change
Critical and Major AI system changes need a description, the classification rationale behind calling it Critical/Major rather than Standard/Minor, pre-production test outcomes, the re-validation scope and its outcome, and an explicit approval record. Standard and Minor changes can be summarized as a count — the committee doesn't need to re-litigate a prompt template tweak.
The specific discipline this enforces: classification rationale has to be written down, because "why did we call this Major and not Critical" is exactly the question an examiner asks when a change later causes an incident. A one-line rationale at change time is cheap. Reconstructing it eighteen months later from memory is not.
What the committee must do: reject any Critical or Major change request that arrives without pre-production test outcomes attached — don't approve on the promise that testing will follow.
7. Regulatory: the horizon scan tied to RBI's eMRM guidance, not a generic watch-list
The regulatory horizon section tracks new or amended requirements, which systems they affect, what action is required, and who owns it. The mandatory sources are RBI circulars, SEBI guidance, DPDP Act enforcement actions, EU AI Act implementing regulation — and specifically RBI's eMRM guidance.
RBI issued its Draft Guidance on Regulatory Principles for Model Risk Management on 24 June 2026 (comments closed 24 July 2026), applying to eleven categories of RBI-regulated entities and requiring board-approved MRM frameworks, model inventories, risk tiering, independent validation, continuous monitoring, and kill-switch / human-in-the-loop controls. That's not a generic "watch this space" entry — it's a near-term compliance obligation with specific, checkable requirements, and this section should name it directly rather than lumping it into a vague regulatory-watch bucket.
What the committee must do: assign a named owner to every open regulatory item, with a date — "monitoring" without an owner is how a bank discovers it missed a comment deadline.
8. Actions: the decisions this specific meeting has to make
This section lists only what requires a decision this meeting: new Critical-tier deployments awaiting sign-off, Major changes pending approval, fairness breach responses, open Critical findings needing a disposition, and any regulatory response with a deadline inside the current cycle. Everything else stays in the earlier sections as information, not action items.
What committee approval records must show
| Record element | Specific, checkable claim | Why examiners look for it |
|---|---|---|
| Evidence reviewed | Minutes name the exact artifacts shown — e.g. "Section 4 fairness breakout for Model X, segment FNR table" — not "risk materials were reviewed" | A generic reference can't be checked against what was actually presented; a named artifact can |
| Committee deliberation | Minutes capture at least one substantive question and answer, not only a motion and a vote | [ACCURACY FLAG resolved via Fact E: framed as practitioner expectation, not a cited clause] RBI examiners typically expect to see evidence the committee engaged with the material, not just stamped it |
| Conditional approvals | Each condition has a named owner and a due date, recorded in the minutes themselves | A condition with no owner and no date is functionally unenforceable and tends to quietly expire |
| Fairness outcome noted | Minutes state the specific fairness result reviewed (e.g. "no proxy breach, FNR parity within threshold") rather than "fairness was discussed" | Examiners probing fairness governance want to see the committee saw a number, not a topic heading |
| Re-review triggers | Minutes specify what event forces the system back to committee — a tier change, an incident, a vendor model update — not just "will be reviewed again" | Undefined triggers mean re-review happens only when someone remembers, which is not a control |
| Vote record | Minutes show who approved, who abstained, and why, for any split or conditional vote | A unanimous-looking record on a system with known Critical findings invites exactly the question examiners ask first |
India-specific additions every BFSI MRM report needs
For Indian banks specifically, four items belong in the report regardless of institution size: proxy variable fairness testing outcomes inside Section 4 (caste, religion, language, disability), DPDP Act data processing compliance status for every AI system handling personal data, fairness testing broken out by language for multilingual AI systems (a model that performs well in English and poorly in regional-language inputs has a real fairness gap, not an edge case), and an explicit RBI examination readiness status confirming evidence packs are ready for on-demand submission rather than needing to be assembled after the examiner asks.
Action checklist for the next MRM committee cycle
- Add a residual risk heat map by domain to the next report, scored on a documented internal convention — don't wait for a regulator to require the exact formula; defensibility comes from consistency, not from matching anyone else's threshold.
- Pull India proxy variable testing (caste, religion, language, disability) into Section 4 as a standing line item, not a one-off deep dive requested after an incident.
- Require every Critical or Major change request to arrive with pre-production test outcomes attached — make this a submission gate, not a review-time ask.
- Rewrite the committee minutes template to force a named owner and due date on every condition, and at least one recorded question-and-answer exchange per Critical item.
- Build the RBI examination readiness check into the quarterly cycle now — assemble the evidence pack before an examiner asks for it, not after.
Related: AI governance committee and reporting
Give your MRM committee the AI risk report it actually needs
Zytra generates the complete 8-section AI model risk report with residual heat maps, fairness testing results including India proxy variable outcomes, committee-ready validation summaries, and hash-chained approval records. Delivered automatically before each committee meeting.