How to scale NBFC lending operations: what breaks at each stage
CS Sushil Choudhary · How-to · 2026-08-12 · 7 min read (estimated)
Scaling an NBFC's operations is mostly about removing the places where a number exists in more than one system and the places where a control depends on somebody remembering. Neither constraint is about transaction volume. A book can multiply tenfold on the same infrastructure; what it cannot survive is a month-end close that grows linearly with it, or a control that worked because one person saw everything.
What breaks, and in what order?
| Stage | What breaks first | Why |
|---|---|---|
| One branch, one product | Nothing — a workbook is fine | One writer, one product, one person |
| Two branches | Concurrency | Two people cannot write to one file |
| Two products | The formulas fork | And the fork is where errors live |
| Fifty crore book | Month-end reconciliation | Grows with the book, not with the team |
| A field collections team | Receipt consistency | Two ways to take money, two outcomes |
| An external examination | The audit trail | Questions that had no answer now need one |
| Multi-state | Access control | "Everyone sees everything" stops being acceptable |
| Bank funding or co-lending | Reporting cadence | Somebody else's timetable, and their definitions |
The pattern: each stage adds a second of something — a second writer, a second product, a second place money is taken, a second reader of the numbers. Scaling is the work of making sure the second one agrees with the first.
Which of these is actually a software problem?
Fewer than vendors suggest.
Genuinely software: concurrency, classification consistency, per-event accounting, scoped access, reporting from a stored position, an audit trail that cannot be bypassed. These cannot be solved by process, because process is what fails when the volume rises.
Genuinely process: underwriting quality, collections discipline, the credit policy itself, and whether the deviation rate is watched. Software can surface these; it cannot fix them, and a lender who buys a platform expecting it to improve credit quality has bought the wrong thing.
Both: turnaround time. Usually lost waiting for a document, a valuation or an approver — so the software's contribution is making the wait visible (what is this file waiting for, and with whom) rather than making a form faster to fill.
What should be in place before the book doubles?
Six things, none of which is expensive to do early and all of which are painful to retrofit.
1. One computation of days-past-due, read by collections, classification, reporting and the bureau file.
2. Accounting posted per event, so month-end is a close rather than a reconciliation. This is the single largest determinant of whether the finance function scales with the book or with the headcount.
3. Data scope enforced. Every list, report and export filtered by the acting user's scope, with no toggle that ignores it. Retrofitting this means auditing every query in the system.
4. Maker-checker where money moves, and on master activation. It is a control that costs nothing when there are three users and is impossible to introduce cleanly when there are sixty.
5. An append-only audit trail with prior values. The first external examination will ask a question that only this can answer.
6. A stored day-end position. Without it, a figure filed last quarter cannot be reproduced this quarter, and every reporting question becomes an argument.
What does the branch expansion actually require?
Three things beyond the obvious:
- Numbering per branch. Loan account numbers, receipt numbers, application numbers — with the
branch in the series, so a document identifies where it came from.
- A cash position per branch. Collections in hand, deposits, and the difference, as a balance
rather than as a spreadsheet.
- Reports that default to the user's scope. A branch manager opening a portfolio report should
see their branch without setting a filter, because the filter is the thing that gets forgotten.
Common mistakes
- Hiring ahead of the reconciliation problem. Adds people to a process that should not exist.
- Scoping access later. Every query has to be audited.
- Maker-checker introduced after growth. Politically much harder at sixty users than at six.
- A second system for the new product. Two books, one lender.
- Assuming the constraint is technical. It is usually the month-end close or the approver queue.
- Growing the deviation rate quietly. The earliest indicator of a book about to turn, and the one
nobody has a report for.
- No cohort view. A growing book dilutes its own bad news; the headline stays flat while the
recent vintages deteriorate.
A worked example
A lender goes from one branch to five over eighteen months, book from ₹12 crore to ₹70 crore.
Month 1–6. Everything works. The workbook is bigger; the close takes two days instead of one.
Month 7. Second branch. The workbook becomes two workbooks consolidated weekly. The consolidated position is always a week stale, and the branch positions are authoritative for different periods.
Month 11. A bank line requires quarterly reporting. Producing the pack takes three weeks, because classification history was never stored — it is being reconstructed from balances.
Month 14. A borrower disputes a rate change. Nobody can say who changed it or what it was before. The answer comes from an email thread.
Month 18. ₹70 crore, five branches, a collections team, and a month-end close that takes eleven days and two people who cannot take leave in the first fortnight.
None of those was a volume problem. Each was a second copy of something — a second workbook, a second version of the truth, a second way of doing the same thing — and each was cheap to prevent and expensive to unwind.
How Lenviq handles this
The properties above are the design rather than a feature list: one classification engine reading one set of due events; accounting posted from loan events as they happen; data scope enforced on every list, report and export; maker-checker on disbursement and on master activation; an append-only audit trail at the data layer, so a bulk job and a screen edit leave the same record; and a day-end position written every night before anything derived from it runs, because a missed night is a month-end position that cannot be reconstructed.
The product page sets out the modules; the reports page sets out what is produced and how each states the date it is as at.
Frequently asked questions
At what size does an NBFC need a proper lending system?
There is no threshold worth quoting. The triggers are structural: a second person needing to write, a second product, a second place money is collected, or an external party about to examine the book. Any one of them is sufficient.
What is the biggest operational constraint on a growing lender?
Usually the month-end close, because it grows with the book rather than with the team. A close that takes eleven days at ₹70 crore takes longer at ₹150 crore, and the only durable fix is accounting posted per event rather than reconciled per month.
Does scaling require more people in operations?
Only where the process requires a person to move a number between systems. Growth in underwriting, collections and relationship work is real; growth in reconciliation headcount is a symptom.
When should access control be scoped?
Before the second branch. Retrofitting scope means auditing every query in the system, and the consequence of missing one is that a user sees a book they should not — which is the kind of finding that becomes an incident rather than a bug.
What should be watched as an early warning of trouble?
The deviation rate and the vintage cohorts. A rising share of approvals outside policy precedes deterioration by months, and a cohort view shows deterioration a growing book's headline NPA is diluting.
Related reading: How to manage an NBFC loan portfolio · Spreadsheets vs loan management software · How to track loan collections · What lenders ask in due diligence
Ask for a walk-through of what your next stage will need.
Read next
- Spreadsheets vs loan management software: when an NBFC has to move
What spreadsheets do well for a small book, the five points at which they stop working, and how to migrate without losing the history.
- NBFC income recognition: what the RBI rules require once an account turns bad
Why accrued interest is reversed at classification, what receipt basis means in the ledger, and the half of the rule most systems never implement.
- The Key Facts Statement: what an NBFC must disclose, and what it costs to get wrong
What goes into a KFS, how the APR is computed, and the clause that stops a lender recovering a charge it failed to disclose.
From the people who wrote this
Run your lending on Lenviq
Seeing it run on your own book is faster than reading about it — a demo works through your products, your schemes and your classification rules, not a generic tour.
Lenviq is loan origination, servicing and accounting for NBFCs, built by FastLegal Technologies.