AI Compliance & Regulatory Risk for Indian Banks and NBFCs

The Reserve Bank of India has not issued a single consolidated circular on AI in lending, but its regulatory expectations are clearly articulated across several frameworks: the Guidelines on Digital Lending (2022), the IT Framework for NBFCs (2017 and subsequent updates), the Master Direction on Know Your Customer (2016, updated 2023), and the Fair Practices Code for lenders. Collectively, these create a clear standard: AI-assisted lending decisions must be explainable, auditable, non-discriminatory, and subject to human accountability.

The Digital Lending Guidelines specifically require that credit assessment models - whether traditional scorecards or AI/ML models - must be documented, validated, and subject to model risk management governance. Lenders must be able to explain to a borrower why their loan was rejected, which means black-box AI models that cannot articulate a rejection reason are non-compliant. LLM-based agents that produce structured, plain-language credit rationales are inherently more compliant than opaque ML classifiers.

RBI's IT Framework requires that all technology systems, including AI systems, have documented risk assessments, change management controls, vendor due diligence, and incident response plans. If you deploy an AI agent from a third-party vendor like LendingIQ, you remain responsible for ensuring the vendor meets RBI's IT outsourcing standards, including data residency, audit access, and SLA requirements.

The Digital Personal Data Protection Act, 2023 establishes the legal framework for processing personal data in India and has significant implications for AI agents in banking, which by definition process large volumes of sensitive personal and financial data. The key obligations for banks and NBFCs operating AI agents are: consent management, purpose limitation, data minimization, retention controls, and the right of individuals to access and correct their data.

For AI agents, the consent challenge is most complex: when a borrower applies for a loan, the bank needs clear consent not just for processing their application, but for each data source the AI agent will access - bureau reports, GST data, bank statement APIs, employment verification services. The consent framework must be granular enough to cover AI-specific data use, and the borrower must be informed that an AI system is involved in their credit assessment.

Purpose limitation means your AI agent cannot use data collected for credit assessment to train a general marketing model, or share insights derived from one customer's data profile with another customer's assessment. Each agent's data access must be scoped to its stated purpose, and this scope must be documented and auditable.

Model Risk Management (MRM) for AI agents follows the same principles as MRM for traditional credit scoring models, but with additional considerations specific to LLM-based systems. The core MRM framework requires: model documentation, independent validation, performance monitoring, periodic review, and governance oversight.

Model documentation for an LLM-based agent must cover: the underlying model used (for example, Claude Sonnet 4 via AWS Bedrock), the system prompt and its rationale, the tools and data sources the agent accesses, the agent's decision authority boundaries, known limitations and failure modes, and the evaluation methodology used before deployment. This documentation package is what an RBI inspector would expect to review.

Independent validation means someone other than the team that built the agent must test it against your golden dataset and confirm that its performance meets the bar required for its intended use. For high-stakes functions like credit underwriting, this validation should be performed by your model risk or internal audit team before go-live, and repeated annually or whenever the underlying model is updated.

Yes, AI agents can exhibit bias - both the LLM they are built on and the data they are trained or evaluated on can encode historical patterns of discrimination. In lending, this is a critical risk because biased credit decisions are both ethically wrong and legally problematic under India's fair practices frameworks. Banks deploying AI agents must actively test for bias, not assume its absence.

The most common forms of bias in lending AI are: demographic bias (the agent approves loans at a systematically different rate for applicants from certain regions, genders, or communities, when controlling for creditworthiness), proxy bias (using a variable like pin code or employer type that is correlated with a protected characteristic), and feedback loop bias (the agent is evaluated on historical approval/rejection data that itself reflected biased human decisions).

Testing for bias requires a structured audit: run a sample of applications through the agent after anonymizing personally identifying information, then analyze approval rates, credit limits, and interest rate recommendations across demographic segments. Any statistically significant difference not explained by legitimate credit variables - income, bureau score, repayment history - is a potential bias signal that requires investigation.

AI agents in banking introduce three categories of security risk that do not exist with traditional software: prompt injection attacks (malicious inputs designed to override the agent's instructions), data leakage through the LLM layer (the model inadvertently revealing information from one customer's data in another's session), and supply chain risk from the LLM provider (the model vendor's systems being breached or the model being updated in ways that change agent behavior).

Prompt injection is the most immediately exploitable risk. An attacker could submit a loan application containing hidden instructions - in white text, in metadata, or embedded in a PDF - that try to override the agent's behavior. Well-designed agents have injection-resistant prompt structures that separate data inputs from instruction inputs architecturally, and validate that inputs are in expected formats before processing.

Data leakage is mitigated through session isolation - each agent interaction should operate in a clean context with no memory of previous sessions. Each borrower's data should be scoped to their own session and never included in another session's context.