Build a digital lending app in 2026: the 9 things an NBFC has to ship

Summary. Digital NBFCs sanctioned 9.9 crore personal loans worth ₹1,53,260 crore across the first three quarters of FY 2025-26, at an average ticket size of ₹15,493, which is 78 per cent of personal loan sanction volume and 19 per cent of sanction value, per the Fintech Association for Consumer Empowerment. In Q3 FY26 alone the value grew 52.86 per cent year on year to ₹56,892 crore. The build is no longer the interesting part. The RBI (Digital Lending) Directions, 2025, in force since 8 May 2025, convert a set of product choices into engineering requirements: a Key Facts Statement with an all-in Annual Percentage Rate, a board-approved cooling-off exit of not less than one day, all data stored only on servers located in India, no biometric collection, every lending app listed with the Reserve Bank, and, since 1 November 2025, a full digital view of every matching loan offer on any platform working with more than one lender. This piece is the engineering reading of those Directions: what each clause forces into the codebase, what it costs in build time, and where teams get it wrong.

What changed, in the order it hits a build

The Directions came into force immediately on 8 May 2025, with two staggered paragraphs. Paragraph 17, the reporting of every digital lending app on the Reserve Bank's Centralised Information Management System portal, took effect on 15 June 2025. Paragraph 6, covering arrangements where a Lending Service Provider works with multiple lenders, took effect on 1 November 2025.

That second date is the one that changed architecture. If your app shows offers from more than one regulated entity, it now has to show the borrower a digital view of every loan offer matching their request, and disclose the names of the lenders that did not match. A ranked funnel that quietly surfaces the highest-commission lender is no longer a design choice.

Requirement	Directions reference	What it becomes in the codebase
Key Facts Statement with APR	Para 8, per the KFS circular of 15 April 2024	A generated, versioned document per offer, not a static PDF
Cooling-off exit, minimum one day	Para 10	A loan state machine with a board-configurable exit window
One-time processing fee on exit	Para 10	Fee must be disclosed upfront in the KFS, so it is a KFS field
All data on servers in India	Para 12	Region pinning across database, object store, logs, backups, analytics
No biometric storage or collection	Para 12	Device-local biometric authentication only; nothing leaves the handset
Digital view of all matching offers	Para 6, from 1 November 2025	An offer-aggregation service with a deterministic, auditable match
Names of unmatched lenders shown	Para 6	Negative results are a first-class API response, not an empty array
Grievance escalation after 30 days	Para 11	Ticket SLA clock, plus RB-IOS and CMS portal signposting in-app
Every DLA reported on CIMS	Para 17, from 15 June 2025	A release process that files before the app ships, not after

Source: RBI (Digital Lending) Directions, 2025, notification DOR.STR.REC.19/21.07.001/2025-26, 8 May 2025.

The nine pieces, and what each one actually takes

1. The Key Facts Statement service. The KFS has to carry an Annual Percentage Rate that includes all charges, and it has to be given before the borrower commits. Teams usually start by templating a PDF and end up rebuilding it, because the KFS has to reflect the exact offer, the exact fee schedule, and the exact cooling-off terms for that borrower on that day. Build it as a service that renders from the offer object and stores an immutable copy against the loan, with the template version recorded. Two to three weeks of work, and it saves an audit reconstruction later.

2. The cooling-off state machine. The Directions leave the length to the board, subject to a floor of one day. That means it is a configuration value, not a constant, and it will change. The loan needs a state where the borrower can exit by paying principal plus proportionate APR with no penalty, and where a one-time processing fee may be retained only if it was disclosed upfront in the KFS. Model it explicitly. Teams that bolt it onto a repayment schedule spend the next year fixing edge cases around disbursal timing.

3. India-only data residency, verified. Every regulated entity has to ensure all data is stored only on servers located within India. In practice this is not one setting. It is your primary database region, read replicas, object storage, backup destination, log aggregation, error tracking, analytics, email and SMS providers, and the AI or scoring APIs you call. The failure mode is almost always a third-party SDK, not the database. Our note on data residency and DPDP cloud architecture covers the region-pinning approach in detail.

