NBFC Core System — Loan Origination, Servicing & Collections

Why this comes up

The symptoms are always the same.

Lenders rarely call us saying "we need a core system". They call because one of these five things has become impossible to live with — and every one of them traces back to the same root cause: the loan does not live in one place.

If finance and collections disagree about a balance, you do not have a reporting problem. You have two ledgers.

Month-end takes a fortnight

Finance exports from origination, exports from servicing, exports from the collections tracker, and reconciles the three by hand. Every mismatch is investigated manually. The close that should take three days takes eleven, and the numbers reaching your board are two weeks stale.

Fixed by a single ledger

The auditor keeps flagging manual journals

When systems cannot talk, someone posts a correcting entry. Do that a few hundred times a year and your audit report carries a qualification about manual intervention. The fix is not more discipline — it is removing the need for the entry in the first place.

Fixed by maker-checker on every write

A new product takes two quarters to launch

Interest calculation is hard-coded. Adding a step-up EMI, a moratorium or a new charge structure means a developer touching the same file three teams depend on. Meanwhile your competitor launched it in a month because their product rules are configuration, not code.

Fixed by a product configurator

Collections works off yesterday's data

The recovery team pulls a nightly extract. An agent visits a customer who paid this morning. Trust drops, the agent's time is wasted, and the receipt they collect takes four days to reconcile against the bank deposit. Real-time balances are not a nice-to-have here — they are the whole job.

Fixed by one live balance

Nobody will touch the migration

Everyone agrees the core has to be replaced. Nobody will sign off on a cutover weekend that might strand a live book. So the decision gets deferred another year, and the cost of deferring compounds. This is the real blocker in most conversations we have.

Fixed by parallel-run migration

What is inside

Nine modules, one data model.

You do not have to take all nine. Most engagements start with the ledger plus two or three modules, then add the rest once the core is proven in production.

M/01

Loan Origination (LOS)

Lead capture from every channel — branch, DSA, website, agent app — into one funnel with de-duplication. Configurable application forms per product, document checklists that block progression when something is missing, and a stage tracker your sales head can read without asking anyone.

Multi-channelDe-dupeDoc checklist

M/02

KYC & Verification

Aadhaar, PAN, CKYC, GST and bank account verification wired into the application flow, with video KYC where the product allows it. Every check is stamped with who ran it, when, and what the bureau returned — so a query three years later has an answer in the record, not in someone's memory.

CKYCVideo KYCPenny-drop

M/03

Credit Decisioning

A rules engine your credit policy team edits without a developer. Bureau pulls, bank statement analysis, income multiples, exposure limits and deviation rules — each versioned, each with an effective date, so you can prove exactly which policy applied to a loan sanctioned last March.

Rules engineBureauVersioned policy

M/04

Sanction & Disbursal

Sanction letters generated from templates, e-signed and stored against the account. Disbursal to bank, split disbursal for tranche loans, and NACH or e-mandate registration in the same flow. Maker-checker on every disbursal, with limits by role so a branch cannot release beyond its authority.

e-SignNACH / e-mandateTranche

M/05

Loan Servicing (LMS)

The heart of it. Amortisation on reducing, flat or hybrid bases; step-up and step-down EMIs; moratorium and holiday periods; part-prepayment with tenure or EMI reduction; foreclosure with charge calculation. Interest accrual runs daily and posts to the ledger, so the balance is always the balance.

Daily accrualPrepaymentForeclosure

M/06

Collections & Recovery

DPD bucketing that updates the moment a payment lands, allocation to field, tele or digital by risk and geography, and a field app that captures receipts offline. Legal escalation, settlement offers and write-off workflows all post back to the same ledger rather than a parallel tracker.

DPD bucketsField appLegal workflow

M/07

Accounting & GL

Double-entry from the first transaction, with a configurable chart of accounts and posting rules per product. NPA classification and provisioning run on schedule against your policy. Output maps to Tally, SAP, Oracle or Odoo so your finance team keeps the tools they already use.

Double-entryNPA & provisioningERP export

M/08

Co-lending & BC

Split ratios per partner, separate books for your share and theirs, automated settlement files and partner-facing statements. Business correspondent arrangements handled the same way, with commission accrual that reconciles against what the partner invoices you.

Split ratioPartner booksSettlement

M/09

Reporting & Regulatory

Portfolio dashboards for the board, ageing and vintage analysis for risk, and regulatory returns generated from the ledger rather than assembled by hand. Bureau reporting files in the prescribed formats, on schedule, with a rejection log so failures get fixed rather than discovered next cycle.

Board dashboardsVintage analysisBureau files

The part everyone worries about

Migration without a cutover weekend.

A live book cannot be stranded. So we do not do a big-bang switch — we run both systems side by side until the numbers agree, then move traffic in tranches. Here is the actual sequence.

STAGE 01

Map and cleanse

Every field in the old system mapped to the new model, with your team deciding what happens to the rows that do not fit. Bad data gets found here, not on cutover night. Typically four to six weeks on a large book.

STAGE 02

Dry runs

The full migration is rehearsed at least three times into a staging environment. Each run produces a reconciliation report down to the last rupee. We do not proceed until three consecutive runs are clean.

STAGE 03

Parallel run

Both systems process the same transactions for a full cycle, including a month-end. Automated comparison flags any divergence daily. Your finance team signs off on the match before anything moves.

STAGE 04

Tranche cutover

Accounts move in batches, usually by product or branch, over consecutive weekends. If a tranche behaves unexpectedly, only that tranche rolls back. The old system stays available read-only for a full audit cycle.

