Regulatory Spine — India

Who regulates what

India does not have one financial regulator. Which one governs you depends on what you do.

A lending app with an investment feature answers to RBI and SEBI simultaneously, under different rules, with different penalties.

The licence question

The first thing to establish is whether you need a licence, or whether you partner with someone who has one.

You generally need your own licence if you are lending your own money, holding customer funds, or operating a payment system.

You can generally partner if you are sourcing customers, providing technology, or acting as an agent for a licensed entity — though the digital lending rules have narrowed what a partner may do considerably.

What an AI system may and may not do

A useful simplification of the current position:

The frameworks you will actually touch

KYC and video KYC

The RBI Master Direction on KYC sets out acceptable customer identification procedures, including the Video-based Customer Identification Process. V-CIP carries specific technical obligations — live capture, geotagging, an official of the regulated entity conducting the session, and recording retention.

This matters for AI design: liveness detection and document extraction assist the process; they do not replace the prescribed steps.

Account Aggregator

The AA framework is the consented data-sharing rail for financial information. A customer consents, and a licensed Account Aggregator moves data from a Financial Information Provider to a Financial Information User.

For a fintech this is usually the only compliant route to bank statement data at scale. Screen-scraping bank credentials is not an acceptable alternative and never was.

Digital lending guidelines

The digital lending rules were a direct response to predatory app lending. The provisions that most shape product design: all disbursement and repayment must flow directly between the borrower and the regulated entity, key facts must be disclosed in a standard statement, data collection must be need-based with explicit consent, and recovery conduct is constrained.

DPDP Act

India’s data protection law introduces consent obligations, purpose limitation, data principal rights and breach notification. For AI systems the consequential parts are purpose limitation — you cannot repurpose data collected for one thing into model training for another without a basis — and the right to erasure, which has architectural implications for anything you have already trained.

Designing an AI system to be compliant

Practical architecture decisions that follow from the above:

• Log the decision, not just the outcome. Store model version, input features, score, threshold applied, and whether a human overrode it. You will be asked.
• Keep a reason-code path. Every adverse decision needs a communicable reason. Design this into the model output rather than reconstructing it afterwards.
• Separate consent scope in the data layer. Tag every record with the purpose it was collected for, so purpose limitation is enforceable in code rather than in a policy document.
• Keep a human in the loop on adverse actions at least initially. It is far easier to remove a human later than to add one after a regulatory finding.
• Data residency. Several categories of financial data carry localisation requirements, which directly restricts which AI APIs you may call.

A prompt for mapping your own regulatory exposure

You are a fintech compliance analyst familiar with Indian financial
regulation. I am describing a product. Map its regulatory exposure.

Product: [DESCRIBE WHAT IT DOES, WHO THE CUSTOMER IS, AND WHAT DATA IT USES]

Produce:

1. Which Indian regulators plausibly have jurisdiction, and why.
2. Whether this likely requires its own licence, or can operate as a
   partner to a licensed entity. State the reasoning.
3. Which specific frameworks apply - KYC Master Direction, digital
   lending guidelines, Account Aggregator, DPDP, NPCI rules, others.
4. For each AI component, whether an automated decision is permitted
   and what disclosure or explainability obligation attaches.
5. The three questions I should take to a qualified Indian financial
   services lawyer before building.

Flag clearly anywhere you are uncertain, or where the position has
changed recently. Do not present a confident answer where the
regulation is genuinely ambiguous.

Where the hard questions are

Explainability versus model performance. Gradient-boosted models outperform logistic regression on credit data and are harder to explain. The regulatory expectation is that you can give a borrower a reason. In practice most firms run an explainable model for the decision and use complex models for portfolio-level insight, or apply post-hoc attribution and accept its limitations. There is no clean answer here.

Alternative data and proxy discrimination. Using device type, app usage or location as credit signals can improve accuracy and can also proxy for caste, religion or region. Indian law does not have a US-style disparate impact doctrine in credit, but reputational and supervisory risk is real. Test for it whether or not you are legally required to.

Generative models in customer communication. A model that writes a repayment message is, functionally, the regulated entity speaking. Recovery conduct rules apply to what it says. Deploying a generative model on that path without tight constraint is a genuine risk.

Training on customer data. Purpose limitation under DPDP makes "we will train on it" a consent question rather than an engineering one. Consider whether you need that consent, and whether aggregated or synthetic data achieves the same outcome.

The supervisory reality

Indian financial regulation is supervised as much as it is written. What matters in practice is what your regulator, or your partner bank’s regulator, will accept during an inspection.

That has a practical consequence: documentation quality is disproportionately valuable. A model with clear documentation, versioned decisions, tested thresholds and recorded human overrides survives scrutiny that a technically better but undocumented model will not.

Build the audit trail first. It is the cheapest compliance investment available and the one most consistently skipped.

Where to verify

Primary sources only, because secondary summaries date quickly:

• rbi.org.in — Master Directions, circulars and notifications. The Master Direction on KYC and the digital lending guidelines are the two most relevant.
• sahamati.org.in — Account Aggregator ecosystem documentation and participant lists.
• npci.org.in — UPI and rails circulars, procedural guidelines.
• meity.gov.in — DPDP Act and subsequent rules.
• sebi.gov.in — if any investment or advisory feature is involved.

Sources

Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which are primary-sourced and which are industry reporting.