4. Biometrics that never leave the device. No biometric data may be stored or collected by the regulated entity or its Lending Service Provider unless a statute allows it. Use the platform APIs the way they were designed: Face ID and Touch ID on iOS, BiometricPrompt on Android, where the match happens in the secure enclave and your app receives a boolean and a cryptographic assertion. If a vendor SDK offers to send a face template to a server for matching, that is the clause you are about to breach.

5. The offer aggregation layer, if you have more than one lender. Paragraph 6 is the most under-built part of most platforms. You need a matching engine whose output is explainable, a UI that shows every matching offer rather than a curated subset, and a record of the lenders that did not match with the reason. Treat the match as an auditable decision with inputs and outputs logged. Three to five weeks, more if your lender integrations return offers on wildly different schemas.

6. The consent and data-collection boundary. Collect only what the loan needs, tell the borrower what is collected, and give a working revocation path. If you are pulling financial data, the Account Aggregator framework is the cleaner route than screen-scraping or SMS parsing, and it gives you a consent artefact you can show. We have written on Account Aggregator integration for fintech builders.

7. Grievance redressal with a real clock. The borrower can escalate to the Reserve Bank-Integrated Ombudsman Scheme through the Complaint Management System portal if the regulated entity has not replied within 30 days. So the ticket system needs an SLA clock that starts at receipt, an escalation path that fires before day 30, and in-app disclosure of the nodal grievance officer for both the regulated entity and any Lending Service Provider with a borrower interface. This is a two-week build that teams routinely defer to a spreadsheet, and then cannot evidence.

8. CIMS reporting as part of release. Every digital lending app, whether the entity's own or a Lending Service Provider's, has to be reported on the Reserve Bank's CIMS portal, with the Chief Compliance Officer or a designated officer certifying that the submitted data is correct. If a new white-labelled app is a business decision that engineering hears about at launch, that certification is being signed on stale data. Put the filing in the release checklist.

9. Default loss guarantee accounting, if you have one. Where a DLG arrangement exists, the total cover on an outstanding portfolio specified upfront may not exceed five per cent of the total amount disbursed out of that portfolio at any given time. That is a running calculation over a moving portfolio, which means it belongs in the ledger with a daily job and an alert, not in a quarterly spreadsheet.

Build, buy, or assemble

Most NBFCs face the same three-way choice, and the honest answer depends on how much of the lending logic is actually differentiated.

Approach	Time to first disbursal	Fits when	The catch
Licensed LOS or LMS platform	Fastest	Standard personal or consumer durable loans, thin engineering team	Residency and KFS behaviour are the vendor's; you still own the compliance
Custom build end to end	Slowest	Novel underwriting, unusual collateral, or a co-lending model with several partners	You own every clause in the table above, including the ones that change
Core platform plus custom borrower app	Middle	Most growth-stage NBFCs	Integration surface between the app and the platform is where defects live

The third row is where most of our work sits, and the reason is unglamorous. The regulated behaviours cluster in the borrower-facing app and the offer layer, which is exactly the part a generic platform handles least well, while ledger, repayment and collections are commodity enough to buy.

An indicative timeline

Numbers below are build effort for a borrower-facing Android and iOS app plus the offer, KFS and grievance services, assuming the lending core is bought rather than built. They are engineering estimates, not a quote.

Phase	Typical duration	Output
Discovery and clause-to-requirement mapping	2 weeks	Requirement set traced to each paragraph of the Directions
Architecture and residency design	2 weeks	Region-pinned reference architecture, third-party inventory
KFS, cooling-off and grievance services	5 to 7 weeks	Versioned KFS generation, exit state machine, SLA clock
Offer aggregation layer (multi-lender only)	3 to 5 weeks	Auditable match, full digital view, unmatched-lender disclosure
Borrower apps, Android and iOS	10 to 14 weeks	Onboarding, consent, KFS acceptance, repayment, support
Hardening, test automation, release readiness	3 weeks	Evidence pack, CIMS filing, automated regression suite

