Machine learning and AI

Why it matters

Machine learning now touches many of a bank’s most important decisions: whether a payment looks fraudulent, whether a borrower is likely to repay, which customer to call about an overdue loan. Language models add assistants for customers and staff, and tools that read documents. Each can bring speed and consistency. Each can also be wrong at scale, treat groups of customers unfairly or be impossible to explain to a customer or a supervisor.

Where banks use it

Common uses of machine learning in banking
Use	What the model does	Typical technique	Key risk
Fraud scoring	Scores each payment or login for fraud in milliseconds	Gradient-boosted trees, graph features, anomaly detection	Blocking genuine customers; missing new fraud patterns
Credit underwriting	Estimates the chance a borrower repays	Scorecards, gradient-boosted trees	Unfair outcomes; decisions that cannot be explained
Collections	Chooses whom to contact, when and how	Propensity models	Aggressive or unfair treatment of vulnerable customers
Customer and staff assistants	Answers questions and drafts responses	Large language models with retrieval	Wrong answers stated confidently; data leakage
Document AI	Reads forms, statements and identity documents	Optical character recognition plus language models	Extraction errors flowing into decisions

General industry patterns, not claims about named banks.

Some of the data these models use arrives through consent-based channels, such as Account Aggregators: No financial information is retrieved, shared or transferred through an Account Aggregator without the customer's explicit consent, and joining is voluntary.^{5Department of Financial Services, Ministry of Finance. Account Aggregator Framework. As of 29 September 2026.} Shared infrastructure for credit is also emerging: The Reserve Bank Innovation Hub describes itself as a wholly owned subsidiary of RBI; its work includes the Unified Lending Interface and MuleHunter.ai.^{4Reserve Bank Innovation Hub. Reserve Bank Innovation Hub. As of 29 September 2026.}

The machinery around a model

Feature stores calculate model inputs once and serve the same values for training and for live decisions.
Model serving runs models behind an API with a fixed latency budget. A fraud score that arrives after the payment has completed is useless.
Monitoring and drift detection watch whether live inputs and outcomes still resemble the training data. Fraud patterns and economic conditions change, and models decay.
Explainability produces reasons for a decision, such as the factors that most lowered a credit score. Customers, staff and supervisors can then understand and challenge it.
Model inventory and validation records every model, its owner, purpose, data and last independent review.

RBI’s expectations: emerging, not settled

RBI’s position on AI and model risk is still developing, and it matters which documents are final:

An RBI committee's report on responsible AI in finance (FREE-AI), placed on RBI's website on 13 August 2025, sets out 7 guiding principles and 26 recommendations under six pillars.^{1Reserve Bank of India. Report of the Committee to develop a Framework for Responsible and Ethical Enablement of Artificial Intelligence (FREE-AI) in the Financial Sector (press release). As of 13 August 2025.}
RBI's draft circular of 5 August 2024 on model risk in credit proposed a board-approved model risk policy, independent validation before deployment, and outcomes that are unbiased, explainable and verifiable.^{2Lexology. RBI releases draft circular on model risk management in credit for lenders. As of 5 August 2024.}
On 24 June 2026 RBI released draft guidance on model risk management across the model lifecycle, including models that use AI and machine learning, for public comment.^{3Business Standard. Reserve Bank issues draft Regulatory Principles for Management of Model Risks. As of 25 June 2026.}

The direction is already clear enough to design for. Keep a model inventory, validate models independently before use and after significant change, monitor them in production, be able to explain decisions that affect customers, and hold the bank accountable for models bought from vendors as well as those built in-house.

Large language models and data protection

Language models raise specific questions: where prompts and outputs are processed and stored, whether customer data could be used to train someone else’s model, and how to stop a model revealing information to the wrong user. Common safeguards include hosting models within the bank’s controlled environment or an approved region, masking personal data before it reaches the model, retrieving only documents the user is allowed to see, and logging prompts and responses for review.

How to choose

Prefer the simplest model that works, especially where decisions must be explained. Start where errors are cheap to catch, such as staff-facing assistants with human review, before customer-facing or credit decisions. Build the inventory, monitoring and validation process before the second model, not after the tenth.

Pitfalls

Training on data the model will not have live, so it performs well in testing and badly in production.
No monitoring after launch, letting a model decay unnoticed.
Proxies for protected characteristics, such as location standing in for community, producing unfair outcomes.
Vendor models treated as black boxes, although the bank remains accountable for them.
Language models given access to data their users should not see.

Questions for a design review

Is this model in the inventory, with an owner and a validation date?
What happens to a customer when the model is wrong, and how can they challenge it?
How is drift detected, and what triggers retraining or rollback?
Can the reasons for an individual decision be produced on request?
Where is data processed when this model runs, and does any of it leave the bank’s control?