Operating systems for NBFCs: the loan and treasury back office, RBI-aligned classification and reporting, borrower servicing and audit-proof books — built on a double-entry core, sized for NBFCs that have outgrown Excel but aren’t ready for enterprise-suite pricing.
What is the mid-size NBFC’s actual software problem?
The worst gap in Indian financial software sits exactly where most NBFCs live. Below you: spreadsheets — fine at fifty loans, dangerous at five thousand. Above you: enterprise LMS suites priced for banks, with licence fees that exceed your technology team’s annual cost and rollouts measured in fiscal years. So the middle improvises: Excel for the book, Tally for accounts, WhatsApp for approvals, and one irreplaceable person who knows how the three connect.
The improvisation worked when supervision was lighter. Scale-based regulation changed the maths: the compliance bar now rises with your layer, inspections assume reconstructable records, and every statutory audit becomes an archaeology project through exports and memory. The jugaad stack’s real cost isn’t inefficiency — it’s that the evidence of your own good behaviour doesn’t exist in provable form. You ran the book honestly; the systems just can’t demonstrate it without a week of assembly. That gap between being compliant and proving compliance is where the audit overtime, the inspection stress and the debt-diligence friction all live.
What does the NBFC build include?
- The lending core, compliance-tuned. Everything on the lending page — origination, servicing on computed schedules, collections, co-lending — with classification logic aligned to RBI’s framework: DPD-driven, automated, and explainable query by query when an inspector asks why account X sits where it sits.
- Borrower servicing without Word files. Statements, interest certificates, closure letters, NOC documents — generated from the ledger, not typed into templates. Every borrower-facing number traceable to entries, which is exactly what the fair-practices lens examines.
- Treasury basics. Borrowings and repayment obligations tracked, ALM-feeding data produced, covenant numbers computed from the same book the auditor sees — so the lender-side reporting your own debt providers demand stops being a monthly spreadsheet ritual.
- The audit pack as architecture. Every number in the returns traceable to entries; every manual adjustment carrying maker, checker and reason; every classification decision reconstructable. Your auditor’s sampling becomes boring — the highest compliment a lending system can earn, and the cheapest audit season you’ll have had.
- The Tally bridge. Statutory accounting stays where your CA likes it, fed clean vouchers. The CA’s blessing, collected early — the same deployment wisdom that keeps factory rollouts alive applies to loan books.
Why does the double-entry core matter more for NBFCs than anyone?
Because an NBFC’s entire product is a book of promises, and the regulator’s entire question is whether the book is true. The event-sourced, double-entry architecture makes truth structural: disbursals, accruals, receipts and waivers as immutable events; balances, DPD and provisioning as projections recomputable from history. When the book is built this way, drift — the quiet divergence between records and reality that Excel books accumulate — becomes impossible to hide and easy to diagnose. For a startup, drift is embarrassing. For a regulated lender, it’s a finding with consequences. The architecture isn’t gold-plating; it’s the difference between an inspection that reads your queries and one that reads your explanations.
What changes in the first quarter?
Month one: the book reconciles daily against bank and NACH files, and the collections-versus-credits gap gets named and starts shrinking. Month two: classification runs computed — the month-end NPA number arrives without a meeting, provisioning follows rules rather than negotiations, and the first borrower statement goes out generated rather than assembled. Month three: the audit dividend — your statutory auditor samples entries, finds the trail complete, and finishes early. The overtime season becomes a season again, bharosa restored on both sides of the table. The board notices last, and then permanently: the numbers stop moving after they’re reported, because they were facts when they were reported.
Related reading
/industries/lending — the credit engine · /services/fintech — the architecture · /work/ledger-rebuild — the archetype engagement · /products/field-operations — collections in the field
The audit-season test
If audit season means overtime season — /contact. Books that defend themselves are buildable, and the first month’s reconciliation usually proves it.
Questions I actually get
We run on Excel and Tally today. Is migration realistic?
Yes, and staged: the loan book migrates first with parallel runs — old and new reconciled until they agree for days — then operations move over, then reporting. Tally stays for statutory accounting, fed clean vouchers instead of manual entries, so your CA's world improves rather than changes. The factory-migration discipline applies; the book never stops.
How does this compare on cost to the enterprise LMS vendors?
A fraction, because you buy the system your book needs rather than eleven brochure modules. The enterprise tier prices for banks; the register tier prices your weekends. This sits deliberately between — deployment plus support, scoped to your book's actual complexity, with the audit-readiness that is usually the expensive add-on built in as architecture.
What does RBI inspection support actually mean?
That the evidence exists before it is asked for: every classification decision reconstructable, every borrower charge visible, every manual adjustment carrying a name and a reason. The data-room-ready trail is a feature of how the system records, not a scramble when the letter arrives. Your CS handles the correspondence; the system handles the proof.
Can it handle our co-lending and BC arrangements?
Yes — split rules, partner statements and daily reconciliation are the same machinery described on the lending page, and business-correspondent collections flow through the field app with geo-tagged receipts. Partner disagreements shrink to arithmetic because both sides read statements generated from the same entries.
Does it produce our regulatory returns?
It produces the numbers the returns need, traceable to entries — classification summaries, provisioning, exposure reports — in formats your team files from. Where formats shift, the underlying queries adjust without re-architecture, because the data model stores facts rather than report layouts. The returns stop being a reconstruction exercise.
What size NBFC is this for?
The middle: too big for spreadsheets, not ready to spend crores on an enterprise LMS. Base-layer and mid-layer NBFCs under scale-based regulation are the natural fit — the compliance bar is rising with your layer, and the tooling should rise with it without demanding an enterprise budget.