Cross-platform frameworks compress the two app tracks; a native split does not, but buys you tighter control over the biometric and secure-storage paths. We have written on that trade in enterprise mobile app development, and on the cost comparison between Indian and US build teams.

Where teams get it wrong

The analytics SDK. Region-pinning the database and then shipping an analytics or crash-reporting SDK that batches events to a US region is the single most common residency defect we see. Inventory every SDK and every outbound host before launch, not after.

Treating the KFS as marketing collateral. It is a generated artefact tied to a specific offer, and it needs to be reproducible months later. If your KFS lives in a design tool, it will not survive a question about what a borrower saw in March.

A cooling-off window hard-coded in three places. The board sets it. It will change. One configuration source, read at loan creation, recorded on the loan.

An offer screen that ranks by commercial preference. Under paragraph 6 the borrower sees every matching offer, and the unmatched lenders are named. Product teams sometimes discover this after the screens are built.

Biometric templates on a server. If a vendor's onboarding SDK does server-side face matching, that is a design decision to make deliberately and with legal input, not a default to accept.

No evidence trail. Almost every requirement above is also an evidence requirement. Log the decision, keep the artefact, version the template. Reconstructing this later costs more than building it in.

What the numbers say about where to build

The market shape argues for a particular kind of app. Average ticket size across digital NBFC personal loans sat at ₹15,493 for the first three quarters of FY 2025-26, and digital NBFCs accounted for 78 per cent of sanction volume against 19 per cent of value. That is a high-frequency, low-value, thin-margin business, and it has three engineering consequences.

Cost per disbursal dominates. At a ticket size in the ₹15,000 range, every manual step in onboarding, verification or collections eats the unit economics. Automation is not a nice-to-have; it is the business model.

Latency is a conversion metric. Borrowers abandon during document upload and verification waits far more than during form fill. Instrument the funnel by step and optimise the slowest one, not the ugliest one.

Value grew faster than volume in Q3 FY26, 52.86 per cent against 9.3 per cent, which means average tickets are rising. Systems sized for small-ticket consumer loans need headroom for larger loans with more documentation and stricter verification. Design the document pipeline for the loan you will write next year.

How we work

eCorpIT is a technology organisation founded in 2021 in Gurugram, with CMMI Level 5, MSME and ISO 27001:2022 certifications and partnerships with AWS, Microsoft and Google. Our senior engineering teams build borrower-facing lending apps and the services behind them for Indian NBFCs and fintechs.

We start with a clause-to-requirement mapping workshop, because the arguments worth having happen there rather than in code review. We then design the residency and third-party boundary before any app screens, since that is the constraint that is expensive to retrofit. Engagements typically run as a dedicated senior-led pod with a fixed discovery phase and iterative delivery after it, with the evidence pack produced alongside the build rather than at the end. We design applications aligned with RBI Digital Lending Directions and Digital Personal Data Protection Act 2023 requirements; the regulatory filings and certifications remain yours to make.

Related work: fintech app development, DPDP-ready app development, and the engineering-level RBI digital lending checklist.

FAQ

When did the RBI Digital Lending Directions, 2025 come into force?

The Directions came into force immediately on issue, dated 8 May 2025, with two exceptions. Paragraph 17, covering the reporting of digital lending apps on the Reserve Bank's CIMS portal, took effect on 15 June 2025. Paragraph 6, covering arrangements where a Lending Service Provider works with multiple lenders, took effect on 1 November 2025.

What is the minimum cooling-off period for a digital loan?

The board of the regulated entity determines it in the loan policy, subject to a floor of not less than one day. During that window the borrower can exit by paying the principal and the proportionate Annual Percentage Rate with no penalty. A reasonable one-time processing fee may be retained if it was disclosed upfront in the Key Facts Statement.

