What to Build for Lending and NBFC Businesses in India

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: Founder or COO of a mid-sized NBFC or digital lending startup in India with 10,000–500,000 borrowers, still running loan origination and collections on a mix of spreadsheets, a legacy LOS, and manual field-agent calls — and now under RBI pressure to tighten their audit trail

If you run a mid-sized NBFC in India today, the first piece of software worth commissioning is not a full lending platform. It is a consented, audit-trailed loan origination workflow that replaces your spreadsheet-and-email underwriting loop — because the RBI (Digital Lending) Directions, 2025 made audit-trail a hard requirement, and you cannot bolt that onto a legacy LOS without rebuilding origination anyway. Collections tooling comes second. A unified borrower data layer comes third. Everything else — fancy dashboards, mobile apps for agents, LLM-driven cross-sell — waits.

This post is for founders and COOs running 10,000 to 500,000 borrowers on some combination of an old LOS, Excel, WhatsApp, and field-agent phone calls. You already know what is broken. The question is which build gives you the most relief per rupee, and in what sequence.

The three operational wounds that actually bleed

Every vendor will pitch you a 14-module lending suite. Ignore that for a minute. In our experience with lending clients, three specific gaps account for most of the operational pain at this stage:

1. Credit decisions take 3–5 days because bureau pulls, bank statement analysis, income verification, and underwriter sign-off happen in disconnected tools with manual handoffs. Industry benchmarks put average NBFC disbursement TAT at 5–7 days, and applicant drop-off climbs sharply once you cross roughly three days (Periscope-tech).
2. Collections run on tribal knowledge. Field agents call borrowers from personal phones. There is no system record of who called whom, what was said, or what was promised. When RBI asks — and they are asking, with roughly 12,903 complaints logged against banks and NBFCs on digital lending and recovery conduct in a 20-month window to November 2022 (Business Standard) — you cannot produce the trail.
3. The audit trail will not survive an inspection. Your LOS logs application status. It does not log consent, who saw what data when, why a limit was changed, or what the borrower was shown in the Key Fact Statement. The RBI (Digital Lending) Directions, 2025 require all of these explicitly (RBI/2025-26/36).

The non-obvious point: these are not three independent problems. The compliance requirement forces you to rebuild origination, and once you are rebuilding origination you may as well solve the TAT problem in the same pass. That sequencing is the entire argument of this post.

Build 1: A consent-first loan origination system

This is the first thing worth commissioning, and it is bigger than it sounds. A loan origination system for an NBFC today is not just a workflow tool — it is the system of record for every regulated interaction with the borrower.

What it actually contains

• A consent layer that captures, timestamps, and versions every piece of borrower data you collect — PAN, Aadhaar (via offline KYC or DigiLocker), bank statements, employment proof, bureau pull authorisation. Para 12 of the 2025 Directions requires data collection to be "need-based and with prior and explicit consent of the borrower having audit trail". If your current system cannot show you which version of which consent screen a specific borrower saw on a specific date, you have a problem.
• A bureau orchestration layer that pulls from CIBIL, Experian, Equifax, and CRIF in parallel, normalises the response, and caches it with an expiry. Most NBFCs still pull serially from one bureau, then a second if the first is thin-file. Parallelising this is a one-week engineering job that cuts a day off TAT.
• An automated document and income verification pipeline. Bank statement analysis via account aggregator (AA) flow where the borrower consents; OCR with human-in-the-loop review for anything ambiguous; GST and ITR pulls for self-employed cases. One documented RPA/IDP deployment at an Indian NBFC processing 8,000+ applications a month cut TAT from 5.2 days to 1.3 days (Periscope-tech). SK Finance cut disbursement time from 27 days to 9 days after automating onboarding, with an 86% lift in volume from the same ops base.
• A policy engine where your credit policy lives as versioned, executable rules — not as a PDF that an underwriter reads and interprets. Every decision logs which policy version ran, what inputs it saw, and what the output was. This is what makes AI credit scoring software meaningful; a model without a policy engine around it is a liability, not an asset.
• A Key Fact Statement generator that produces the KFS in the required format, logs what the borrower was shown, and captures explicit acceptance.

What changes once it exists

TAT typically drops from 5–7 days to 1–2 days for straight-through cases, with the harder files still going to a human underwriter but on a clean dossier instead of a scattered one. More importantly, every decision becomes reproducible. When RBI inspects, you can replay the decision for any loan in your book.

What it takes

This is a three-to-six-month build for a mid-sized NBFC, driven mostly by how many loan products you have, how many bureaus and AAs you integrate, and how much legacy data has to migrate. The things that actually move the number: product count (one unsecured personal loan is dramatically simpler than a mix of PL, two-wheeler, and MSME secured), whether you already have clean digital KYC, and how many third-party integrations (bureaus, AAs, eSign, eNACH, video-KYC vendors) you need live on day one. We get into the shape of this estimate below.

