What AI compliance regulations apply to banks?

Banks face AI compliance obligations from multiple regulators simultaneously. In India: RBI's 2024 AI Circular (mandatory, applies to all scheduled banks and NBFCs — requires board-approved governance framework, audit trails for all production AI, explainability for customer-facing decisions); RBI FREE-AI Framework (effectively mandatory — examination benchmark for BFSI AI governance covering Fairness, Reliability, Explainability, Ethics, Security); RBI draft eMRM guidelines (extends model validation requirements to AI/ML including LLMs); DPDP Act 2023 (applies to AI systems processing personal data — ₹250Cr per-incident penalty for unauthorized processing). For US-regulated banks: SR 11-7 (model risk management — applies to AI models used in material business decisions). For banks with EU operations: EU AI Act (mandatory for high-risk AI systems including credit scoring, fraud detection, employment screening — Art. 9 risk management, Art. 10 data governance, Art. 12 logging, Art. 15 robustness testing, Art. 26 deployer obligations). Singapore operations: MAS TRM §12 and FEAT Principles.

What does RBI's 2024 AI Circular require from banks?

RBI's 2024 AI Circular requires banks to: (1) maintain a board-approved AI governance framework covering all production AI systems — the board must approve the framework, set AI risk appetite, and receive regular AI governance reports; (2) maintain audit trails for all production AI systems — the audit trail must be able to connect any AI-assisted decision to the governance chain (validation status, monitoring status, approval records); (3) ensure explainability for customer-facing AI decisions — where a customer is denied credit or service based on AI output, the bank must be able to explain the basis; (4) include AI risk in the bank's overall risk management framework — AI risk is not a separate topic, it is a component of operational risk; (5) report material AI incidents to RBI within regulatory notification timelines. The 2024 AI Circular applies to all scheduled commercial banks and NBFCs operating under RBI supervision. The FREE-AI Framework provides the detailed control requirements for each obligation; the eMRM guidelines extend the obligation to model validation procedures.

How do banks prepare for an AI compliance examination?

Banks prepare for AI compliance examination by ensuring four things are examination-ready: (1) Model inventory — current, complete, risk-tiered list of all production AI systems including vendor models. Examiners ask to see this first. An inventory that has not been updated since deployment signals ungoverned AI deployment. (2) Board governance documentation — board-approved AI governance framework, AI risk appetite statement, evidence of board AI reporting. Without this, no subsequent evidence is treated as formally governed. (3) Validation evidence for Critical and High tier models — validation reports, adversarial testing results, fairness assessment, issue tracking and resolution. (4) Audit trail sample — for at least one production AI system, a sample audit trail showing an AI-assisted decision connected to its governance chain. RBI's most common examination finding is that banks cannot produce this — they have inference logs but cannot connect them to governance records.

AI Compliance for Banking: RBI, SR 11-7, EU AI Act — Complete Obligations Guide

Compliance teams at Indian banks are currently building three governance programs when they think they're building one, because RBI, SR 11-7 (for banks with US exposure), and the EU AI Act (for anyone with EU-facing operations) don't share a vocabulary, an evidence format, or an examination calendar. A bank that treats these as three separate projects ends up with three incomplete programs. A bank that treats them as one risk-management program with three sets of evidence requirements ends up examination-ready for all three at once.

RBI's active obligations

What is not in dispute is the substance examiners are asking for in practice: a board-approved AI governance framework, a model inventory with risk tiering, audit trails for production AI systems, and explainability for customer-facing decisions. Treat the specific circular citation as something to verify, not the underlying expectation.

What a bank can usefully pull from the report's risk-mitigation recommendations, regardless of how you label them, is the expectation of India-specific bias testing, decision-level explainability, genuine human oversight, and adversarial robustness testing for any system exposed to manipulation.

The draft eMRM guidelines extending model risk management to AI/ML — including independent validation for vendor models — are real work in progress at RBI; banks should treat "effectively mandatory examination benchmark" as directionally correct but build in the expectation that final requirements may shift before they're formalized, rather than freezing a compliance program against a draft.

SR 11-7 and the EU AI Act — the parts that are solid

SR 11-7 (the Fed/OCC's 2011 model risk management guidance) genuinely does now get applied to AI/ML models in US examinations, and the gap the original article identifies — that SR 11-7's performance-monitoring framework doesn't catch behavioral drift in an LLM that still looks fine on average — is a real and well-documented problem, not an exaggeration. If your US-exposed bank's MRM committee is tracking LLM "performance" the same way it tracks a credit scorecard's Gini coefficient, it is missing the failure mode that actually bites first.

The EU AI Act citations hold up on inspection: high-risk classification does sweep in credit scoring and fraud detection, Articles 9/10/12/15/26 carry the obligations described, Article 73 does require serious-incident notification within 15 working days, and the penalty tiers (up to €35M or 7% of global turnover for prohibited AI; up to €15M or 3% for high-risk violations) match the regulation as enacted. Indian banks with even modest EU-facing operations tend to underestimate how inclusive the high-risk classification is — "we don't do credit scoring in the EU" is rarely actually true once you trace which systems touch an EU resident's data.

DPDP Act — real exposure, overstated arithmetic

The DPDP Act's data-fiduciary obligations and breach-notification duties are real and apply to any AI system processing personal data of Indian residents. Where the compliance narrative gets ahead of the law is the claim that a single AI processing failure affecting a million transactions is automatically a million separate penalty events — that's a plausible way to size the tail risk, not a rule the Data Protection Board has established through enforcement. Either way, the practical lesson is the same: at banking transaction volumes, even a narrow AI compliance gap is not a small problem.

Building one program instead of three

NIST AI RMF's GOVERN/MAP/MEASURE/MANAGE structure is a reasonable methodology to hang all three regulatory tracks on, precisely because NIST doesn't prescribe specific controls — it gives you the skeleton, and each regulator's specific requirements become the muscle attached to it. One model inventory, one validation program, one audit trail, reformatted for whichever regulator is asking, beats three parallel documentation efforts every time a bank has actually tried both approaches.

What to do this quarter

Confirm the exact RBI circular and section numbers your compliance documentation cites — don't let an invented or outdated citation undercut an otherwise solid program.
Re-map FREE-AI-related documentation to the actual Sutras and recommendations in the committee report, not a five-letter acronym.
Extend your SR 11-7 (or SR 11-7-equivalent) monitoring to behavioral consistency testing for any LLM, not just output-quality metrics.
Re-check EU AI Act high-risk classification for every AI system that touches an EU resident's data, even indirectly — the scope is wider than most banks initially assume.
Build one model inventory and one audit trail that feed all three regulatory evidence formats, rather than maintaining three separate documentation trails.