AI Compliance Checklist for Banking: 42 Requirements Across RBI, SR 11-7, EU AI Act, and DPDP Act

Most banks fail their first AI examination not because they lack controls, but because they cannot produce the controls on demand. An examiner doesn't ask "do you have a fairness policy" — they ask for the disparate-impact test results on last quarter's credit book, and the gap between "we have a policy" and "here is the test output" is where most institutions get cited. An Indian bank's realistic minimum compliance stack is the RBI's IT governance and outsourcing master directions, the non-binding but increasingly examined FREE-AI committee report, and the DPDP Act 2023. Capital markets operations add SEBI's AI/ML disclosure obligations; an insurance subsidiary adds IRDAI; EU-facing credit or lending activity adds the EU AI Act. This checklist sequences the 42 requirements that produce the fastest examination readiness, not the ones that look best in a slide deck.

Model inventory and risk tiering — the item examiners check first

An examiner's opening question is almost always "show me the inventory," and a bank that cannot produce a complete list of every production AI system — including vendor AI and AI embedded inside third-party platforms — has already failed the first test. Every model needs a risk tier (Critical/High/Medium/Low/Minimal) with a written rationale, because an unexplained tier assignment reads as arbitrary to a reviewer. Vendor attestations do not substitute for independent validation on Critical or High tier models; the bank remains accountable for the model's behavior regardless of who built it. Treat autonomous agents executing financial workflows as Critical or High tier by default until a specific risk assessment says otherwise — defaulting an agent to "Low" because no incident has happened yet is the single fastest way to draw examiner scrutiny.

Audit trail and evidence chain — what "logging" actually has to reconstruct

Standard application logs capture what an LLM output was, not why it produced that output — missing the prompt, retrieved context, conversation history, and model version at the moment of inference. Forensic replay — the ability to reconstruct the exact context state behind any past inference — is what turns a log file into regulatory evidence. Hash-chain the records so a reviewer can verify nothing was altered after the fact, and tag every inference with the model version that produced it. DPDP Act data principal inquiries ask a narrower question than regulators assume: what decision was made and on what basis, answerable through access and correction rights — not an automated-decision override right the Act doesn't actually grant.

Fairness and bias — why Western toolkits miss the Indian risk surface

Disparate impact testing against gender, age, and geography is table stakes; it is also insufficient on its own for an Indian deployment. Pincode, surname, and geographic-concentration variables can proxy for caste or religious community membership even when the bank never collects that data directly, and standard fairness libraries (IBM AIF360, Google's What-If Tool) were not built to test for these proxies. Run this testing before deployment and again on a recurring cadence in production, because a model that passed fairness testing at launch can drift as the customer base and feature distributions shift. Document the statistical methodology in a form a non-technical examiner can follow — a results table with no explanation of the test design will generate more questions than it answers.

Explainability — the SHAP-versus-LIME decision that creates examination risk

SHAP values are consistent between an individual explanation and the model's global behavior; LIME's local approximations can contradict what the model does overall, which is exactly the kind of inconsistency an examiner will seize on. Any customer-facing AI decision needs to be explainable in plain language within a defined turnaround — treat 48 hours as a reasonable internal SLA, not a figure fixed anywhere in Indian statute. Boards don't need per-model SHAP dumps; they need a residual-risk heat map by domain, because a board member asked about "the fairness of the AI program" should be able to answer from memory, not from a 40-page appendix.

Security, monitoring, and lifecycle — treat retraining as a new deployment

Cover the OWASP LLM Top 10 for every LLM deployment, with runtime detection for prompt injection rather than a policy memo that says injection "should not happen." Adversarial robustness testing matters most for credit and fraud models, where a motivated actor has direct financial incentive to find the model's blind spots. Agentic AI needs a written authorization manifest — what the agent can and cannot do, and which actions require a human checkpoint before execution — because "the agent behaved correctly in testing" is not a control once it's running unsupervised in production. Treat every retraining event as a new deployment subject to the same validation and sign-off as the original model; a quietly retrained model is an unvalidated model wearing the old one's approval.

Action checklist before your next examination

1. Produce a complete AI inventory including vendor and embedded AI, with a documented risk tier for each system.
2. Stand up inference-level logging with forensic replay for every LLM deployment — not sampling, every inference.
3. Run India-specific proxy variable testing (pincode, surname, language, device-usage proxies) on every credit, fraud, and underwriting model, then repeat it on a fixed cadence.
4. Replace any LIME-based explanation pipeline with SHAP for Critical and High tier models before an examiner asks why the two disagree.
5. Write the agentic AI authorization manifest and human-checkpoint rules before any agent goes into production, not after an incident.