RBI Digital Lending Guidelines: Compliance Guide for Devs
RBI's Digital Lending Guidelines restrict data collection, mandate KFS, and require consent. Here's what every fintech developer building loan agents must know.
India's fintech lending boom came with a regulatory reckoning. After a surge in predatory digital lending apps — hidden fees, coercive collection, unauthorized data harvesting — the RBI released its Digital Lending Guidelines in August 2022, with mandatory enforcement from December 2022. A second circular in 2024 tightened the screws further.
If you're building a loan processing agent, a credit underwriting tool, or any AI that touches lending workflows for Indian users, these rules apply to you — even if you're a technology provider (Loan Service Provider / LSP) rather than a regulated lender.
This guide translates the guidelines into concrete engineering decisions: what data you can collect, how consent must flow, what the Key Fact Statement requires, and how to use Lekha's document extraction API to stay on the right side of the regulation.
What the RBI Digital Lending Guidelines Actually Say
The guidelines apply to three categories:
Most fintech developers fall into the LSP or DLA categories. The key obligations for each:
| Requirement | RE | LSP | DLA | | ------------------------------------- | --- | --- | --- | | KFS mandatory | ✓ | — | ✓ | | Data minimization | ✓ | ✓ | ✓ | | Explicit consent before data access | ✓ | ✓ | ✓ | | Grievance officer designated | ✓ | ✓ | — | | Funds routed only through RE accounts | ✓ | — | — |
Data Collection Restrictions
This is where the guidelines bite hardest for AI developers. The rules are specific:
For document extraction pipelines, this translates directly: if the loan product requires 6 months of bank statements, you cannot extract 24 months. If salary slips are not required for a product, don't collect them even if you could.
The Key Fact Statement (KFS) Requirement
The KFS is a standardized disclosure the borrower must receive before they accept a loan offer. Think of it as a nutritional label for credit products. It must include:
The KFS must be in the borrower's preferred language, and the borrower must explicitly acknowledge it before disbursement. If you're building the underwriting layer that feeds into loan offer generation, the downstream DLA must generate a KFS from your output — which means your structured data needs to be KFS-friendly.
How Document Extraction Fits Into a Compliant Flow
A compliant lending agent has a specific data flow:
Borrower consent → Document upload → Extraction → Underwriting → Offer → KFS → Acceptance
The consent step cannot be skipped or combined with another action. The RBI is explicit that blanket or pre-checked consent forms are invalid.
Here's how to implement this in TypeScript with Lekha:
import axios from "axios";
interface ConsentRecord {
borrowerId: string;
documentTypes: string[];
consentTimestamp: string;
consentIp: string;
sessionId: string;
}
// Step 1: Record explicit, granular consent before touching any documents
async function recordConsent(
borrowerId: string,
documentTypes: string[],
consentMeta: { ip: string; sessionId: string },
): Promise {
// Store in your audit log — regulators can ask for this
const consent: ConsentRecord = {
borrowerId,
documentTypes,
consentTimestamp: new Date().toISOString(),
consentIp: consentMeta.ip,
sessionId: consentMeta.sessionId,
};
await storeConsentRecord(consent); // your database write
return consent;
}
// Step 2: Extract only the document types the borrower consented to
async function extractWithConsent(
documentBuffer: Buffer,
consent: ConsentRecord,
): Promise {
const LEKHA_API_KEY = process.env.LEKHA_API_KEY!;
const formData = new FormData();
formData.append(
"file",
new Blob([documentBuffer], { type: "application/pdf" }),
);
const response = await axios.post(
"https://lekhadev.com/api/extract",
formData,
{
headers: {
Authorization: Bearer ${LEKHA_API_KEY},
"Content-Type": "multipart/form-data",
// Pass consent ID for your own audit trail
"X-Consent-ID": consent.sessionId,
},
},
);
return response.data;
}
Extracting Only What the Product Needs
The data minimization principle means you should scope your extraction to the loan product. Lekha returns rich structured data — but you only use what you need:
interface SalariedLoanInputs {
// What a basic salaried loan needs — nothing more
averageNetSalary: number;
employerName: string;
lastSalaryDate: string;
monthsOfHistory: number;
}
function extractSalariedLoanInputs(
salarySlipData: Record,
): SalariedLoanInputs {
// Lekha returns many fields — select only what the product requires
const data = salarySlipData as {
net_salary: number;
employer_name: string;
salary_month: string;
months_covered: number;
// ... many other fields we deliberately don't use
};
return {
averageNetSalary: data.net_salary,
employerName: data.employer_name,
lastSalaryDate: data.salary_month,
monthsOfHistory: data.months_covered,
};
}
Generating a KFS from Extracted Data
Once underwriting is complete, the KFS must be generated before the offer is shown. Here's a minimal KFS generator that takes structured underwriting output:
interface LoanOffer {
principalAmount: number;
tenureMonths: number;
monthlyEmi: number;
processingFee: number;
annualInterestRate: number;
apr: number; // includes all charges
coolingOffDays: number;
}
interface KeyFactStatement {
loanAmount: string;
tenure: string;
monthlyEmi: string;
processingFee: string;
apr: string;
totalRepayable: string;
coolingOffPeriod: string;
grievanceContact: string;
}
function generateKFS(
offer: LoanOffer,
grievanceEmail: string,
): KeyFactStatement {
const totalRepayable =
offer.monthlyEmi * offer.tenureMonths + offer.processingFee;
return {
loanAmount: ₹${offer.principalAmount.toLocaleString("en-IN")},
tenure: ${offer.tenureMonths} months,
monthlyEmi: ₹${offer.monthlyEmi.toLocaleString("en-IN")},
processingFee: ₹${offer.processingFee.toLocaleString("en-IN")},
apr: ${offer.apr.toFixed(2)}% per annum,
totalRepayable: ₹${totalRepayable.toLocaleString("en-IN")},
coolingOffPeriod: ${offer.coolingOffDays} days,
grievanceContact: grievanceEmail,
};
}
The KFS output gets shown to the borrower before the accept button is enabled. This is non-negotiable.
Common Compliance Mistakes in AI Lending Pipelines
Extracting more document history than needed. If your product requires 3 months of statements, don't send a 12-month PDF to the extraction API and store all of it. Extract, scope to the required window, discard the rest. Storing raw documents after extraction. The guidelines (and DPDP) require data minimization at rest. Once you have structured JSON from Lekha, delete the PDF. Don't store financial documents on your servers. Lekha processes in-memory and returns structured data, which is exactly the right architecture for this. Consent UI dark patterns. Pre-checked boxes, bundled consent ("by proceeding you agree to share all your data"), or consent buried in terms — all invalid under the guidelines. Each document type requires an explicit, standalone consent checkbox. Not logging consent with timestamps. RBI audits will ask for consent records. Log consent grants with: borrower ID, document types consented to, timestamp, IP address, and session ID. Generating APR without all-in costs. Processing fees, insurance premiums, and platform fees must be included in the APR calculation. The flat interest rate is not sufficient.The 2024 Tightening: What Changed
The 2024 circular added two significant requirements for LSPs:
For developers: if you're building an LSP platform, your agreement with the lending RE must now be publicly accessible. This affects how you structure your contractual relationships.
FAQ
Who does the RBI Digital Lending Guidelines apply to?Any entity involved in digital lending to Indian residents: banks and NBFCs (Regulated Entities), technology companies that source or process loans (LSPs), and the apps borrowers use to apply (DLAs). If your AI agent processes financial documents to assess loan eligibility for Indian users, you're in scope as an LSP.
Is it legal to use AI for credit underwriting in India?Yes — AI-based credit scoring and underwriting is permitted. The guidelines do not restrict the technology used; they restrict the data practices around it. You can use an AI agent to assess creditworthiness, as long as consent is obtained, data is minimized, and the borrower receives a proper KFS.
What happens if a borrower requests data deletion?You must delete their data upon request after loan closure. This means your pipeline should not store raw documents — only structured outputs needed for loan servicing (repayment schedules, KFS copies). Lekha's in-memory processing model helps: the PDF never touches your storage, so deletion scope is limited to the structured JSON you produce.
Does every document type need separate consent?Yes. Consent must be granular. A borrower consenting to share salary slips has not consented to share bank statements. Each document type requires its own consent action. In practice, this means your consent UI should have separate checkboxes for each document the product requires, with plain-language descriptions of what each document reveals.
Building a compliant lending pipeline isn't a checkbox exercise — it's an architecture choice. Getting structured data from Lekha in milliseconds means you spend less time wrangling PDFs and more time getting the consent flows, KFS generation, and data lifecycle management right.
Ready to build? Explore the Lekha API docs or try live extraction in the playground. Sign up at lekhadev.com to get your API key.