RBI Digital Lending Guidelines (2022): What Indian Lenders Need to Operationalise

The RBI Digital Lending Guidelines (September 2, 2022) are the most consequential operational regulation Indian lenders have absorbed in the past decade. Three years on, most banks and NBFCs we talk to are technically compliant — they have a KFS template, they have a cooling-off process, they have a grievance email — but their compliance is brittle. It survives a routine audit. It does not survive a determined RBI inspection or a Banking Ombudsman case.

This post is the operational playbook we wish we’d had when we built CortexData’s implementation. If you’re a bank CTO, an NBFC CRO, or a credit-ops head responsible for these guidelines, here’s what you actually have to operationalise.

What the Guidelines actually require

The Digital Lending Guidelines are structured around four pillars:

1. Customer-facing transparency — Key Fact Statement (KFS) per Annex II, no fees outside the KFS, clear APR breakdown.
2. Customer rights — cooling-off / look-up period (7 days for short-tenure loans, 14 days otherwise), data privacy, consent, grievance redressal.
3. Lender accountability — only Regulated Entities (REs) on record, Lending Service Providers (LSPs) disclosed, Digital Lending Apps (DLAs) governed.
4. Disbursement and recovery rules — direct-to-borrower disbursement (no LSP intermediation in the money flow), regulated recovery practices.

Each pillar maps to specific code paths in production. Let’s take them in turn.

Pillar 1: KFS as a regulatory contract

The KFS is the single most-tested artefact in the Digital Lending world. It’s the document a customer is shown before signing, and it’s the first thing an RBI inspector or Banking Ombudsman asks for. RBI’s Annex II prescribes the format precisely — and crucially, it requires you to never charge a fee that isn’t on the KFS.

What this means in implementation:

• Single source of truth for fees. Your fee catalogue must be a code-managed table with a unique identifier per fee. Every fee charged anywhere in the system traces back to this table. KFS generation reads from it; disbursement filers read from it; the LMS GL posting reads from it. If a fee exists in your system that isn’t on the customer’s KFS, you have a violation.
• APR computation as a regulatory function. RBI requires APR (annualised cost) including interest + fees + insurance + any other recoverable charge. Compute it as a single, versioned function. We treat APR computation the way payment systems treat money math: deterministic, paise-precise, with a regression test for every edge case.
• Per-product, per-language KFS templates. Personal loans look different from gold loans. Vehicle loans look different from MSME. And every artefact must be available in the customer’s preferred language — for most of India that means English plus at least one of Hindi, Kannada, Tamil, Marathi, etc.
• Customer-acknowledged copy in immutable storage. The KFS the customer saw is not the KFS the system might regenerate later. Hash and store the exact bytes the customer signed off on. Production-grade systems use S3 Object Lock or equivalent WORM storage with multi-year retention.

CortexData LOS ships KFS auto-generation per Annex II for all 8 retail products in EN/KN/HI, with the customer-acknowledged copy stored in our audit chain by default.

Pillar 2: Cooling-off, done right

The cooling-off window (7 days for tenure ≤90 days, 14 days otherwise) sounds simple. The implementation is full of edge cases that catch teams off-guard:

• Pro-rata interest reversal math. The customer pays back what they got, plus interest for the days the funds were used, plus the published one-time exit fee. Most teams botch this by using simple-interest with end-date-inclusive math when RBI guidance is end-date-exclusive. We’ve seen Banking Ombudsman cases turn on a single day’s interest.
• Fee reversal scope. Processing fees, documentation charges, insurance premiums — which reverse, which don’t? RBI is clear: only the published one-time exit fee is recoverable. Processing fees do not survive cooling-off exit. NBFCs in particular get this wrong because their fee structures evolved before the Guidelines.
• GL impact. Cooling-off exit affects multiple GL accounts: principal in/out, interest accrued, fee income reversed, exit fee booked. If your LMS doesn’t handle the reversal as a single atomic transaction, you’ll have reconciliation drift.
• Communication SLA. The customer receives a final closure intimation within a defined window. This intimation needs to be archived alongside the KFS and the original sanction letter.

