Loan Management System (LMS)
A loan management system built as a ledger.
Any retail credit product, without touching code.
Lending software is built one product at a time. Lokta Ledger inverts that, in three layers. A double-entry, event-sourced ledger computes every schedule to the paise and books every event. A product builder composes each loan product from 190 configuration parameters rather than code. Andproduct applications run each loan type on that one record, from disbursal through collections to closure.
Pick one product. We replay its book on the Ledger and show you every figure that lands differently. Nothing moves off your core, and a reply comes inside a business day.
The category
The loan management system is where the book actually lives.
A loan management system (LMS) is the system of record for a loan after disbursal: schedules, repayments, interest, charges, restructuring, write-offs, and the audit trail behind every change.
Most LMS platforms grew one product at a time, and the loan product became whatever the modules could be made to do. We built ours as a ledger, and rethought the loan product from the ground up on top of it. Every construct on this page, from day-count to appropriation waterfall to foreclosure regime, is a parameter on one engine rather than a feature bolted onto twenty.
Where a foundation model expresses capability through billions of weights, Lokta Ledger expresses it through parameters: interest method, day-count, appropriation waterfall, broken-period interest, moratorium behaviour, multi-tranche disbursal, foreclosure regime, NPA classification, and a hundred more.
Why rebuild
The old architecture fails the institution first.
The lender pays for the architecture long before a borrower sees a wrong number. It shows up in projects that never end and in objectives quietly cut to fit the system.
At any moment, a lender is migrating off a core, evaluating vendors, or mid-implementation. That treadmill is the architecture confessing. Launches miss the market window they were priced for, and business objectives shrink to whatever the system can do.
The compounding cost is regulatory. Every RBI change, and every equivalent move by a supervisor anywhere else, gets re-implemented product by product, each copy carrying its own bugs. Compliance becomes a recurring war room instead of a one-time update.
Why a ledger
A loan is three ledgers. One of them is the future.
A deposit account is one balance. A loan is three interlocked books that must agree to the paise, and legacy systems keep them in separate places, then reconcile by hand.
Ledger 01
Obligation
The schedule: what is owed and when, split across principal, interest, fees and penalties across years of future installments.
Ledger 02
Money
What was actually paid, value-dated, appropriated back against the obligation in a regulator-blessed order.
Ledger 03
Collateral
The security position: tracked, revalued, and released exactly as the obligation runs down.
The obligation ledger is a mutable future. Every prepayment, rate reset, moratorium, restructure and backdated correction re-generates it, deterministically, to the paise, under RBI’s rules. Interest is computed truth, not a recorded fact. Lokta Ledger holds all three books as one source of truth, so the book is right by construction, not right after reconciliation.
The product builder
A loan product is composed from configured primitives.
The primitives are the vocabulary. The product builder is where they become a product: one versioned record that credit approves, engineering consumes and the ledger executes.
Common configurations, handled everywhere.
Standard schedules, standard charges, standard repayment. Every lending system in the market already does these, and no lender wins or loses on them.
The long tail, built into the foundation.
Broken-period treatment, appropriation order, co-lending splits, penal charge rules, subvention, foreclosure regimes. The configurations that are hardest to get right, and the ones that decide whether a product launches on time.
The long tail is where traditional systems run out of configuration. The hard part falls to custom code, written per lender and per product, which is why a change to a loan management system typically takes weeks. We built the ledger from the ground up around those constructs instead. They live in the same parameter set as everything else, so what would normally be a change request is a setting, and the same change lands in hours to days rather than waiting on an engineering cycle.
STAGE 01
Build
Set the primitives that define the product: ticket and tenor, interest method and day-count, charges, appropriation order, moratoria, foreclosure regime. Contradictory settings are refused before the product can be tested.
STAGE 02
Simulate
Scenarios book real loans against the engine and read the results back: schedules, charges, corner cases. The same product and inputs return the same numbers every run.
STAGE 03
Sign-off
The review panel is derived from what this product configures rather than a fixed matrix. Finance signs the GL mapping, risk the classification, compliance the KFS and penal charges. The next stage stays locked until every seat signs.
STAGE 04
Integrate
The API surface and agent tools are generated from the exact version, carrying the product’s own bands and limits, so a change is diffable rather than discovered in production.
STAGE 05
Pilot
Release it into a bounded slice of the book, with the origination limits and the delinquency level that pauses it recorded against the version.
One record, read the same way by everyone. Treated as configuration data, a product leaks: the differentiating logic falls to vendor code, and the approved rule stops matching the built rule. Here the authors, the reviewers and the systems that consume it all read the same version, so no function signs off one product while another builds a different one.
Product applications
Each loan type composes from the same primitives.
A home loan and an invoice facility behave nothing alike in servicing, but they do not need to be separate systems. Each is composed in the builder from the same primitives and runs on the same ledger, carrying the servicing behaviour that loan type actually needs.
The three layers are what makes servicing end to end. The ledger computes and books every event. The builder composes the product and governs its versions. The applications run the loan from disbursal through collections to closure or recovery. Because all three sit on one record, a repayment, a restructure or a write-off lands once and is right everywhere, with no second system to reconcile.
Specification
The engine, on paper
The parameter counts below describe the engine as it stands today.
- Parameters
- 190 across 19 configuration domains
- Expressiveness
- If it fits on a term sheet, it runs on the engine, flat or reducing, bullet or EMI, step-up, moratoria, tranches, subvention: every retail construct we’ve met in fifteen years, expressed as configuration
- Product coverage
- 20 retail product types
- Templates
- 20 products × 10 built-in variants, 200 launch-ready templates, configurable and programmable
- Validation
- ≈500,000 automated test cases · 1,000 paise-exact golden schedules
- Compliance, native
- RBI IRAC/SMA · KFS/APR · Penal-charges 2024 · Prepayment Directions 2025 · Ind-AS EIR/ECL
- Determinism
- Full replay: hand the engine any loan's history and it re-derives today's book, entry by entry
- Time to product
- Ideation to live product in hours, not quarters. A regulatory change lands once and every product inherits it
Fine print: every number above describes the engine as it stands today; test counts are published as run in CI.
How it works
Configure. Compute. Post. Service. Replay.
One engine under every product, the product layer is pure configuration.
01
Configure
Pick a template or set the 190 parameters, from day-count to appropriation to foreclosure regime.
02
Compute
The engine solves the schedule, paise-exact, broken periods and moratoria included.
03
Post
Every event books double-entry to the mapped GL heads. No side-system to reconcile.
04
Service
Payments, prepayments, resets, restructures and NPA. The full life, re-amortised correctly.
05
Replay
Re-derive any book from its history, entry by entry. Proof on demand.
Capability benchmark
Against the field
The dimensions below decide whether a servicing system survives contact with a real book.
| Capability | Lokta ledger | Legacy LMS | In-house build |
|---|---|---|---|
| Day-count conventions | 6 | 2-3 | 1 |
| Appropriation strategies | 11 | 3-4 | 1-2 |
| Broken-period interest | first-class | workaround | none |
| Moratorium behaviours | 9 typed | 2 booleans | hand-coded |
| Multi-tranche + re-amortise | ✓ | partial | ✗ |
| RBI-2025 NIL-foreclosure logic | ✓ config | manual | code change |
| NPA → IRAC/SMA | ✓ automated | partial | manual |
| Book re-derivable from history | ✓ replay | ✗ | ✗ |
| New product: config → launch | hours | weeks | months |
EVALUATIONS & LIMITATIONS
Tested like an auditor. Scoped like an engineer.
Evaluations
We hold the engine to the standard a lender’s auditor would. Every schedule is verified installment-by-installment, to the paise, against a golden reference.
The configuration space is too large to test exhaustively, the 15 most-used levers alone admit over a billion combinations. So we test it the way avionics software is tested: ≈500,000 automated cases through combinatorial design, pairwise across all 190 parameters, three-wise across the ~30 interacting money-path parameters, and the full loan lifecycle: disburse, bill, part-pay, prepay, restructure, classify, foreclose, write off.
- ≈500,000
- Automated cases
- 1,000
- Golden schedules
- ₹0.00
- Tolerated drift
Limitations
- Lokta Ledger is a servicing and computation engine, not a credit-decisioning model. It configures and runs the loan; it does not decide whom to lend to.
- The money path is deterministic by design, with no ML inside it, so every rupee is explainable and reproducible. AI operates on top of the ledger, never inside it.
- Group and JLG lending are outside the current retail scope.
Getting started
Adoption begins with a Drift Audit, before any migration decision.
We never ask a lender to cut over a live book. The first engagement is aDrift Audit: bring us one product, and we show you where our numbers and yours disagree before anything moves.
Step 1
Start with one product
Share the transaction history for a single product, anonymised however your team is comfortable. Nothing touches your live system, and we work with the data in whatever shape it already exists.
Step 2
We replay it on the ledger
Lokta Ledger re-derives that book from its own history: every schedule, every appropriation, every classification, entry by entry.
Step 3
We walk the differences together
You see where our numbers and yours agree, and where they do not, with the reasoning behind each difference. That picture is what tells you whether moving across is worth doing, and how easily it would go.
From there, adoption is gradual by design. The ledger can runalongside your live book, so you keep seeing both sets of numbers side by side. New lending moves across one product at a time, and the existing book runs off where it already sits. Nobody is asked to jump, and you can check the numbers each morning before deciding on the next step.
Talk to usLoan management system, frequently asked questions
Rollout, deployment, configuration depth, integrations, and where AI sits relative to the ledger.
Does Lokta do loan origination or underwriting?
No. Lokta runs the loan book after approval: servicing, monitoring and early warning, collections, and recovery. For the next 6-9 months that post-approval book is the entire build focus. Lenders keep the loan origination system they already run and hand off to Lokta at disbursement, through a canonical product and party mapping. Lokta does not decide whom to lend to, and origination on the same canonical model is a later horizon on the roadmap rather than something you can buy today.
What is a loan management system (LMS)?
A loan management system is the system of record for a loan after disbursal: schedules, repayments, interest, charges, restructuring, write-offs, and the audit trail behind every change. Lokta Ledger is that system of record, built as a double-entry, event-sourced ledger rather than as a set of per-product modules.
How long does a loan-management rollout take?
Timelines depend on integration scope, data migration, and policy configuration, so we scope them per lender rather than quoting a number here. The first engagement is a Drift Audit on one product, not a migration.
Where can Lokta run?
On-prem, single-tenant cloud, or VPC. You choose the data residency. Same binary either way: we ship modules, you operate one deployable.
How do you handle data residency for cross-border lenders?
Schema-per-tenant isolation plus per-tenant deployment topology. Tenants pin to specific regions, and tenant boundaries are enforced at the schema level, not just the application layer.
How customisable is the loan product engine?
Compositional: 190 parameters across 19 configuration domains covering interest method, day-count, appropriation waterfall, moratorium, tranches, foreclosure regime, NPA classification and more. Most loan products assemble from configuration, not code. New product variants typically ship in days, not weeks.
What integrations are available?
A governed OpenAPI 3.1 surface with header versioning is in the platform today. KYC, credit bureau, payment gateway, core-banking bridge, accounting connectors, and SMS / email are delivered with deployment, sequenced to your priorities, with a delivery window the founder commits to in the RFP response.
What is your AI position?
The money path is deterministic by design, no ML inside it, so every rupee is explainable and reproducible. Agents operate on top of the ledger: servicing operations, collections, borrower and portfolio agents run against canonical state, governed APIs, identity for agents, and audit trails. AI proposes, the core decides, the record proves it.
How is Lokta different from Apache Fineract?
Same heritage, different generation. We helped build Apache Fineract, the world’s most widely deployed open-source lending core; Lokta is what that team would build starting today. The architectural diff is set out in the Lokta vs Apache Fineract comparison.
A book that cannot drift.
A product launch that fits in an afternoon.
The loan book, rebuilt from the ledger up.