All Articles
Compliance7 min read·1 May 2026

RBI Digital Lending Guidelines: A Practical Compliance Guide for NBFCs (2026)

The RBI's digital lending framework requires NBFCs to rethink data collection, consent, and vendor relationships. Here's what the guidelines mean in practice for credit technology stacks.

SD

Subhalaxmi Das

Co-founder & CTO · Santulan

RBI Digital Lending Guidelines: A Practical Compliance Guide for NBFCs (2026)

The Reserve Bank of India's digital lending guidelines — progressively tightened since the 2022 master direction — have fundamentally changed the compliance landscape for NBFCs and fintech lenders. While much of the public discussion has focused on first-loss default guarantees and lending service provider (LSP) relationships, the guidelines have equally significant implications for how lenders collect, process, and use borrower financial data.

Consent Architecture: What the Guidelines Require

The RBI guidelines establish clear requirements for borrower consent in digital lending. At the data collection level, lenders must obtain explicit, informed consent before accessing any borrower financial data — including bank statements, GST returns, and ITR data. This consent must be purpose-specific (collected for credit assessment, not general commercial use), revocable, and documented with a timestamp.

For bank statement analysis specifically, this means that access to borrower statements through account aggregator (AA) frameworks or direct API access must be preceded by documented consent captured through the lender's app or portal. Obtaining statements through other means — asking borrowers to email PDFs, accepting WhatsApp-shared files without consent logging — while common in legacy workflows, is increasingly difficult to defend from a compliance standpoint.

RBI Digital Lending Guidelines: A Practical Compliance Guide for NBFCs (2026) illustration

Data Minimisation and Retention Limits

The guidelines establish a data minimisation principle: lenders and their technology vendors may only collect data that is necessary for the stated purpose (credit underwriting), and must not retain it beyond what is required for that purpose. For bank statement analysis, this has two practical implications.

First, full statement PDFs should not be retained indefinitely by analysis vendors after extraction is complete. Structured transaction data may be retained for audit and dispute resolution purposes, but the raw document should have a defined retention and deletion policy. Second, enriched profiles built from borrowed statement data — behavioural scores, propensity models, or any use beyond the original underwriting purpose — require separate, specific consent.

Lending Service Provider Obligations

If your NBFC uses a third-party vendor for bank statement analysis, that vendor is likely classified as a Lending Service Provider or Technology Service Provider under the RBI framework. This classification carries specific obligations: the lender must maintain a list of LSPs/TSPs and report it to the RBI; contracts with LSPs must include specific provisions around data handling, grievance redressal, and regulatory access; and the NBFC remains fully responsible for the actions of its technology vendors — including data breaches, consent violations, and incorrect credit assessments that result from vendor errors.

This last point deserves emphasis: the RBI takes the position that regulatory responsibility cannot be outsourced to vendors. An NBFC cannot argue that a compliance failure in its credit data processing was the vendor's fault. This creates strong incentives to choose vendors with robust compliance postures and to maintain genuine oversight of how third-party systems handle borrower data.

The Account Aggregator Pathway

The RBI's Account Aggregator (AA) framework represents the cleanest compliance pathway for digital lending data collection. Under AA, borrowers consent through a standardised interface to share specific financial data with specific lenders for specific purposes and time periods. The consent artefact is cryptographically signed, timestamped, and verifiable. Data flows through the AA ecosystem in encrypted format, with no raw data stored by the aggregator.

For NBFCs that have implemented AA-based data collection, the consent compliance burden simplifies considerably. The framework handles consent documentation, revocation mechanisms, and audit trails in a standardised way that satisfies RBI requirements. The practical challenge has been that AA adoption among MSME borrowers is still growing — not all borrowers can or will share data through the AA pathway, requiring fallback mechanisms that must maintain equivalent compliance standards.

Building a Compliant Credit Technology Stack

The practical question for NBFC technology and compliance teams is: does our current credit technology stack satisfy the RBI's digital lending requirements? The checklist should cover: documented consent capture before any borrower data collection; purpose limitation (data used only for stated credit assessment purpose); defined data retention and deletion schedules across all vendor systems; LSP/TSP agreements that include required RBI-mandated provisions; audit trails that can demonstrate compliance during an RBI examination; and grievance redressal mechanisms that extend to third-party data processing.

For most NBFCs that assembled their credit technology stack before the current guidelines were finalised, a gap assessment against this checklist will reveal items requiring attention. The good news is that the regulatory direction has been clear for long enough that most reputable technology vendors have updated their posture to support compliant deployments.

SD

Subhalaxmi Das

Co-founder & CTO

All Articles

See it in action.
Book a live demo.

Run a real analysis on your own sample statements in under 2 minutes.