AI Fairness in Banking: Why Standard Fairness Testing Is Insufficient for India — India-Specific Proxy Variables, Disparate Impact Methodology, and What RBI FREE-AI Requires

Run a standard Western fairness audit on an Indian credit book and it will tell you the model doesn't discriminate by gender or age — and it will tell you nothing about whether it's discriminating by caste, because caste was never a variable the audit was built to look for. That's not a limitation of the specific toolkit; IBM's AIF360 and Google's What-If Tool were built against US and EU protected-class definitions, and no bank collects caste or religion as a model feature, so there's nothing for a standard audit to directly test against. The discrimination, when it happens, is routed through proxies — variables the bank does collect that happen to correlate with the characteristic it never asked about.

Caste proxies hide in geography and surname, not in any field labeled "caste"

Pincode-level residential concentration carries real signal in many Indian cities, where historically marginalized communities remain geographically clustered as a legacy of settlement patterns — a credit model using pincode for geographic risk pricing can be quietly pricing by caste without anyone writing that intent anywhere. Surname patterns carry statistically meaningful caste correlation across multiple Indian linguistic regions, which means any model with name-derived features (even indirectly, through a linked database field) has a caste-proxy risk that a standard audit will never flag because "surname" doesn't appear on anyone's protected-characteristic list.

Religion, language, and disability proxies follow the same pattern through different variables

Counterparty names in payment and beneficiary histories, employer and business names, and transaction timing around religious observance can all carry religious-community signal — a fraud model that over-flags transactions to religious institutions as "unusual timing" is discriminating without a single religion field anywhere in its training data. Language-group proxies show up in mobile network carrier, device language settings, and even the script used in UPI payment descriptions; disability proxies show up in screen-reader usage, interface modality preference, and how long someone takes to complete a digital transaction. None of these require the bank to know anything explicitly — that's exactly what makes proxy discrimination hard to catch and genuinely dangerous to ignore.

The testing methodology has a step most banks skip: proving causation, not just correlation

Identify which features in a given deployment plausibly proxy for a protected characteristic — this is domain knowledge about Indian socioeconomic patterns, not a statistical routine you can run blind. Build a proxy indicator by correlating the feature against publicly available demographic data (census, academic research on India's geographic and social patterns) without ever collecting the protected characteristic directly. Measure outcome disparity across proxy groups — approval rates, pricing, false-positive rates in fraud detection — using the four-fifths ("80%") rule as an internal investigative trigger; note that this threshold originates from US EEOC employment-discrimination guidance, not Indian statute, so use it as a signal to investigate, not a number to cite as a legal bright line to an Indian examiner. The step banks skip most often is the fourth one: determining whether a found disparity reflects a legitimate risk factor that happens to correlate with geography, or actual discrimination riding on the proxy — skipping this step means you either over-remediate a legitimate risk signal or under-remediate real discrimination, and you won't know which until you've done the causal work.

Remediation has to close the loop, not just flag the finding

Where the investigation finds discrimination rather than legitimate risk, remediate through feature removal, re-weighting, or post-processing constraints, then re-test against the same proxy groups to confirm the fix actually worked. The complete cycle — initial finding, causal investigation, remediation action, post-remediation test result — is the examination evidence that matters; a fairness report that stops at "we found a disparity" without showing what happened next reads as an admission with no resolution attached, which is a worse position than not having tested at all.

Action checklist for India-specific fairness testing

1. Map every credit, fraud, and underwriting model's features against the four proxy categories — caste (pincode, surname), religion (counterparty name, geography, timing), language (mobile/device signals), disability (device usage, interaction mode) — before assuming standard demographic testing covers you.
2. Build proxy indicators using publicly available demographic data, without collecting protected characteristics directly as model features.
3. Use the 80% rule as an internal investigative trigger, not a legal citation, and always complete the causal-investigation step before concluding a disparity is or isn't discrimination.
4. Remediate and re-test every confirmed discrimination finding — document the full cycle, not just the initial result.
5. Repeat this testing on a recurring production cadence, not only at model launch, since proxy relationships shift as your customer base and feature distributions change.