Loan Management System (LMS)Available now
A loan management system built as a ledger.
Any retail credit product, without touching code.
Lokta includes a Loan Management System for banks, NBFCs and fintech lenders. It maintains approved loan accounts, repayment schedules, dues and balances, with loan accounting, collections and reporting on the same platform. Lending Partner Management covers partner onboarding, activity analysis and monthly payouts.
The full loan servicing stack also includes collateral management, Loan Product Studio, compliance workflows and governed AI. Payment gateway and bureau connections are scoped and tested for your deployment.
Bring one product and a representative loan history. Compare the replayed figures before planning a move.
How it works
The repayment schedule, computed, posted, serviced and replayed.
One engine under every product, the product layer is pure configuration.
01
Configure
Pick a template or set the 200 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.
The loan management system is where the book actually lives.
The category
A loan management system (LMS) is the system of record for a loan after disbursal: the repayment schedule, repayments, interest, charges, collections, write-offs and the audit trail behind every change. Lokta’s LMS holds that record as one double-entry, event-sourced ledger, so each retail loan product is configuration on a single engine rather than its own module.
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.
The old architecture fails the institution first.
Why rebuild
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.
A loan is three ledgers. One of them is the future.
Why a ledger
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 the allocation order configured for the loan.
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 product rules configured and validated for your deployment. 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.
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.
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 volume limits for new loans 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 runs servicing and collections on the same record.
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.
Three layers, one servicing record. The ledger computes the repayment schedule and books every event. The builder composes the product and governs its versions. The applications run the loan from disbursal through early warning, collections and closure or recovery, with delinquency read off the same record. 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.
The loan management system, on paper
Specification
The figures below describe the engine as it stands today.
- Interest & accrual
- Day-count conventions
- Schedule shape
- EMI & rounding
- Broken-period interest
- Moratorium
- Disbursal & tranches
- Repayment & frequency
- Appropriation waterfall
- Fees & charges
- Penal charges
- Prepayment & foreclosure
- Rate reset
- Restructure
- Subvention
- NPA & irac/SMA
- Ind-AS EIR/ECL
- GL mapping
- KFS & APR disclosure
- Parameters
- 200 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
- Combinatorial automated cases, pairwise across all 200 parameters and three-wise across the interacting money-path parameters · paise-exact golden schedules, verified installment by installment
- Compliance, native
- RBI IRAC/SMA · KFS/APR · Penal-charges 2024 · Prepayment Directions 2025 · Ind-AS EIR/ECL. Shipped for India’s regime; for a supervisor elsewhere the same parameters express Basel-aligned staging and IFRS 9 expected credit loss, the global twin of Ind-AS ECL
- Determinism
- Full replay: hand the engine any loan's history and it re-derives today's book, entry by entry
- Time to product
- A product configures and simulates in hours; ideation to a signed-off pilot is days to weeks, depending on your review panel. A regulatory change lands once and every product inherits it
Fine print: every figure above describes the engine as it stands today.
Loan management system benchmark against legacy LMS and in-house builds
Capability benchmark
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 | fixed per module | as coded |
| Appropriation strategies | 11 | fixed per module | as coded |
| Broken-period interest | first-class | workaround | none |
| Moratorium behaviours | 9 typed | boolean flags | hand-coded |
| Multi-tranche + re-amortise | ✓ | partial | ✗ |
| Prepayment Directions 2025, nil foreclosure charges | ✓ config | manual | code change |
| NPA → IRAC/SMA classification | ✓ automated | partial | manual |
| Book re-derivable from history | ✓ replay | ✗ | ✗ |
| New product: configure and simulate | hours | release cycle | engineering cycle |
The Lokta column is the engine as it stands today. The other two columns describe the pattern we meet in the field rather than any named product; check a specific system against its own documentation.
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: automated cases generated by combinatorial design, pairwise across all 200 parameters, three-wise across the ~30 interacting money-path parameters, and across the full loan lifecycle: disburse, bill, part-pay, prepay, restructure, classify, foreclose, write off.
- Pairwise
- Across all 200 parameters
- Three-wise
- Across the money path
- 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 a Drift 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.
Agree the implementation scope before a rollout
- Which system owns balances, loan state and financial posting?
- Which product rules, historical events and reconciliation tolerances must the Drift Audit cover?
- Who owns each integration, exception queue, approval and acceptance decision?
- What hosting, access, cutover and rollback requirements must be tested?
Use the migration playbook to document evidence and acceptance gates. Delivery timing follows the agreed scope.
From there, adoption is gradual by design. The ledger can run alongside 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 usNot included today
Loan Origination is on the roadmap, with no published date; the approved loan arrives from your LOS, or your partner lender's, by API. There is no leasing module. The three pricing tiers are on the pricing page, and the questions lenders ask on calls, from Tally export to hosting, are answered on the FAQ page.
What lenders said
Lenders on the loan management screens.
After the portfolio dashboards
“This kind of concise and clear dashboard I never saw.”
On why Lokta starts after sanction
“The post-sanction area is the one which still today remains a grey area.”
On hearing the rate, ₹1,000 per crore of book a month
“It's a reasonable price.”
On the partner and payout view
“Traditional systems never had something like this.”
On seeing bucket roll-back and roll-forward at account level
“My team takes half a day today just to get this data out manually.”
Asked when he wanted servicing automated
“At this point, I can start within a month.”
At the end of the demo
“You have covered all the pain points of the smaller NBFC.”
Loan management system, frequently asked questions
Rollout, deployment, configuration depth, integrations, and where AI sits relative to the ledger.
Does an LMS need to include loan origination?
An LMS maintains the loan account through repayment and closure. An LOS handles applications, underwriting and approval. Lokta provides Loan Management today and accepts approved loans from a lender’s LOS by API. Loan Origination is a separate roadmap capability.
Does Lokta do loan origination or underwriting?
No. Lokta covers the loan book after approval: servicing, monitoring and early warning, collections, and recovery. Loan Origination is on the roadmap and is not available now. No release date is published. 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.
What is a loan management system (LMS)?
If you run a book after disbursal, the loan management system is the record everything else reads from: what each borrower owes and when, what was paid and how it was appropriated, where the account sits on delinquency, and who changed what. Lokta builds that record as a double-entry, event-sourced ledger, with each loan product held as configuration rather than as its own module.
What does loan accounting in an LMS cover?
Every loan event, from disbursal through repayment, accrual, charges, waivers and write-off, posting double-entry to the general ledger heads the lender maps. In Lokta those entries come from the same event-sourced ledger that computes the schedule, so the loan book and the accounts are one record and there is no side system to reconcile at month end.
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: 200 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. A new variant configures and simulates in hours; the signed-off pilot follows in days to weeks, set by your review panel.
What integrations are available?
A governed OpenAPI 3.1 surface, versioned in the path so a new version never replaces the one you built on, 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.