What it is bad at

A new LOS will not fix a bad credit policy. If your NPAs are climbing because your underwriting rules are wrong, software makes you wrong faster. Fix the policy first, then encode it.

Build 2: A collections system with full interaction history

Only after origination is on solid ground is it worth rebuilding collections. The reason for the sequence: a good collections system needs clean borrower and loan data to feed it, and the LOS is where that data gets born.

What it actually contains

• A single borrower record that stitches together every touch — IVR call, agent call, SMS, WhatsApp, email, field visit, payment attempt. Every one of these gets a timestamp, an actor (human or system), and a disposition code.
• A dialler integration where every call to a borrower goes through a recorded, logged channel. No personal phones. The agent sees the borrower's full history on screen before the call connects. The recording is retrievable by loan ID for at least the regulatory retention period.
• A field-agent app with geotagged visit logs, PTP (promise-to-pay) capture, and offline mode for low-connectivity areas. The agent cannot mark a visit without the GPS ping; the ping is part of the audit record.
• A segmentation and prioritisation engine that decides who to call today, in what order, through which channel. Early-bucket borrowers get SMS and IVR. Mid-bucket get agent calls. Late-bucket get field visits. This is where machine learning earns its keep — not in credit scoring, where it is overhyped, but in collections prioritisation, where a modest uplift on contact rate pays for itself in a quarter.
• A grievance capture flow wired to the SACHET portal workflow. The nodal officer details show on the app, website and KFS as required; every complaint has an SLA clock; every response is logged.

What changes once it exists

Recovery rates typically improve in the 10–20% range at the early and mid buckets, mostly from better prioritisation and higher contact rates. The bigger win is defensive: when a borrower complains about agent conduct, you can produce the call recording in minutes, not weeks. In a regulatory environment where recovery conduct is under active scrutiny, that defence is worth more than the recovery lift.

What it is bad at

Collections software does not make an angry borrower less angry. If your product terms are predatory or your KFS is misleading, no collections system saves you. And no ML model fixes a book that was underwritten badly in the first place — garbage in, more efficient garbage out.

Build 3: A unified data layer and reporting backbone

Third in the sequence, and often the one that gets skipped because it is invisible to end users. It is also the one that pays off longest.

Right now your data lives in your LOS, your core banking or loan management system (LMS), your collections tool, your bureau cache, and a dozen spreadsheets. Regulatory reporting — the monthly, quarterly and annual returns to RBI, CIC reporting to bureaus, GST, TDS — is reconstructed each cycle by an analyst with Excel and willpower. This is where mistakes happen and where inspections find discrepancies.

The build: a borrower-and-loan data warehouse that pulls from every operational system on a schedule, a canonical schema that every downstream report reads from, and a set of reconciled report templates for the recurring regulatory submissions. Add a BI layer on top for your own portfolio analytics.

This is where the legacy modernisation work actually lives for most NBFCs — not in replacing the LMS, which is rarely worth the risk, but in getting data out of it cleanly and consistently.

What is not worth building yet

A few things vendors will try to sell you that you should push back on until the three above are done:

• A borrower-facing mobile app with every bell and whistle. A clean web application and a simple app for repayments and statements is enough at this stage. A full-featured app is a 6–9 month build that distracts engineering from the compliance backbone.
• LLM-powered chat support. Fine as a V2. Not fine as a V1 when your audit trail is thin.
• Cross-sell and upsell engines. Earn the right to cross-sell by being clean on origination and collections first.
• A full in-house AI credit scoring model. Start with a well-instrumented rules engine, log every decision and outcome for 6–12 months, and then train a model on your own data. Buying a generic "AI credit scoring" black box early is how NBFCs end up with models they cannot explain to RBI.

Cost and timeline: the shape of the number

Every lending platform estimate you get will be wrong in the same way — it will quote the happy-path build and miss the integration and migration work that actually dominates the schedule. Here is how to think about it.

What drives the number up: number of loan products, number of third-party integrations live on day one (each bureau, each AA, each eSign/eNACH/video-KYC vendor is 1–3 weeks of integration-plus-UAT), volume and messiness of legacy data to migrate, number of user roles and approval workflows, and whether you need on-premise deployment for data-residency reasons versus cloud.

What drives it down: single loan product, clean existing digital KYC, willingness to go live with one bureau and add others in phase 2, and a product team on your side that can make decisions in days instead of weeks.

