The most common reason a validation team returns a model to the developer without completing a validation opinion is incomplete documentation — not a failed model, an undocumented one. A model whose training data is described but not versioned, whose feature engineering decisions are summarized but not specified, and whose evaluation metrics are reported but not justified, cannot be independently validated to the standard SR 11-7 and current RBI supervisory expectations call for.
Documentation is not a formality completed after model development. It is a governance gate that determines whether validation can even begin. Banks whose AI development processes treat documentation as a post-development activity will consistently see delays in the validation pipeline, because validators return models to developers for documentation completion rather than proceed on incomplete inputs — and the delay always lands at the worst possible moment, right before a deployment deadline someone already committed to.
This article covers the documentation requirements for AI models in banking: what must exist before validation begins, what AI documentation requires beyond the SR 11-7 baseline, and the model card format that makes AI portfolios governable at scale.
AI Model Card: Eight Sections for BFSI
1. Identity and governance status. Model name, version, and model registry ID; deployment date and current environment; model owner as a named individual, not a role or team; current validation status and date of last validation; open validation findings and remediation status; next scheduled re-validation date.
2. Intended use. Specific approved use cases, not general categories; geographic and product scope of approved use; customer population scope the model is validated for; explicitly prohibited uses; human review requirements for decisions that need an override path.
3. Training data. Training dataset summary, version identifier, and hash; data sources and extraction methodology; observation date range and outcome window; population scope and known representativeness gaps; proxy variable presence assessment (for India: pincode, UPI, language); label quality assessment and historical bias screen result.
4. Model architecture. Architecture and hyperparameter specification, with final hyperparameters locked at deployment; model family (gradient boosting, neural network, LLM, etc.); feature list with engineering decisions per feature; missing value handling and imputation strategy per feature; for LLMs, base model identifier, version, and fine-tuning approach; for RAG systems, knowledge base version and retrieval configuration.
5. Performance. Primary evaluation metric with selection rationale; performance on holdout and out-of-time test data; performance by key sub-populations, including PMJDY, rural, and regional-language segments; acceptable performance threshold below which the model is suspended; benchmark comparison against the prior model version and any challenger model.
6. Fairness. Fairness metrics and results for the approved population scope; India proxy variable fairness assessment across pincode, UPI, language, and device dimensions; intersectional group analysis results; disparate impact ratios for key proxy group pairs; known fairness limitations and any deployment restrictions.
7. Limitations. Known failure modes, out-of-distribution scenarios where performance degrades, population segments with known lower performance, adversarial patterns the model is vulnerable to, economic scenarios not represented in training data, and the time horizon beyond which model reliability degrades.
8. Change history. A full list of changes since last validation, each classified Major/Minor/Patch; whether re-validation was triggered and, if not, the rationale for exemption; fairness re-testing on any change affecting fairness-sensitive features; a version control log for the feature engineering pipeline. This section is where most model cards quietly go stale — someone updates the feature list but forgets to log the change, and six months later nobody can reconstruct what actually happened between validations.
AI Documentation Gaps: Where Banks Commonly Fall Short
| Documentation element | Gap pattern | Validation consequence | Examination finding risk |
|---|---|---|---|
| Training data version | Training data described but not versioned; model registry records the source system but not the specific dataset snapshot used | Validator cannot verify the training data representativeness claim; limitation findings cannot be reproduced | Medium — incomplete MRM documentation; model may not be examination-defensible if challenged |
| Feature engineering decisions | Feature list documented but transformation decisions are not — "income was normalized" without the normalization function and reference population | Conceptual soundness review incomplete; potential proxy discrimination from feature engineering is not assessable | High — fairness assessment requires feature engineering documentation; the gap creates proxy discrimination finding exposure |
| India proxy variable assessment | No proxy variable correlation analysis conducted or documented; fairness treated as demographic variable analysis only | Fairness validation incomplete against current India fairness expectations | High — India-specific fairness finding likely on examination |
| LLM system prompt version | LLM documented by base model name and version only; system prompt not versioned or included in the model card; prompt changes not treated as model changes | Behavioral assessment of the LLM is not possible without the current system prompt; change management assessment incomplete | Medium — agentic and LLM governance gap; examination finding for agentic AI without documented behavioral scope |
| RAG knowledge base version | RAG AI documented as "uses company knowledge base" without a recorded KB version; KB updates not treated as model changes | Model behavior cannot be reproduced at any past point in time; validation findings may not apply to the current KB version | Medium — operational risk finding; incident investigation and examination defense require reproducibility |
India-Specific Model Documentation Requirements
India banking AI model documentation needs three elements beyond the SR 11-7 baseline.
India proxy variable documentation. Whatever its exact regulatory status, this assessment — caste via pincode, religion via UPI counterparty, language via device type and app usage — is not optional for credit AI in practice. A model card documenting only standard demographic fairness analysis, however rigorous by international standards, is incomplete for India BFSI deployment.
PMJDY population sub-population performance documentation. For banks with financial inclusion lending mandates, model documentation must include a performance assessment specific to the PMJDY segment. Aggregate-level metrics alone can hide materially worse performance on PMJDY-enrolled customers. Banks that can show PMJDY sub-population performance documented and within acceptable bounds are in a measurably stronger examination position than banks reporting aggregate metrics alone.
Regional language scope documentation. For AI systems that process or produce text, the model card must document which languages the model supports, what performance testing was conducted in each, and what deployment restrictions follow from language-specific performance. An AI customer service system tested only in Hindi and English but used by customers who transact in regional languages has a documentation-to-deployment gap the model card should surface, not hide by omission.
Model Documentation Action Checklist
- Audit the last five models sent to validation for how many were returned for incomplete documentation — if it's more than one, documentation is a process problem, not an individual oversight.
- Add training dataset version hashing to the model registry if it isn't there already; "described but not versioned" is the single most common validator complaint.
- Require India proxy variable correlation analysis in the model card template for every credit, fraud, or pricing model, regardless of how the requirement is currently sourced in policy.
- Version LLM system prompts and RAG knowledge bases in the model registry and treat changes to either as model changes requiring re-validation assessment.
- Add PMJDY and regional-language sub-population performance fields to the standard model card template rather than producing them ad hoc when an examiner asks.
Related: AI model governance
AI model documentation — 8-section model cards, India proxy variable fields, training data version control, documentation-gated validation workflow
Zytra's model registry generates 8-section model cards with India-specific fields built in. Training dataset version hashing, LLM system prompt versioning, and RAG knowledge base version tracking integrated. Documentation completeness gates validation submission — no partial documentation reaches the validation queue.