AI Data Governance for Banking: Training Data Quality, Feature Store Controls, DPDP Act 2023 Compliance, and the India Proxy Variable Problem No International Framework Addresses

AI data governance for banking isn't the same discipline as data management for AI. It's the layer that connects what your data team does — labeling, versioning, access control — to what a specific regulator will ask you to prove. A bank whose training data sails through every quality check can still fail an RBI fairness review if nobody ever tested the model's features for caste, religion, language, or disability proxies. A bank with an immaculate data quality pipeline can still sit exposed under the DPDP Act if KYC data collected for onboarding got repurposed into a training set without anyone documenting a legal basis for that second use. Good data hygiene and defensible data governance are not the same thing, and the gap between them is where exam findings and regulatory notices live.

This article covers what RBI's FREE-AI framework, the DPDP Act 2023, and India's own demographic data landscape actually require of a bank's data governance function — not what a generic AI-governance template assumes they require.

What RBI's FREE-AI framework actually requires of training data and feature stores

RBI released the "Framework for Responsible and Ethical Enablement of AI (FREE-AI) in the Financial Sector" on 13 August 2025, built from the recommendations of a committee chaired by Prof. Pushpak Bhattacharya of IIT Bombay, convened in December 2024. The framework rests on 7 Sutras — Trust is the Foundation, People First, Innovation over Restraint, Fairness and Equity, Accountability, Understandable by Design, and Safety-Resilience-Sustainability — operationalized through 6 strategic pillars: Infrastructure, Policy, Capacity, Governance, Protection, and Assurance. It carries 26 recommendations in total.

What follows is not an official RBI numbering — it's our mapping of concrete data-governance obligations onto the Sutras that actually drive them, because that's the structure a bank's data team needs to plan against.

Fairness and Equity. This Sutra is where India-specific exposure concentrates, and it's the one most teams underestimate. It calls for training data representation bias assessment, proxy variable testing (caste, religion, language, and disability proxies specific to the Indian context), protected-characteristic correlation analysis, and demographic group performance comparison. In our experience this is the single most commonly examined area in practice, and the one with the widest gap between what international vendors ship and what an India-based fairness review actually asks for.

Safety-Resilience-Sustainability. This covers training data representativeness — documented and tested, not just assumed — plus concept drift monitoring, data drift monitoring, and documentation of seasonal variation and geographic coverage gaps. Feature store versioning controls fall here too: if you can't reconstruct which feature definition version produced a given prediction six months ago, you can't demonstrate resilience when asked.

Understandable by Design. This is the Sutra behind feature importance documentation per model, SHAP value retention per decision (needed for what we call Forensic Replay — reconstructing why a specific past decision came out the way it did), a clear line between personal-data-derived features and purely derived features, and plain-language translations of what a feature actually measures. It overlaps directly with DPDP Act data subject rights, covered below.

Trust is the Foundation / Accountability. This is where training data integrity verification, data poisoning attack detection, pipeline access controls, and — increasingly, as agentic AI systems pull context from RAG retrieval at inference time — feature substitution attack detection for real-time inference all sit. Agentic AI's live data-integrity surface is new enough that most banks' existing data governance playbooks were written before it existed, which is exactly why it keeps showing up as a gap in assurance reviews.

The India proxy variable problem: four categories no international framework was built to catch

This is Zytra's own analytical framework, developed from working inside Indian bank fairness reviews — not a taxonomy RBI or any other regulator has published verbatim. We think it holds up because it maps onto how proxy discrimination actually shows up in India-specific data, which off-the-shelf fairness tooling built for US or EU demographic categories simply doesn't test for.

Caste proxies. Pincode clusters, surname patterns, and school or college names can each carry caste signal on their own, and the correlation gets stronger when a model combines two or three of them. A credit model that never sees a "caste" field can still functionally discriminate on it.

Religion proxies. Counterparty name patterns in UPI or NEFT transaction data, geographic concentration scores, and festival-linked spending clustering all carry religion signal. A transaction-monitoring model built on spending pattern features can pick this up without anyone intending it to.

Language proxies. Mobile platform usage, social network patterns, and app usage segmented by language each correlate with linguistic — and often regional or community — identity. These features are common in engagement and risk-scoring models precisely because they're predictive, which is exactly the problem.

Disability proxies. Device usage patterns, transaction channel choice, and input method patterns (voice vs. touch vs. assisted) can function as disability proxies, especially in models that score "customer effort" or channel-switching behavior as a risk signal.

We've seen a bank discover, two years into production, that a surname field entered during onboarding — kept purely for KYC matching — had been silently functioning as a caste proxy inside a cross-sell propensity model the whole time. Nobody flagged it at build time because nobody ran proxy correlation testing on it; it passed every standard data-quality check because it was clean, well-formatted data. That's the failure mode this section exists to prevent: proxy testing has to happen before deployment, on every feature that touches geography, name, device, or channel, not just on fields explicitly labeled "sensitive."

