RBI Digital Lending Guidelines: What Your Software Must Comply With
The RBI's digital lending guidelines (DLG) are the single most cited regulatory framework in Indian fintech engineering reviews. Most teams treat them as compliance overhead. They're actually architecture requirements. Here's the engineering view.
Key takeaways
- All loan disbursals and repayments must flow directly between the borrower's and lender's bank accounts, no pass-through wallets.
- Key Fact Statement (KFS) must be displayed before the borrower commits.
- Cooling-off period: borrower can exit early without penalty.
- All loan-related communication must come from the regulated lender, not the platform.
- Customer data handling has its own rules layered on top of DPDP.
Why this matters
Non-compliance triggers regulator action and, in serious cases, license risk for your bank/NBFC partner. The architecture decisions you make in your first 90 days of building dictate whether DLG compliance is straightforward or impossible without rebuilding.
The architectural requirements
Direct fund flows
No pass-through wallets. Loan disbursal: lender's bank account → borrower's bank account. Repayment: borrower's account → lender's account. Your platform orchestrates but doesn't custody.
Key Fact Statement (KFS)
Before the borrower commits, they must see: principal, interest, fees, APR, repayment schedule, cooling-off rights, grievance contact. Build it as a structured KFS object, render consistently, log timestamp + version when shown.
Cooling-off period
Borrower can exit within a defined window. Your loan state machine must support an "exited" state with the right financial treatment.
Lender attribution
All communications about loan terms, repayment, recovery must come from the regulated lender. Your platform can be the channel, but the sender must be the lender.
Customer data
In addition to DPDP, RBI requires specific handling: data localization, retention rules, restricted sharing with third parties.
Disclosures
Your app must disclose: the lender's name and license, your role as platform, all fees, grievance redressal officer.
How this shapes your architecture
You'll need a loan state machine that tracks: applied → KFS shown → accepted → disbursed → repaying → completed / exited / defaulted. With timestamps, version of KFS shown, and audit trail of every state transition.
You'll need a payment orchestration layer that triggers direct bank-to-bank transfers via your gateway (most gateways now support direct-credit flows).
You'll need a communications service that lets the lender be the originator of every borrower-facing message.
You'll need an audit log of every disclosure, KFS, and state transition.
Common pitfalls
The first: building wallet-mediated flows in V1 and discovering the rebuild is enormous.
The second: treating the KFS as a static PDF, it needs to be versioned, programmatically generated, and consistently rendered.
The third: missing the cooling-off mechanics, refund flows, interest reversal, communication.
What we recommend
Architect for DLG from day one even if you're pre-launch. Direct flows, structured KFS, state machine with full audit. Get a compliance review before MVP launch. Plan for RBI inspection-readiness as a continuous concern.
FAQs
Does DLG apply to BNPL? Yes if it qualifies as credit.
P2P lending? Has its own regulations, related but distinct.
Loan against securities, gold, etc.? Apply where digital channels are used.
Can we use a wallet as a pass-through? No.