CortexData implements cooling-off as a deterministic pure function (coolingOffMath()) followed by an atomic GL post. Both are exhaustively tested.

Pillar 3: Lender accountability and the LSP layer

This is where most NBFC-fintech partnerships have had to reorganise. RBI was unambiguous: the Regulated Entity (the bank or NBFC) is on record for every loan, period. The Lending Service Provider can market, source, and service — but the loan is on the RE’s book, the customer’s contract is with the RE, and the customer’s grievance comes back to the RE.

Operational implications:

• DLA registration and disclosure. Every Digital Lending App associated with the RE must be disclosed on the RE’s website. Maintain this list in your CMS, not in a Word doc somewhere on a compliance person’s laptop.
• LSP contract registry. Each LSP relationship is governed by a contract that mandates flow-through compliance, data-handling rules, and regulatory reporting. The contract registry is auditable.
• Customer interface enforcement. If you’re running co-lending or partner-NBFC programmes, the customer must see a single brand (typically the originator). Back-end book splits must remain customer-invisible — see RBI’s Co-Lending Master Direction for the full framework.

Pillar 4: Money flows and recovery

Direct-to-borrower disbursement: the loan principal goes from RE bank account to customer bank account, full stop. LSP cannot be in the money flow. We’ve seen older fintech partnership patterns where LSP’s escrow held principal even briefly — these no longer survive an RBI inspection.

Recovery practices: RBI’s line on harassment is unambiguous. Calls before 8 AM or after 7 PM, repeated calls within 24 hours, calls to non-borrower contacts, or any abusive language are violations that flow back to the RE. Your dunning system needs:

• Time-of-day enforcement per channel (SMS, voice, WhatsApp).
• Per-customer call-frequency caps.
• Verifiable recordings for voice channels.
• A dunning policy ladder that respects RBI guidance: pre-reminder → soft → firm → hard → legal handoff (see CortexData’s LMS dunning module for our 5-tier implementation).

What “compliant” looks like in production

Three years after the Guidelines, here’s the bar for production-grade compliance:

1. KFS, sanction letter, and customer acknowledgement bytes are hashed and stored in immutable retention storage with 10-year horizon.
2. Cooling-off is a deterministic pure function with a regression test per edge case (zero-day exit, full-tenure exit, fee-reversal-with-stamp-duty, etc.).
3. Fee catalogue is a single code-managed source. APR computation is a single function. Both versioned with audit trail.
4. DLA + LSP registry is web-published and audit-trail-versioned.
5. Customer artefacts ship in the customer’s actual language — not just English.
6. Grievance redressal SLA is tracked per ticket, with Banking Ombudsman escalation queue automated.

If you can’t produce all six on demand, your compliance is brittle.

Implementation-time checklist

For teams operationalising the Guidelines from scratch (or re-implementing because their first attempt didn’t survive audit):

• Fee catalogue normalised to code-managed table, with audit trail
• APR computation function with paise-precise math + edge-case regression suite
• KFS template per product, per language, with byte-exact archival of customer-acknowledged copy
• Cooling-off math + GL impact as atomic transaction, regression-tested
• DLA + LSP registry with public web disclosure
• Customer interface single-brand enforcement (especially for co-lending)
• Direct-to-borrower disbursement (no LSP-held escrow on principal)
• Dunning policy with time-of-day + frequency-cap controls
• Recordings retention for voice recovery
• Banking Ombudsman 30-day SLA tracker
• 10-year retention infrastructure (S3 Object Lock or equivalent WORM)

How CortexData operationalises this

Every item on the checklist above is shipped as default configuration in CortexData LOS + LMS. We didn’t build the Guidelines as a feature — we built CortexData around them. If you’re evaluating a platform replacement and the Digital Lending Guidelines are a non-trivial part of your compliance surface, request a demo. We’ll walk through the full pipeline on a working environment.