An illustrative shape — not a quote: a single-product unsecured personal loan origination system, integrated with one bureau, one AA, one eSign provider, one eNACH provider, and video-KYC, with migration of an existing borrower book of under 100,000 records, typically lands in a four-to-six-month window for a first production release, followed by a hardening and iteration phase. Collections rebuild is a comparable or slightly shorter effort when it reuses the origination data model. The data warehouse and reporting layer is a parallel track that starts once origination schemas stabilise.

To turn that shape into a real number you would need to scope three things specifically: (1) exact loan-product count and product variants, (2) the integration list with named vendors for bureaus, AA, KYC, eSign, eNACH, and dialler, and (3) the state of your current data — how much has to migrate, how clean it is, and whether the legacy LMS stays or goes. That conversation is what scoping with CodeNicely is for.

A note on the market context: India's digital lending platform market was valued at USD 623.2 million in 2025 and is projected to reach USD 5,905.7 million by 2033 at a 32.9% CAGR (Grand View Research). Build costs are not falling. Build timelines are, modestly, as reference integrations become more standard.

None of this is legal or compliance advice. The RBI Directions, 2025 text should be read by your compliance head and a lawyer who specialises in financial-sector regulation before any build spec is frozen.

How CodeNicely can help

We built the lending stack for Cashpo, an Indian consumer-lending product, from the KYC and onboarding flow through credit decisioning and collections. The parts of that engagement that are directly relevant to a mid-sized NBFC under RBI pressure: a consent-and-audit-trail design that survived regulatory scrutiny, a bureau-and-AA orchestration layer that cut decisioning time to minutes for the straight-through band, and a collections module where every borrower interaction is logged against the loan record.

If you are rebuilding origination because the 2025 Directions forced your hand, the useful thing we can bring is the pattern — the consent schema, the policy engine shape, the data model that keeps origination and collections talking — not a boilerplate platform. You keep full IP. See our broader India AI and software work and AI Studio for the model-and-data-pipeline side.

Sequencing: how to actually start

1. Month 0: Freeze your credit policy on paper. Get your compliance head and a financial-regulation lawyer to map each clause of the RBI Directions, 2025 to a gap in your current system. This becomes your build spec.
2. Months 1–6: Build the consent-first LOS with policy engine, bureau and AA orchestration, and KFS generator. Migrate in waves by product.
3. Months 4–9 (overlapping): Start the collections rebuild on the new borrower data model. Dialler integration and field-agent app first; segmentation engine second.
4. Months 6–12: Stand up the data warehouse and reporting backbone. Automate the top five regulatory returns.
5. Month 12+: Now consider the AI credit scoring model, the borrower mobile app, and the cross-sell engine — with a year of clean, labelled data behind you.

The temptation is to build the shiny things first because they are what the board asks about. The regulatory forcing function means you do not have that luxury. Build the boring, auditable backbone first. Everything else is easier once it exists.

Frequently Asked Questions

What does a loan origination system for an Indian NBFC actually need to include in 2025?

At minimum: a consent layer that logs every data-collection event with a timestamp, bureau and account-aggregator orchestration, automated document and income verification, a versioned policy engine where credit rules execute, a Key Fact Statement generator, and full audit logs on every decision. These are driven by the RBI (Digital Lending) Directions, 2025, which require explicit consent with audit trail and borrower-request audit trails for limit changes.

How long does it take to build a lending platform for an NBFC in India?

The shape is typically four-to-six months for a first production release of a single-product origination system, with collections and reporting as follow-on tracks. The number is driven mostly by loan-product count, number of third-party integrations live on day one, and how much legacy data has to migrate. To turn that into a real estimate you need to scope products, integration vendors, and data state — that is a scoping conversation, not a published rate.

Should an NBFC build or buy its loan origination system?

Buy if you have a single standard product, no unusual workflow, and are willing to live with the vendor's audit-trail model. Build (or build-with-a-partner on a custom stack) if your products are differentiated, you want to own your credit policy engine, or your compliance team needs control over how consent and audit trails are captured. Most mid-sized NBFCs end up with a hybrid: buy for LMS, build for origination and collections.

Is AI credit scoring worth it for a mid-sized NBFC?

Not as your first build. Start with a well-instrumented rules engine and log every decision and outcome for 6–12 months. Then train a model on your own data where you can explain what it does and why. Buying a generic AI credit scoring product before you have clean labelled data is how NBFCs end up with models they cannot defend to the regulator.

What does RBI actually inspect in a digital lending audit?

Based on the 2025 Directions and observed inspection patterns, inspectors look for proof of explicit borrower consent for each data pull, the Key Fact Statement shown to each borrower, the audit trail of any credit-limit change, the display of nodal grievance officer details on all borrower-facing surfaces, and the recovery conduct trail — including call recordings and field-visit logs. Your compliance head and lawyer should walk through the full checklist against your current systems.