Build Vs. Buy Loan Management Software (LMS)
Compare building, buying and composing an LMS by who owns loan servicing exceptions, policy changes and releases. Use a decision matrix before choosing a stack.
For an NBFC CEO and CTO choosing a Loan Management System (LMS), the build-versus-buy decision is a choice about who will carry the work after launch. A demo can prove that a repayment screen exists. It cannot prove who will fix a disputed calculation, test a policy change or restore service when an integration fails.
Build only when a material business requirement justifies it and you can fund named owners for interest calculations, accounting entries and regulatory change over a five-year planning horizon. Otherwise, buy a platform whose behaviour you can verify, and spend the internal effort on policy, acceptance and the change process. Source-code access is not a substitute for that team.
The LMS maintains the loan account. Servicing is the work across its life. A lender can keep a sound account system and build a distinctive servicing workflow around it without rebuilding the ledger.
Define the work that remains with the lender
Start with one sheet listing the account calculations, policy decisions, servicing workflows and interfaces your book needs. For each, identify who defines the requirement, implements it, tests it, approves it and handles a failure. “Vendor” and “IT” are too broad to be useful assignments.
Separate the financial account from the work around it. An agent may prepare a borrower reply or propose a permitted action. The calculation and posting controls need a named authoritative system. A new interface should not quietly become a second place that decides the balance.
The lender also retains judgment about acceptable outcomes. A supplier can demonstrate a rule and provide evidence. Someone accountable for the book must decide whether that rule matches the agreed product and policy.
Compare three ownership models
Choose the boundary at which control is worth its continuing cost. A supported extension of a purchased core can be part of a build; record which calculations and interfaces your engineers will actually own.
| Path | Reason to choose it | Responsibility to fund |
|---|---|---|
| Build and operate | Distinct requirements justify control over implementation | A continuing team for releases, incidents, calculations and security |
| Buy a supported platform | Its verified behaviour fits the book and the support boundary is acceptable | Lender policy ownership, acceptance testing and provider oversight |
| Compose around an account system | The core works, but a surrounding workflow needs a different capability | Cross-system consistency, interfaces and a named incident owner |
An open-source base changes the starting material, not the ownership question. Apache Fineract provides open-source financial services software and explicitly directs operators to competent technical resources for secure deployment and operation. Our open-source LMS guide examines that route in more detail.
Buying deserves the same scrutiny. “Included in the platform” can mean configurable now, available through a supported extension, or subject to a future project. Ask for the demonstrated state and contractual scope of the capability you intend to use.
Composition is attractive when the account system is sound. It becomes harder when several components disagree about the amount due or the status of a payment. The integration owner needs authority to resolve that disagreement, with the lender’s approval where required.
What the engineering owner inherits
Published open-source lending issue reports make the responsibility concrete. A first-period calculation report described a schedule using 31 days where the reporter expected five. A separate instalment-rounding report described a configured rounding multiple not appearing in the resulting schedule. These are historical reports, not evidence about a current vendor or a Lokta deployment; the first was closed as abandoned, not as a verified fix.
The point for a sourcing decision is what happens after someone reports the mismatch. An engineer must reproduce it, identify the relevant product settings, agree the expected calculation with finance and add regression cases before release. If the account already has transactions, someone must also establish which historical outputs need correction.
A published retry-hardening task, still in progress when checked, raises another obligation: proving what happens when a financial command succeeds but its response is lost. Ask who owns the test and the recovery process. A proposal in an issue tracker is not shipped behaviour.
These are better selection questions than a count of features. The LMS selection mistakes guide explains how to keep acceptance evidence in the procurement decision.
Put one post-launch change through every option
For a concrete evaluation exercise, suppose the collections head wants to change the reminder sequence for one existing borrower segment. The request changes contact timing under the lender’s approved policy. It does not change loan terms or authorise a new debit.
Ask each candidate team to explain the complete path from request to an observable production result. Who selects the eligible accounts? How is the old sequence stopped? What happens to messages already queued? Can the previous policy be restored without contacting the same borrower twice?
For a build, the answer needs a funded implementation and testing owner. For a purchase, it needs the permitted configuration surface, approval path and any provider dependency. For a composed stack, it needs agreement between the account state and the contact system at the point of action.
Run the exercise against a normal account, a just-paid account and an account with unresolved payment evidence. The team should show which action each receives and why. A configuration screenshot is only the start of the test.
Change requests have two prices
The first is the invoice and internal effort. The second is the time during which the business waits or carries a workaround. The LMS customization trap starts when routine operating changes repeatedly become supplier projects. A change with little coding can still take a long time if it crosses specification, provider scheduling, regression, approval and deployment queues.
Record elapsed time separately from engineering effort. Ask for evidence from an agreed trial or a contractual commitment, rather than converting a sales estimate into a delivery promise. If a delay affects a product launch, estimate its economic effect with explicit assumptions. Lost revenue and lost profit are different quantities.
The LMS cost guide provides the cost comparison. This decision needs an additional question: which changes must the lender be able to make without waiting for a supplier, and which changes should remain tightly controlled regardless of speed?
Reject an option when ownership is missing
A weighted feature score can hide a serious gap. Do not let a strong user interface offset the absence of a workable recovery or account-reconciliation process.
- A named owner for each calculation, policy decision, interface and release.
- A demonstrated routine change, including queued work and rollback behaviour.
- An incident walkthrough showing who diagnoses, corrects and verifies the account.
- A continuing budget for maintenance, security and lender acceptance work.
- A usable export and transition plan for the records another operator would need.
If the build has no continuing team, its attractive first-year estimate is incomplete. If a purchase cannot explain its change boundary, its roadmap remains a dependency. If a composed stack has no owner for a cross-system incident, its interfaces have created work nobody has accepted.
Make the final choice against the live book
Lokta offers Loan Management and AI Loan Servicing for the post-approval book. Evaluate that route with the same account and change tests you would apply to an internal build or another provider. The team’s earlier work includes Apache Fineract. That experience gives a reason for the conversation, while the evidence from your evaluation should decide the fit.
Write the ownership decision before the price negotiation: the named team, the changes it controls and the incidents it must resolve. Discuss Lokta’s scope against that document. If nobody can sign for the work after launch, the sourcing decision is unfinished.
Frequently asked questions
When should a lender build its own LMS?
Build when a material requirement cannot be met through an acceptable platform or extension, and a funded team will own calculations, accounting, security and regulatory changes over a five-year planning horizon. Otherwise, buying and controlling the change process is the more defensible starting point.
Does buying an LMS remove the need for an internal technology team?
Buying can move implementation and software maintenance work to a provider under an agreed scope. The lender still needs people who can define policy, verify account results, manage data and integrations, accept releases and oversee the provider. The exact staffing depends on the operating model. Ask which tasks remain with the lender and who performs them during an incident, rather than assuming that a subscription covers every responsibility.
What is a composed loan management stack?
A composed stack uses a selected account system with separate components for work such as borrower communication, collections or reporting. It can preserve a sound core while changing another workflow. The lender must define which system owns each fact and how updates reach the others. A composition decision therefore needs reconciliation, failure handling and release ownership as well as an integration diagram. More components do not automatically mean more freedom.
How should change requests affect a build-versus-buy decision?
Compare the invoice, internal effort and elapsed time to a tested release. Include specification, provider queues, regression, approval and deployment. Put the same change through each option: who can make it, who verifies it, and how long the business carries the workaround?
Read next
- Open-source loan management systems: understand what an open-source core leaves to its operator
- LMS pricing and TCO: compare the costs once the responsibility boundary is clear
Sources
- Apache Fineract project: open-source financial services software and the need for competent secure deployment and operation, checked 2 October 2026
Lokta editorial analysis by Chandramouli, co-founder and CEO.