Rollback is planned before go-live, not improvised during it. Every tranche has a documented reversal path that has been tested in staging, and the decision to use it belongs to your team, not ours.

Controls & compliance

Audit-ready on day one, not year two.

These are not features we add when an auditor asks. They are properties of the data model, present from the first sprint.

Maker-checker everywhere

Any write that moves money, changes a rate, waives a charge or alters a customer record needs a second pair of eyes. Approval limits are configured by role and amount, and the pending queue is visible to the approver rather than sitting in an inbox.

Immutable audit trail

Every state change is appended, never overwritten. You can reconstruct what any account looked like on any past date, and see who changed what and from which IP. Corrections happen as reversing entries, which is what your auditor wants to see anyway.

Regulatory context built in

Our lending team has worked inside RBI scale-based regulation, FCA consumer credit rules and MAS requirements. Asset classification, provisioning norms, fair practice code obligations and data localisation are treated as constraints on the design, not a later remediation.

Data protection

Customer PII encrypted at rest and in transit, with field-level masking so a collections agent sees what they need and nothing more. Retention and purge rules configured per jurisdiction. Regional hosting in the market you choose.

Access that expires

Role-based permissions down to the field, with time-bound elevation for anything unusual. Our engineers work through credentials held in your vault that you can revoke instantly, and every production access event lands in your log, not ours.

Reconciliation as a habit

Bank statements, payment gateway settlements, NACH returns and partner files reconcile automatically each morning, with exceptions queued for a human. Nobody discovers a three-week-old mismatch at month-end because the check runs daily.

Integrations

It has to talk to what you already run.

A core system that needs everything else replaced is not a core system, it is a rebuild of your whole estate. These integrations are standard work for us, not custom projects.

Ask about a specific integration

Category	What connects	Typical effort
Credit bureaus	CIBIL, Experian, Equifax, CRIF High Mark — pull, parse and store the report against the application.	1–2 weeks each
Payments	NACH and e-mandate registration, UPI autopay, payment gateway collections, virtual account allocation for inward credits.	2–4 weeks
Identity	Aadhaar and PAN verification, CKYC registry, video KYC, penny-drop bank account validation.	2–3 weeks
Accounting	Tally, SAP, Oracle Financials and Odoo — scheduled journal export or live API posting, whichever your finance team prefers.	2–3 weeks
Communication	SMS, WhatsApp Business, email and IVR for reminders, receipts and statutory notices, with delivery status stored on the account.	1–2 weeks
Documents	e-Sign providers, e-Stamp, digital locker retrieval and object storage for the loan file.	2 weeks

Proof

A ₹4,000 crore book, moved without stopping.

NBFC · Secured & unsecured lending 🇮🇳 India · 14 months · Under NDA

Three loan systems consolidated into one ledger, with no business-day downtime

The problem

Origination, servicing and collections had been bought at different times from different vendors. Collections worked off a nightly export, finance reconciled three sources by hand, and month-end close took eleven days. The statutory auditor had flagged manual journal entries in two consecutive reports.

What we did

Built the core on a single double-entry ledger with maker-checker on every write and daily interest accrual. Migrated 1.1 million loan accounts in eight tranches across four weekends, with old and new running in parallel and automated reconciliation between them until the numbers matched to the paisa. The legacy systems stayed read-only through a full audit cycle.

What changed

Finance closes in four days instead of eleven. Collections agents see live balances, so nobody visits a customer who paid that morning. Two new loan products launched in the following quarter using the product configurator, with no developer involvement.

11 → 4

Days to close the month

1.1M

Accounts migrated

0

Hours of downtime

Before you call

What lenders ask us first.

Straight answers, including the ones that might rule us out.

Ask something else

Nine months for a single-product lender with a clean book. Twelve to eighteen for a multi-product NBFC with co-lending and a legacy migration. The migration itself is usually a third of the timeline — mapping and dry runs take longer than people expect, and that is where the risk actually sits. We will give you a range at the end of discovery, and it will not move unless you change the scope.

A build, on top of modules we have written before. You own the code and it runs in your cloud. There is no per-account licence fee and no annual renewal that grows with your book. What we reuse from our own libraries is licensed to you perpetually and royalty-free, so nothing creates a dependency on us after handover.

Sometimes, and we will say so if that is the cheaper answer. If your servicing engine is sound and the problem is collections or reporting, building around it is faster and less risky than a replacement. We have taken that route several times. If the ledger itself is the problem, patching around it just adds a fourth system to reconcile.

Closed accounts and transaction history migrate with the live book, because your retention obligation does not distinguish between them. Where old data is genuinely unusable, your team decides what happens to it during the mapping stage — we do not make that call quietly. The legacy system stays available read-only for a full audit cycle after cutover.

Your choice of three. You take it in-house with runbooks, documentation and two to four weeks of pairing with your engineers. You keep a reduced pod for ongoing releases. Or we operate it under a managed SLA with agreed response times and a named escalation path. Roughly a third of lending clients pick each option.

Yes. The ledger and servicing engine are jurisdiction-neutral; what changes is the regulatory layer, the payment rails and the bureau integrations. We have delivered lending platforms into the UK and Singapore. For a market where we have not worked before, we will bring in local compliance counsel and tell you what that adds to the cost before you sign.

Often paired with

What lenders add next.

Collection Management

The recovery side as a standalone product — allocation engine, offline field app, geo-tagged receipts and same-day deposit reconciliation.

View product

Agent Institutions

If you source through DSAs or business correspondents — onboarding, tiered commissions, wallet top-ups and settlement cycles.

Explore service

Customer App

Statements, EMI payments, prepayment requests and document downloads — reading from the same ledger, so the balance shown is the balance owed.