AI Governance · Risk Taxonomy
AI Risk Taxonomy for Banking: 7 Domains, India-Specific Categories, and Framework Crosswalks That Make It Examination-Ready
A model risk register tells you validation status. An AI risk taxonomy tells you what could go wrong — organized consistently enough that residual risk can be compared across systems and domains, and mapped precisely enough that a regulatory crosswalk answers an examiner's first question before they ask it.
Zytra Research Team · October 2026 · 9 min read
Every bank's AI governance program eventually has to answer one question: what are all the ways your AI systems could cause harm, and what stands between you and each one? A risk taxonomy is the structure that makes this answerable at scale, across dozens or hundreds of AI systems, sorted by regulatory framework, in a form a committee or examiner can actually work with.
Without a taxonomy, risk catalogues get built model by model, using whatever the deployment team happened to think of at the time. We've watched this play out at banks running 30–40 AI systems with zero shared risk vocabulary: the fraud team calls something "model drift," the chatbot team calls the same failure mode "response degradation," and neither shows up on the same heat map. Cross-cutting risks — hallucination across every LLM in the estate, prompt injection across every agentic system, proxy-variable bias across every model touching transaction data — stay invisible because no one is looking for them as a category. Residual risk scores have no common basis for comparison, so the committee ends up staring at a list of per-system risks instead of a picture of where the whole portfolio is exposed.
This guide lays out a 7-domain AI risk taxonomy for banking, with subcategories, India-specific extensions, and crosswalk mappings to RBI's FREE-AI framework, SR 11-7, the OWASP LLM Top 10, and the NIST AI RMF.
The 7 AI risk domains for banking
Domain 1: Model Accuracy and Performance Risk in Lending and Fraud Systems
A credit model that's 2% less accurate than validated doesn't just underperform — it mispriced risk on every loan it touched since the drift started, and nobody notices until the loss curve moves. This domain covers performance metric breach, distributional shift, concept drift, out-of-distribution input, LLM hallucination (both factual and behavioral), threshold erosion, override rate anomaly, and RAG retrieval failure. For banks, the sharpest version of this risk sits in underwriting and fraud-scoring models, where drift is slow, silent, and expensive by the time anyone looks.
Domain 2: Fairness and Non-Discrimination Risk, Including India-Specific Proxy Variables
A fair-lending complaint doesn't care whether your model "intended" to discriminate — it cares whether outcomes diverged by segment, and in India that segmentation includes variables most Western fairness frameworks never test for. This domain covers segment-level false-positive/false-negative rate disparity, proxy variables (gender, age, caste, religion, language, disability), LLM behavioral inconsistency by demographic group, and training data imbalance. A model trained on national transaction data can easily encode caste or language-community proxies through pincode, surname pattern, or merchant category — and those proxies won't show up unless you test for them specifically.
Domain 3: Security and Robustness Risk Across LLM and Agentic Systems
A prompt injection attack against a customer-facing LLM doesn't need to breach your perimeter — it just needs the model to follow an instruction hidden in a document it was asked to summarize. This domain covers prompt injection (direct and indirect), jailbreak, model inversion, training data poisoning, PII exfiltration, model denial-of-service, KV-cache cross-tenant leakage, supply chain risk (weights and training data provenance), and adversarial examples. Banks adopting LLM-based assistants and agentic workflows are absorbing an entirely new attack surface that traditional application security testing doesn't cover.
Domain 4: Explainability and Transparency Failures in Adverse Action and Regulatory Reporting
When a customer disputes a loan decline, "the model said no" is not an explanation a banking ombudsman will accept, and it's not one your own risk committee should accept either. This domain covers decision-level explanation failure, model-level interpretability gaps, customer adverse-action explanation, regulator explanation failure, LLM reasoning opacity, explanation inconsistency, and counterfactual explanation failure. The gap gets worse with LLMs: a chain-of-thought trace is not the same as a validated explanation of why a specific customer was declined, and conflating the two is one of the more common mistakes we see in early-stage AI governance programs.
Domain 5: Data Governance and Privacy Risk Under DPDP
A model that memorizes and later reproduces a customer's account number in an output isn't a privacy near-miss — under the DPDP Act, it's a reportable event with a clock already running. This domain covers training data quality failure, feature data staleness, purpose limitation breach, DPDP consent, DPDP data subject rights, personal data appearing in model outputs, retention beyond authorization, cross-border transfer, and training data copyright exposure. Most banks' existing data governance programs were built for structured data pipelines, not for the fact that an LLM can reconstruct personal data from patterns in its training set.
Domain 6: Governance and Accountability Gaps Across the Model Inventory
The single most common finding when we help a bank build its first real AI inventory is that the inventory itself is wrong — systems are missing, owners are stale, and "in production" turns out to mean three different things to three different teams. This domain covers model inventory incompleteness, overdue validation, change management gaps, committee approval bypass, evidence trail gaps, accountability gaps, board reporting gaps, ungoverned third-party AI, and decommission evidence failure. It's the domain examiners probe first, because a governance gap here undermines confidence in every other domain's controls.
Domain 7: Agentic and Autonomous System Risk
An agent that can authorize a transaction, update a ledger, or escalate a case doesn't fail the way a chatbot fails — a chatbot gives a wrong answer, an agent takes a wrong action, and some of those actions can't be undone. This domain covers authorization scope violation, prompt injection via agent, multi-agent trust chain failure, tool access beyond declared scope, irreversible action without authorization, context accumulation risk, emergent goal-seeking behavior, and agent-to-agent data leakage. It's the newest domain in this taxonomy and the one existing frameworks cover worst, which is exactly why it needs its own line item rather than folding into "security."
Mapping the taxonomy to RBI, SR 11-7, OWASP, and NIST
A taxonomy only earns its place in an examination if it maps cleanly to the frameworks an examiner actually asks about. The table below is Zytra's working crosswalk — built for internal risk management and examiner conversations, not a substitute for legal or compliance sign-off on any single framework's text.
| Domain | Related FREE-AI principle (Zytra's informal mapping) | SR 11-7 section | OWASP LLM Top 10 (category, not fixed numbering) | NIST AI RMF |
|---|---|---|---|---|
| 1. Model Accuracy and Performance | Safety, Resilience and Sustainability (Sutra) | Model Validation | Categories covering overreliance and misinformation, where the system is LLM-based | Maps most closely to NIST's MEASURE function |
| 2. Fairness and Non-Discrimination | Fairness and Equity (Sutra) | Not covered — SR 11-7 gap | Not a primary focus of OWASP's LLM list | Spans MEASURE (bias testing) and GOVERN (equity policy) |
| 3. Security and Robustness | Safety, Resilience and Sustainability (Sutra); Protection (pillar) | Partial — Model Development, Implementation, and Use (predates adversarial ML and LLM-specific threats) | Categories covering prompt injection, training data poisoning, sensitive information disclosure, and insecure output handling | Maps most closely to NIST's MANAGE function, with MEASURE for testing |
| 4. Explainability and Transparency | Understandable by Design (Sutra) | Not covered — SR 11-7 gap | Not explicitly named as a standalone category in OWASP's LLM list | Spans MAP (context/transparency) and GOVERN |
| 5. Data Governance and Privacy | Protection (pillar); Trust is the Foundation (Sutra) | Partial — Model Development, Implementation, and Use (data quality only; doesn't address DPDP-style privacy obligations) | Categories covering sensitive information disclosure and training data poisoning | Maps most closely to NIST's GOVERN function, with MAP for data provenance |
| 6. Governance and Accountability | Accountability (Sutra); Governance (pillar) | Governance, Policies, and Controls | Adjacent to categories covering supply chain and model theft, though governance itself isn't an OWASP LLM category | Maps most closely to NIST's GOVERN function |
| 7. Agentic and Autonomous System Risk | Cross-cutting: Accountability, Understandable by Design, and Safety-Resilience-Sustainability (Sutras) | Not covered — SR 11-7 gap | Categories covering excessive agency and insecure plugin/tool design | Spans MAP (novel risk identification) and MANAGE (response planning) |
SR 11-7 is real supervisory guidance from the Fed and OCC, published in 2011 — a decade before LLMs or agentic systems existed in any form a bank would deploy. That's not a knock on the guidance; it's just math. It was never written to evaluate algorithmic fairness as a distinct validation dimension, it has no vocabulary for prompt injection or agent authorization scope, and treating it as sufficient coverage for Domains 2, 4, and 7 is the single most common gap we find in banks that have only ever validated models against SR 11-7. Extending model risk management to cover these domains isn't optional anymore — it's the difference between a validation framework built for regression models and one that actually covers what's in production.
India-specific taxonomy extensions
Global taxonomies miss categories that matter specifically in the Indian regulatory and social context, so this taxonomy adds five extensions under RBI FREE-AI's Fairness and Equity Sutra and the DPDP Act: caste proxy discrimination, religion proxy discrimination, language community fairness, DPDP consent and data subject rights, and RBI data residency requirements. These aren't theoretical. A model scoring creditworthiness using surname, pincode, or preferred-language features can reconstruct caste or religious proxies even when no such field is ever collected directly — and a fairness test built for a US or EU framework simply won't catch it, because it isn't looking for it.
How to classify a system using this taxonomy
Classifying an AI system against the taxonomy is a four-step exercise: identify which of the 7 domains apply to the system, score inherent risk, assess control effectiveness, and calculate residual risk. Zytra's own methodology scores inherent risk on a 1–16 scale (impact × likelihood) and control effectiveness on a 0–1 scale combining coverage, effectiveness, testability, and regulatory alignment; residual risk is inherent risk × (1 − control effectiveness). None of this scoring methodology is externally mandated — it's Zytra's internal risk-scoring approach, built to be defensible in an examination, not a formula lifted from RBI, the Fed, or NIST.
The first time a bank runs this exercise across its full inventory, the committee's reaction is usually the same: someone asks why a system nobody flagged as high-risk on its own deployment review is sitting at the top of the heat map. That's the taxonomy doing its job — cross-cutting risk that was invisible system-by-system becomes visible once everything is scored on the same scale.
What to do next
- Inventory every AI system against all 7 domains, not just the domain the deployment team originally flagged — most systems touch 3–4 domains, and the uncounted ones are where residual risk hides.
- Run the India-specific fairness extensions explicitly on every model that touches transaction, credit, or customer data — caste and language-community proxies don't appear unless you test for them by name.
- Treat Domains 2, 4, and 7 as SR 11-7 gaps, not SR 11-7 coverage — if your validation program's only citation for fairness, explainability, or agentic risk is SR 11-7, you have a documented gap, not a control.
- Score inherent and residual risk on one consistent scale across the whole inventory so the committee sees a portfolio heat map, not 40 disconnected per-system risk lists.
- Build the RBI FREE-AI crosswalk as an internal interpretive mapping, labeled as such — don't present any vendor's pillar mapping, including this one, as an official RBI crosswalk in examiner-facing material.
Zytra's Risk Atlas operationalizes this taxonomy at full depth — 167 individual risks across 21 domains, pre-mapped to RBI FREE-AI, SR 11-7, OWASP, NIST AI RMF, and DPDP, with inherent and residual scoring built in. If you're building a risk register from scratch across a multi-system AI estate, start with the taxonomy above before you start scoring anything.
Related: AI risk catalogue and governance
Apply a consistent AI risk taxonomy across your entire portfolio
Zytra's Risk Atlas implements the 7-domain taxonomy with inherent risk scoring, control effectiveness assessment, and residual heat maps — pre-mapped to RBI FREE-AI, SR 11-7, OWASP LLM Top 10, and NIST AI RMF. India proxy variable subcategories built in.