Can a lending app store borrower data outside India?

No. The Directions require the regulated entity to ensure that all data is stored only on servers located within India, while complying with other statutory and regulatory obligations. In practice this covers databases, replicas, object storage, backups, logs, analytics and any third-party service that receives borrower data, not just the primary database.

Are biometrics allowed in a digital lending app?

The regulated entity must ensure that no biometric data is stored or collected by it or its Lending Service Provider, unless allowed under extant statutory guidelines. Device-local biometric authentication through the platform APIs is the safe pattern, because the match happens on the handset and no template is transmitted or retained.

What does a multi-lender platform have to show borrowers?

Since 1 November 2025, a Lending Service Provider must provide a digital view of all loan offers matching the borrower's request on the app, and the names of the unmatched lenders must also be disclosed in that view. The matching mechanism itself is left open, but the disclosure of both matched and unmatched lenders is not.

How long does an NBFC have to answer a borrower complaint?

If a complaint is not resolved, is only partly resolved, the borrower is not satisfied with the reply, or no reply is received within 30 days of the regulated entity receiving the complaint, the borrower may escalate through the Complaint Management System portal under the Reserve Bank-Integrated Ombudsman Scheme.

What is the cap on a default loss guarantee arrangement?

The regulated entity must ensure that the total amount of default loss guarantee cover on any outstanding portfolio, specified upfront, does not exceed five per cent of the total amount disbursed out of that loan portfolio at any given time. Because the portfolio moves daily, this is a running calculation rather than a periodic reconciliation.

How large is digital lending in India right now?

Digital NBFCs sanctioned 9.9 crore personal loans worth ₹1,53,260 crore across the first three quarters of FY 2025-26, at an average ticket size of ₹15,493, per the Fintech Association for Consumer Empowerment. That is 78 per cent of personal loan sanction volume and 19 per cent of sanction value over the period.

How eCorpIT can help

eCorpIT builds borrower-facing lending applications and the KFS, offer, consent and grievance services behind them for Indian NBFCs and fintech lenders, with senior-led teams working from Gurugram. We map each clause of the Directions to a testable requirement, design the residency and third-party boundary first, and hand over an evidence pack alongside the release. Our CMMI Level 5 and ISO 27001:2022 certifications reflect how we run delivery and information security. Talk to us at /contact-us/ to scope a build or review one already in flight.

References

1. Reserve Bank of India (Digital Lending) Directions, 2025, notification DOR.STR.REC.19/21.07.001/2025-26, 8 May 2025.
2. Key Facts Statement (KFS) for Loans and Advances, RBI circular DOR.STR.REC.13/13.03.00/2024-25, 15 April 2024.
3. Guidelines on Default Loss Guarantee in Digital Lending, RBI, 8 June 2023.
4. FAQs on Guidelines on Default Loss Guarantee in Digital Lending, Reserve Bank of India.
5. Guidelines on Digital Lending FAQs, Reserve Bank of India.
6. Digital Personal Loans, December 2025 report, Fintech Association for Consumer Empowerment, 24 March 2026.
7. Digital personal loan value outpaces volume growth in Q3 FY26, Business Standard, March 2026.
8. Growth rate of digital loans moderates in Q1 FY26, says FACE report, Business Standard, October 2025.
9. New digital lending directions issued by the Reserve Bank of India, Lexology, 2025.
10. Digital Lending Directions, 2025 analysis, Vinod Kothari Consultants, May 2025.
11. RBI (Digital Lending) Directions, 2025: an overview, Argus Partners, 2025.
12. RBI notifies the RBI (Digital Lending) Directions, 2025, Saraf and Partners, 2025.
13. RBI digital lending press release, reproduced by FIDC India, 8 May 2025.
14. Guidelines on Digital Lending, RBI circular DOR.CRE.REC.66/21.07.001/2022-23.
15. FACE resource centre, Fintech Association for Consumer Empowerment, accessed August 2026.

Last updated: 4 August 2026.