Every lending business starts the same way: a spreadsheet. It works beautifully — until it doesn’t. Somewhere between the fiftieth and the five-hundredth loan, the spreadsheet cracks. Interest gets miscalculated. A repayment is applied to the wrong loan. An auditor asks for a document you cannot produce. The founder realizes that “we just track loans in Excel” has quietly become the single largest risk in the business.
A loan management system (LMS) is what replaces that spreadsheet. But building one is deceptively hard. On the surface it looks like arithmetic — principal, interest, a repayment schedule. Underneath, it is one of the most unforgiving domains in software: money must reconcile to the cent, every state change must be auditable, and the rules keep changing because regulators keep changing them.
We have built loan management platforms for lenders across several markets, and the same architectural questions come up every time. Here is how we think about them.
Start With the Loan Lifecycle, Not the Database
The most common mistake we see is teams that model the loan as a static record — a row with an amount and a rate. A loan is not a row. It is a state machine that moves through a lifecycle, and every transition has consequences.
A typical lifecycle looks like this:
Application. A prospective borrower submits a request. Nothing financial has happened yet, but you are already collecting data that KYC and credit decisions will depend on.
Underwriting and approval. The application is scored, checked, and either approved with terms or declined. This is where risk lives.
Disbursement. Money leaves your account and the loan becomes active. This is the moment the clock starts and interest begins to accrue.
Servicing. The long middle. Repayments arrive, interest accrues daily, schedules get recalculated, borrowers ask for restructures, some payments bounce.
Closure. The loan is paid off, written off, refinanced, or sent to collections.
If you model the loan as a state machine from day one, every business rule has an obvious home: what is allowed to happen in this state, and what does each transition do to the balance? If you model it as a mutable row, that logic scatters across your codebase and becomes impossible to reason about. When we start a lending build, the state machine is the first thing on the whiteboard — long before anyone opens a schema editor.
Interest Accrual Is Where Naive Systems Break
Ask three lenders how they calculate interest and you will get five answers. Simple interest, compound interest, reducing balance, flat rate, daily accrual on an actual/365 basis, actual/360, 30/360 — these are not interchangeable, and picking the wrong one means every balance in your system is subtly wrong.
Two principles keep us out of trouble:
Never store a derived balance as the source of truth. The outstanding balance of a loan should be computable from an immutable ledger of events — disbursements, accruals, repayments, fees, waivers. If you store “current balance” as a mutable number and update it in place, you will eventually hit a race condition, a double-applied payment, or a failed transaction that leaves the number lying. When the balance is derived from an append-only ledger, you can always reconstruct exactly how you arrived at any figure, on any date. Auditors love this. So will you, at 2 a.m. during an incident.
Use exact decimal arithmetic, never floats. This sounds obvious and is violated constantly. Floating-point math will cheerfully tell you that a fully repaid loan has a balance of €0.0000000003. Use a decimal type, define your rounding rules explicitly (and per jurisdiction), and apply them consistently. Rounding is not a detail in lending — it is a compliance requirement.
The Ledger Is the Heart of the System
If there is one idea to take from this article, it is this: a loan management system is a specialized double-entry ledger with a lifecycle on top.
Every financial event — a disbursement, an interest accrual, a repayment, a late fee, a waiver — becomes one or more immutable ledger entries. Balances are read models projected from that ledger. This gives you three properties that lending businesses cannot live without:
- Auditability. You can answer “why is this balance what it is?” for any loan, on any historical date, by replaying its entries.
- Reconciliation. Your system’s numbers can be matched against the bank’s numbers, because every movement of money has a corresponding entry.
- Correctness under failure. If a process dies halfway, you never end up with a half-updated balance — you either wrote the entry or you didn’t.
Getting this foundation right is unglamorous work that pays off for the entire life of the product. Getting it wrong means a rewrite two years in, usually triggered by an audit you failed.
Servicing Is 90% of the Work
Founders spend most of their planning energy on origination — the shiny application flow. In production, servicing is where the system actually lives, and it is full of edge cases that never make it into the first spec:
- Partial payments. A borrower pays part of what is due. How is it allocated across fees, interest, and principal? The waterfall order is a business and regulatory decision, and it must be explicit.
- Early repayment. Does the borrower owe future interest? Is there a prepayment penalty? Reducing-balance and flat-rate loans behave very differently here.
- Restructuring and payment holidays. Real borrowers hit hard times. The system must be able to re-amortize a loan mid-life without corrupting its history.
- Delinquency and collections. When does a loan become overdue, then defaulted? What automated actions fire, and what has to stay a human decision?
- Failed and reversed payments. A direct debit bounces after you already marked the loan as paid. The ledger has to unwind cleanly.
None of this is exotic — every lender hits all of it. Systems that treated servicing as an afterthought are exactly the ones that get replaced. We plan the servicing edge cases in the discovery phase, because they are far cheaper to design for than to retrofit.
Compliance Is Not a Bolt-On
Lending is one of the most heavily regulated activities in software. Depending on your market you will face consumer-credit rules, interest-rate caps, mandatory disclosures, KYC/AML obligations, and strict data-retention requirements. These are not features you sprinkle on at the end — they shape the architecture.
Two implications are worth calling out. First, every state change needs an audit trail: who did what, when, and to which loan. Retrofitting an audit log onto a system that mutates data in place is painful; an event-sourced ledger gives it to you for free. Second, document retention has real teeth — loan agreements, disclosures, and KYC evidence often must be retained for years after closure, while GDPR simultaneously grants borrowers data-subject rights. Designing that tension in early is far cheaper than litigating it later.
Build for the Portfolio You Will Have, Not the One You Have
The final architectural question is scale — and here the trap is over-engineering as often as under-engineering. You do not need a distributed microservice mesh to service a thousand loans. But you do need to make choices that will not trap you at a hundred thousand:
- Batch jobs must be idempotent and restartable. Nightly interest accrual across a large portfolio will eventually fail partway. It has to be safe to re-run.
- Accrual should be event-driven where it can be. Recomputing every loan every night does not scale forever; accruing on a schedule of events does.
- Reporting load must not compete with servicing. Finance teams run heavy queries. Keep them off the transactional path with read replicas or a reporting store.
The right answer is usually a well-structured modular monolith with a clean ledger core — something a small team can operate — with the seams drawn so that the parts which actually need to scale independently later can be split out without a rewrite.
The Bottom Line
A loan management system is not a CRUD app with interest. It is a ledger-first, lifecycle-driven, compliance-shaped piece of financial infrastructure, and the decisions you make in the first month determine whether it survives your first audit and your hundred-thousandth loan.
The good news: these are known problems. The lifecycle, the ledger, the accrual rules, the servicing edge cases — they are well understood by teams who have built lending platforms before. The expensive path is discovering them one production incident at a time.
If you are building or replacing a lending platform, this is exactly the kind of system we build. Take a look at our loan management system work, or get in touch to talk through your portfolio and your architecture.