Ask any founder running a lending fintech in India what keeps them up at night, and “the next RBI circular” is a near-universal answer. That’s not a complaint about over-regulation so much as an acknowledgment of how fast this space has been reshaped. What used to be a loosely governed ecosystem of loan apps, lending service providers (LSPs), and balance-sheet-light NBFC partnerships is now operating under one of the more detailed regulatory frameworks the RBI has built for any fintech vertical. If you’re building, investing in, or partnering with a digital lender, here’s what the compliance landscape actually looks like today.
Why the RBI stepped in so hard
The digital lending guidelines didn’t emerge in a vacuum. They followed a wave of predatory lending app scandals — apps charging exorbitant interest, using coercive recovery tactics, harvesting contact lists and photos from borrowers’ phones, and in some tragic cases, driving borrowers to suicide through harassment. The RBI’s Working Group on Digital Lending, and the subsequent guidelines, were built explicitly to close the gap between how fast lending apps were scaling and how little oversight existed over their practices.
The core structural rule: money must flow directly
Perhaps the single most consequential requirement is this: loan disbursals and repayments must flow directly between the bank/NBFC’s account and the borrower’s account, with no pass-through via the lending app or any third-party pool account. This single rule broke the business model of a huge number of app-based lenders who were essentially operating as unlicensed shadow banks, controlling cash flows without holding the capital or regulatory obligations of one.
For any fintech operating as an LSP (Lending Service Provider) rather than a regulated entity itself, this means the technology stack has to be rebuilt so that the fintech’s app is a customer acquisition, underwriting-support, and servicing layer — not a custodian of funds.
Disclosure requirements that actually bite
The guidelines mandate a standardized Key Fact Statement (KFS) that must be given to the borrower before loan execution. This has to include the Annual Percentage Rate (APR), not just headline interest — a change that has forced many apps to stop hiding processing fees, platform fees, and insurance add-ons inside a lower advertised rate. The APR must include all costs, making genuine price comparison possible for borrowers for arguably the first time in this market.
Fintechs also need to disclose the identity of the actual regulated lender behind the loan on every touchpoint — the app, the website, the loan agreement — because so much of the earlier abuse came from unclear or hidden lending relationships where borrowers had no idea who was actually extending them credit.
Cooling-off period and prepayment rights
Borrowers must be given a cooling-off or look-up period during which they can exit the loan by paying only the principal and proportionate APR, without penalty. This is a meaningful compliance point for fast-disbursal apps whose entire user experience is built around instant credit — the flow now has to accommodate this exit window without friction that would violate the spirit of the rule.
Data collection: the part that changed app design the most
Digital lending apps historically justified aggressive access to contacts, gallery, call logs, and location as “necessary for underwriting.” The RBI’s guidelines explicitly restrict data collection to what is need-based, with the borrower’s explicit consent for each data category, and the ability to revoke that consent and have the data deleted. Access to contact lists and photo galleries — the two categories most implicated in harassment cases — is effectively prohibited outside narrow exceptions.
This has forced a real re-architecture of underwriting models. Fintechs that leaned heavily on alternative data scraped from the phone have had to shift toward bureau data, banking transaction data (via Account Aggregator consent flows), and declared income — a slower but far more defensible foundation.
FLDG: bringing co-lending risk-sharing into the light
First Loss Default Guarantee arrangements — where a fintech guarantees a portion of loan losses to the bank or NBFC it’s partnering with — existed for years in a regulatory grey zone. The RBI’s subsequent guidelines formalized FLDG arrangements, capping the guarantee at a defined percentage of the loan portfolio and requiring these arrangements to be structured and disclosed properly, rather than functioning as an off-balance-sheet way for fintechs to effectively act as unlicensed lenders while regulated entities carried the compliance burden on paper.
What this means practically for a fintech building in this space today
- Choose your regulatory posture early. Decide whether you’re an LSP partnering with a bank/NBFC, or pursuing your own NBFC license. The compliance burden and business model economics differ substantially.
- Build the KFS and APR disclosure into the product from day one, not as a bolt-on before a compliance audit.
- Re-architect underwriting around consented, auditable data sources — Account Aggregator rails, bureau data — rather than device permissions.
- Document your FLDG or risk-sharing structure with your lending partner explicitly, with caps that align with RBI norms.
- Treat grievance redressal seriously. The guidelines require a nodal grievance officer and defined resolution timelines, and RBI has shown it will act on borrower complaint patterns.
The bigger picture
The digital lending guidelines represent one of the clearer cases of the RBI writing rules specifically to protect a category of borrower — often first-time, credit-thin, financially vulnerable users — that a purely growth-driven fintech ecosystem was not going to protect on its own. For founders and investors, the framework is now stable enough to build against with confidence, but the bar for compliance sophistication has risen considerably. The apps that treated regulation as an afterthought have mostly been forced out or absorbed; the ones still standing are, for the most part, the ones that built compliance into their core architecture rather than around it.
