I build software for lending businesses in India and the UAE: loan origination, servicing, collections, co-lending splits and RBI-compliant reporting — on a double-entry core so every rupee of principal, interest and penalty is traceable from disbursal to closure.
Where does lending software actually break?
At the edges, where money behaves badly. The demo loan — one disbursal, twelve tidy EMIs — works in every system ever built. Loan #4,000 is where the sheet dies: the EMI that arrives twice because the NACH retried, the part-payment that must split across penalty, interest and principal in the right order, the restructured loan whose old schedule haunts the new one, the co-lending partner whose ledger disagrees with yours at settlement by an amount too small to escalate and too large to ignore.
Excel and first-generation LMS builds handle the happy path and improvise the edges — and the improvisations compound. Every manual adjustment is a small unexplained fact in your book, and a loan book is exactly the wrong place to accumulate unexplained facts: RBI’s Digital Lending Guidelines (September 2022 — rbi.org.in) and scale-based supervision assume your systems can answer for every flow, borrower-visible fees included. The day the question arrives, “humne adjust kar diya tha” is not an answer — it’s a finding.
What does a lending build include?
- Origination. Application to disbursal: KYC hooks, credit-check integration points, deviation approvals with maker-checker, sanction letters generated from the decision — not typed after it. Every approval carries its reasons, which is what turns an audit sample into a non-event.
- Servicing on computed truth. Schedules as functions, not tables: change a rate or restructure a tenor and the schedule recomputes, with the old schedule preserved as history. Nobody edits rows. Accruals post daily as ledger events, so interest income is a fact rather than a month-end estimate.
- Collections that respect reality. DPD buckets computed from the ledger, promise-to-pay tracking, allocation rules for partial receipts, and the field app — offline-first, geo-tagged receipts, built for the network conditions collections actually happen in.
- Co-lending and partner settlement. Split ratios, fee structures and recovery priority encoded as rules; partner statements generated from the same entries your books run on; daily reconciliation so disagreements surface while they’re one transaction old. The quarterly settlement argument dissolves because both sides read the same arithmetic.
- Reporting from one set of numbers. The regulatory pack, the CEO pack, the ALM feed and the auditor’s samples all drawn from the same ledger — because there is only one ledger. When the returns and the board deck disagree, that’s not a formatting issue; it’s the disease this architecture exists to prevent.
Why is the loan book built as a ledger?
Because that’s what it is — a ledger wearing a costume. Every disbursal, accrual, receipt, waiver and write-off becomes an immutable double-entry event; balances, DPD, and NPA classification become projections you can recompute and prove from history. This is the fintech engineering architecture, specialised for credit — and it changes the texture of the hard conversations. “Why is this account NPA?” becomes a query. “What did we actually earn on this co-lending book?” becomes a report. “Show me every fee this borrower was charged” — the exact question the digital lending framework makes urgent — takes seconds, with evidence attached.
The alternative — balances as columns, corrections as UPDATEs — is how lending books drift, and drifted books in a regulated lender are a different category of problem than in a startup: the auditor is annual, the inspection is real, and the diligence for your next debt line will read your systems the way I read systems for acquirers. Building it right is cheaper than explaining it later, seedhi baat — and the lenders who learn this from a finding rather than a page pay tuition this paragraph was trying to save them.
What should the first quarter deliver?
Concrete outcomes, not vibes. Reconciliation first: receipts matched daily against bank and NACH files, exceptions queued with reasons — the “collections figure vs bank credit” gap named and shrinking within the month. Classification you can defend: DPD and provisioning computed, not curated; the month-end NPA number stops needing a meeting. Co-lending peace: partner statements agreeing by construction, the settlement call reduced to sign-off. And the audit dividend: the statutory auditor’s sampling becomes boring, which is the highest compliment a lending system can earn. Most lenders feel the difference at the first month-end; the board feels it at the first inspection.
Related reading
/industries/nbfc-operations — the back-office layer · /services/fintech — the architecture underneath · /work/reconciliation — the recon engagement · /blog/why-your-ledger-drifts — the failure mode, explained
The month-end test
If your month-end NPA number needs a meeting to defend it — /contact. Hisaab should argue for itself, and in a well-built lending system it does.
Questions I actually get
Do you handle NBFC-specific compliance?
The systems side, fully: classification logic, audit trails, borrower communication records, the evidence an inspection asks for. Your CA and CS own the filings — I make their inputs provable instead of assembled. The dedicated NBFC operations page covers the back-office layer in depth.
Can you migrate us from our current LMS or Excel book?
Yes — parallel-run migration is the house specialty: the book replayed into the new core, old and new reconciled until the difference holds at zero, then cutover. Live loans, live NACH mandates and mid-cycle restructures all survive the move, because the method assumes them rather than hoping against them.
How does co-lending settlement actually work in your build?
Split logic encoded as rules — ratios, fees, priority of recovery — applied automatically at every receipt, with partner statements generated from the same entries your books run on. Daily reconciliation against the partner's numbers catches disagreements while they are one transaction old, which is what kills the quarterly settlement war.
Do you build the field collections app too?
Yes — offline-first, geo-tagged receipts, promise-to-pay capture, synced when the network returns. Collections agents work in exactly the network conditions the field-operations platform was designed for, and the receipt the borrower sees is the receipt your ledger records. One truth, even at a doorstep in the mofussil.
What does RBI's digital lending framework mean for our systems?
Practically: every borrower-facing fee visible and reconstructable, loan flows through regulated accounts, communication records kept, and your books able to answer for any account's full history on demand. The 2022 guidelines assume systems that can prove behaviour — that proof layer is precisely what I build.
How long does a lending core take to build?
A focused servicing-and-collections core lands in weeks on the platform foundation; origination workflows and co-lending add scope per partner complexity. The honest sequencing conversation happens on the first call — most lenders need the reconciliation and classification layer stabilised first, and that alone changes month-end.