SR 11-7 established the baseline: model documentation must describe the training data, including source, scope, and known limitations. The DPDP Act adds consent and purpose limitation constraints that are genuinely unique to India, and those are real statutory obligations, not inferred ones.
In practice, most bank AI model documentation does describe the training data. The gap is not usually absence but precision: the training data is described but not versioned, assessed for representativeness in general terms but not for specific sub-populations, and its label quality noted as "standard credit bureau outcomes" without ever asking whether those outcomes reflect historical discrimination baked into decades of lending decisions.
This page addresses training data governance across three dimensions: quality requirements and how to test them, lineage requirements for model risk and DPDP compliance, and India-specific training data risks that international frameworks simply do not address.
Training Data Quality: Six Dimensions with Testable Criteria
1. Completeness — missing data within records. High missing-value rates in key features, if handled by imputation, embed the imputation assumptions into the model, and imputation assumptions that differ by population segment can introduce systematic bias. Test: per-feature missing rate by population segment, flagging anything above 5% for documented imputation strategy, and checking whether that strategy differs systematically across demographic or geographic groups.
2. Representativeness — training population vs. deployment population. The training dataset must represent the population the model will actually be deployed on. Gaps in representativeness translate directly into degraded performance for underrepresented groups — and that degradation tends to run in the direction of conservative rejection, which is the harder failure mode to notice because it looks like caution rather than error. Test: compare training data distribution against the deployment population across geography, product type, income tier, credit bureau score band, and — India-specific — PMJDY enrollment status, rural/urban split, and regional language.
3. Label quality — outcome labels, accuracy and bias. For supervised learning, the labels are the ground truth the model learns from. Credit default labels may be accurate as recorded payment outcomes while still being biased, if past discrimination caused some customers to never receive credit they could have repaid — their absence from the training set encodes that bias into the label distribution itself, invisibly. Test: approval-rate disparity in historical labels by proxy groups before training begins. A 30% approval-rate gap for a proxy group, alongside comparable actual risk characteristics, indicates label bias from historical discrimination, not genuine risk difference.
4. Vintage and recency — training data age relative to the deployment environment. Training data more than five years old may not represent current customer behavior, product structures, or macroeconomic conditions. Vintage risk is especially acute for models trained before 2020, since COVID-era behavioral changes may not be captured at all. Test: compare feature distributions between training vintage and current production data; a shift above 15% should trigger a re-assessment of whether the training data is still recent enough to trust.
5. Proxy variable presence — features that encode protected characteristics. Even without explicitly including protected characteristics, training data features can encode them. Pincode encodes geography, which correlates with caste and religion in India. UPI counterparty network encodes religious community. Device type and app usage encode economic class and language community. These proxy features must be identified before training, not discovered afterward when a regulator or a journalist finds them first. Test: correlation analysis between each training feature and India proxy dimensions — pincode-caste correlation via census data, UPI counterparty religious community correlation, device-language proxy correlation. Features correlating above 0.3 with protected dimensions need a documented inclusion decision.
6. Feature engineering documentation — transformation decisions that embed assumptions. Raw data transformations — binning, normalization, categorical encoding, imputation — embed assumptions about the data that affect fairness and performance. Normalizing income against a national average applies different effective scaling to regions with different income distributions. Binning credit bureau scores can cluster protected groups into the same bin as higher-risk non-protected groups, silently. Test: document each transformation decision with its underlying assumption, and check whether that assumption holds uniformly across population segments — one that doesn't is a potential source of discriminatory impact requiring design review, not just a documentation footnote.
Training Data Lineage: What Must Be Documented for Model Risk and DPDP
| Lineage element | Model risk requirement | DPDP Act requirement | Documentation evidence required |
|---|---|---|---|
| Training data source | Source systems identified; extraction method documented; transformation pipeline documented | If personal data: confirm original consent scope covers use for AI training; document lawful basis | Data lineage diagram from source system to training dataset; transformation code version-locked |
| Training data version | Training dataset versioned and hash-identified; model-dataset pair is the governance unit | Datasets containing personal data: retention period documented; deletion rights assessed | Training dataset hash stored in model registry; model card includes dataset version reference |
| Training date range | Observation period start and end; minimum outcome observation period for credit labels | Data used must stay within original consent retention scope | Training window documented in model card; outcome observation period meets typical model-risk minimum (generally 12+ months) |
| Exclusions and filters | Excluded records documented with rationale; exclusions differing by population segment require fairness assessment | Systematic exclusion of population segments may affect consent representativeness | Exclusion criteria documented; exclusion rate by key population segments; fairness assessment if exclusion differs by proxy group |
India-Specific Training Data Risks
Historical discrimination encoded in training labels. India's banking system has had unequal credit access across caste, religion, and language communities for structural reasons — geographic distribution of bank branches, language requirements for branch banking, land titling patterns that affect collateral access. Credit AI trained on historical approval decisions inherits this unequal access as a statistical signal, whether anyone intended it or not. Banks training on pre-2010 data carry higher label bias risk; banks training on pre-PMJDY data have thin-file representation gaps for inclusion customers. A training data governance program for Indian banking AI needs a historical discrimination screen — comparing pre-training approval rates across proxy groups — before training begins, not as a post-hoc fairness audit once the model is already in production and the finding is harder to act on.
DPDP Act consent for training data. Under the DPDP Act, 2023, a bank that collected customer data under a privacy notice that didn't specify AI model training as a purpose may need to update its consent mechanism before using existing customer data for new AI training rounds. This matters particularly for banks that collected data under pre-DPDP consent frameworks. New AI training projects should have a data sourcing assessment as a governance gate: confirm the training data's consent basis actually covers AI training as a purpose, or use anonymized or synthetic data instead — and "we'll figure out consent later" is not a governance gate, it's the absence of one.
Regional language training data gaps. For AI systems that process text — document extraction, customer communications, chatbots — training data in regional Indian languages is systematically scarce compared to Hindi and English. Models trained primarily on Hindi and English data will underperform on inputs in Bengali, Tamil, Telugu, Marathi, Gujarati, and other regional languages. In a country where a significant share of banking customers, particularly in priority sector lending, transact primarily in regional languages, this underrepresentation translates directly into a service quality disparity by language community. Training data governance for text AI needs a language coverage assessment, and deployment to regional language communities should account for the resulting performance gaps rather than assume they average out.
Training Data Governance Action Checklist
- Run a historical discrimination screen — approval-rate disparity by proxy group — on training labels before the next credit model build, not after deployment surfaces a fairness finding.
- Version and hash every training dataset in the model registry; "described but not versioned" should not survive the next validation cycle.
- Confirm the consent basis for any personal data used in AI training explicitly covers that purpose — audit pre-DPDP-era data sourcing specifically.
- Add a language coverage assessment to the training data checklist for any text-processing AI, with explicit performance testing per regional language, not an aggregate score.
- Document every feature engineering transformation with its underlying assumption and check that assumption against population segments — not just against the aggregate dataset.
Related: AI data and model governance
AI training data governance — India proxy variable screening, DPDP consent verification, lineage tracking
Zytra's training data governance module screens each training dataset for India proxy variable correlations, DPDP consent basis, label bias indicators, and representativeness gaps before training begins. Version-locked training dataset records are maintained alongside model registry entries for examination evidence.