What the data governance team must do: run proxy correlation testing against pincode, surname, counterparty-name, device, and channel features before any model touching credit, underwriting, or risk scoring goes live, and re-run it whenever the feature set changes — not just at initial validation.

DPDP Act 2023: what each data governance requirement actually demands

1. Purpose limitation — repurposing data requires a fresh legal basis, and the penalty depends on what goes wrong

If your bank wants to use KYC data collected for onboarding to train an AI model, you need documented consent or another valid legal basis for that new purpose — repurposing without one is a Section 4/Section 6 problem regardless of how good your security is.

Don't conflate two separate exposures here, because they carry very different penalty bands. Unauthorized repurposing on its own — using personal data for a purpose the data principal never consented to, with no resulting breach — falls into the Act's residual contravention band, capped at up to ₹50 crore, and the Data Protection Board would assess it case by case. The ₹250 crore figure is Section 8(5)'s ceiling specifically for failing to implement reasonable security safeguards where that failure results in an actual personal data breach. Unauthorized repurposing becomes a ₹250 crore problem only if it also causes, or is bundled with, a security-safeguards failure that leads to a breach — the repurposing itself doesn't carry that number.

In practice this means your purpose-limitation control and your security-safeguards control are two separate line items on your compliance matrix, not one. Treat them as one and you'll either over-state your risk in board reporting or under-build the control that actually caps your exposure at ₹50 crore instead of ₹250 crore.

2. Data subject rights — customers can ask which of their data drove an AI decision

Customers have the right to know which personal data features drove a given AI decision about them. That means your bank has to retain feature values and SHAP contributions per decision, not just the model's final output — a loan rejection with no retrievable feature trail doesn't satisfy this. This overlaps with EU AI Act Article 86, which grants a comparable right to an explanation of individual decision-making for high-risk AI systems; if you're already building Article 86 compliance, the DPDP data-subject-rights infrastructure is largely reusable.

3. Data minimization — "document your feature selection" is not a standard; showing your work is

Models with 200-plus features, many pulling directly from personal data, struggle to satisfy data minimization if a smaller feature set gets comparable performance. The usual advice here — "document your feature selection methodology" — is close to useless without specifying what that document has to contain.

A defensible feature-selection justification needs three things: ablation testing showing what happens to model performance when each personal-data feature is removed, a marginal predictive-power ranking showing how much lift each feature actually contributes versus the next-best alternative, and a written rationale for every personal-data feature that survives the cut, tied to a specific performance threshold the bank has pre-committed to. "We tested removing it and performance held" is not the same as showing the ablation numbers.

This is also the conversation every data governance lead eventually has with a data science team that wants all 200 features because more features generally help at the margin. The data science argument is usually correct on pure model performance. It just isn't the only input — a feature that buys 0.3% AUC lift but carries unminimized personal data is a regulatory liability the model's performance metric doesn't price in, and the governance team's job is to make that trade-off explicit and documented rather than resolve it by default in whichever direction nobody pushes back on.

4. Grievance pathway — customers need somewhere to contest an AI decision, and you need to be able to answer them

The Act requires a documented complaint pathway for AI-driven decisions, and that pathway has to actually reach the decision's feature values and the model's explanation — not just route to a generic customer service queue that can't see inside the model. A bank without Forensic Replay capability — the ability to reconstruct a past decision's exact feature values and explanation after the fact — cannot satisfy this for decisions made months or years earlier, even if it builds a perfect grievance process going forward. Retrofitting Forensic Replay onto decisions you didn't instrument for it at the time is often impossible; the data simply wasn't captured.

Action checklist: what the data governance team should do this quarter

1. Re-map your FREE-AI compliance tracker away from any invented "Pillar 1–5" numbering and onto the actual Sutras (Fairness and Equity; Safety-Resilience-Sustainability; Understandable by Design; Trust is the Foundation/Accountability) and the 6 strategic pillars — if a vendor or internal deck hands you numbered pillars, verify against the August 2025 framework text before building controls against it.
2. Run proxy correlation testing on every model touching credit, underwriting, or risk scoring against pincode, surname, counterparty-name, device-usage, and channel-choice features — before deployment, and again on every feature-set change, not just at initial validation.
3. Split your DPDP penalty exposure into two separate line items: purpose-limitation/repurposing risk (up to ₹50 crore, case-by-case) and security-safeguards-failure/breach risk (up to ₹250 crore under Section 8(5)) — don't let one control gap hide behind the other's number in board reporting.
4. Require ablation testing and marginal predictive-power analysis as a condition of sign-off for any model with more than roughly 100 features touching personal data — not a narrative document, an actual per-feature performance delta.
5. Build Forensic Replay capability now, not when the first grievance arrives — retain feature values and SHAP contributions per decision at inference time, because you cannot reconstruct this retroactively for decisions already made.

No international vendor has built proxy variable testing for caste, religion, language, and disability proxies, DPDP feature-level disclosure for past AI decisions, or feature store lineage with personal data tagging and purpose tracking specifically for India BFSI. That gap is the reason this analysis exists.