← Back to blog
·8 min read

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.

rbi guidelinesdigital lendingfintech complianceloan agentindian fintechai agentdocument extractionregulatory compliance

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:

  • RE (Regulated Entity): Banks, NBFCs — the licensed lenders
  • LSP (Loan Service Provider): Technology companies that source, process, or service loans on behalf of REs
  • DLA (Digital Lending App): The interface the borrower uses — a mobile app or website
  • 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:

  • Only collect data necessary for the loan product — no "while we're at it" data harvesting
  • One-time access to device data (camera, microphone, location, contacts) — not persistent
  • No access to contacts or phone book — a specific call-out aimed at coercive collection practices
  • Data storage must be disclosed — what you store, where, for how long
  • Borrower can request deletion of their data after loan closure
  • 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:

  • Annual Percentage Rate (APR) with all-in cost
  • Loan amount, tenure, and repayment schedule
  • Processing fee and any other charges (in rupee terms, not just percentages)
  • Cooling-off period (the window to exit without penalty)
  • Grievance redressal contact
  • 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:

  • LSP agreements must be disclosed publicly — the RE must publish which LSPs it works with and what data they access
  • Penal charges must be reasonable — no disproportionate late fees, and the reason for penal charges must be shown to the borrower
  • 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.