Ten Things Your LMS Needs to Do in 2026
The 2026 LMS requirements list — AI maker-checker trails, 5–10× tool-call EOD throughput, event-sourced accounting, policy-bounded agents, single-binary deployment, and operability for a 20-person team. Lokta Core Phase 2 ships against all ten.
The 2025 Loan Management System specification was a CRUD list. Products, schedules, ledgers, screens. Reporting on top. A vendor that shipped every box could win procurement.
The 2026 specification is operational, not functional. An LMS now has to govern AI actions identically to human ones, sustain backend load no 2025 platform was sized for, expose event-sourced accounting an auditor can replay, and stay operable by a 20-person team. The vendor that ships eight of these has a roadmap problem. Nine, a quarter of project plan. Ten, a platform.
Here are the ten. Lokta Core Phase 2 ships against all of them. If yours does not, the gap is the project plan.
- AI actions sit in the same maker-checker queue as human ones. No two compliance postures in the same loan book.
- COB closes on time at 5–10× tool-call load. Agentic operations break a 2025 backend; 2026 absorbs them.
- Allocations are continuous, not batched. Co-lending and securitization splits settle as events arrive.
- One product engine covers credit line, hybrid, and traditional. Not three integrations stitched at runtime.
- The vendor names a tool-call ceiling. In writing, in the contract — not “contact support.”
- Every AI action maps to a policy boundary a regulator can read. Audit-by-design, not bolt-on logging.
- The platform deploys on-prem, in your VPC, or as single-tenant cloud. One binary, lender’s choice.
- A 20-person team can run it. Operability is a 2026 requirement, not a luxury for the 200-person platform team.
The ten requirements
- 01Hold a maker-checker trail for AI-driven actions, not just human onesEvery agent-initiated commit (reschedule, waiver, write-off, state change) enters the same approval and replay surface as a human one.AI governance
- 02Close COB/EOD on time at 5–10× tool-call loadAgentic operations turn one human touchpoint into 60–120 governed tool calls. The day still has to end at 23:59.Throughput
- 03Allocate collections across partners without a nightly batchCo-lending and securitization splits settle continuously as events arrive — not in a fragile midnight reconciliation.Throughput
- 04Support credit line, hybrid, and traditional in one product modelRevolving, fixed, and hybrid behave as variants of one product engine — not three integrations stitched at runtime.Architecture
- 05Run on-prem, in your VPC, or single-tenant cloud — your choice of binarySame artifact. Lender chooses the deployment shape. No SaaS-only lock-in, no on-prem “fork.”Deployment
- 06Bureau-integrate without a 12-month implementationA new bureau, score, or KYC source is a configuration, not a vendor statement of work.Integration
- 07Expose event-sourced accounting your auditor will sign off onEvery ledger entry is replayable from a typed event stream. No reverse-engineering balances from screenshots.Audit
- 08Surface a tool-call ceiling number, not a vague capacity claimGoverned tool calls per second, per tenant, sustained through COB — in writing, in the contract.Capacity
- 09Map every AI action to a policy boundary you can readEach agent action references the policy version it was evaluated against. Audit-by-design, not bolt-on logging.AI governance
- 10Be operable by a 20-person team, not only a 200-person oneDeploy, observe, upgrade, and tune on a single-binary footprint. The platform doesn’t require a platform team.Operability
Why is the 2026 spec different from the 2025 one?
Three forces converged inside one renewal cycle. Each one breaks a different assumption a 2025 LMS was built on.
A collections, servicing, or KYC touchpoint that used to be 8–15 human tool calls is now 60–120 governed agent tool calls. The LMS is no longer servicing humans on screens — it is servicing software, all day, every day. Throughput, ceilings, and audit semantics all reset.
Regulators stopped distinguishing between a human commit and an agent commit. The auditor wants identical maker-checker, replay, and policy-version attribution on both. An LMS with first-class human governance and bolt-on AI governance is now shipping two compliance models into one loan book — and one of them does not pass review.
The lender’s platform team did not double in size. The platform’s surface did. A 20-person team is being asked to run an LMS, a workflow stack, an agent orchestration layer, an event bus, an evidence store, and an integration surface. The 2026 LMS that needs a 200-person team to keep it standing is the 2026 LMS that gets replaced.
How are the ten requirements actually grouped?
The list reads as ten line items. Architecturally, it is three pillars. A vendor that wins one pillar but loses the other two is shipping a slide, not a platform.
- #01 maker-checker on AI actions. Agent commits enter the same dual-control surface as human ones.
- #07 event-sourced accounting. Every balance is replayable from a typed event stream.
- #09 policy-boundary mapping. Each AI action references the policy version it was evaluated against.
- Why it lives together: the auditor’s question is the same — who did this, under what policy, and can I replay it.
- #02 COB at 5–10× tool-call load. The day still has to end at 23:59.
- #03 continuous allocations. Co-lending splits settle as events arrive, not at midnight.
- #04 one product engine. Credit line, hybrid, and traditional as variants of one model.
- #08 a stated tool-call ceiling. In writing, in the contract.
- #05 one binary, three deployment shapes. On-prem, VPC, single-tenant cloud — lender’s choice.
- #06 bureau-integrate without a project. Configuration, not a vendor SOW.
- #10 operable by a 20-person team. The platform doesn’t require a platform team.
- Why it lives together: all three are the difference between a system the lender owns and a system the vendor rents back to them.
- The ten work as a set. Maker-checker on AI without a tool-call ceiling is theatre. A ceiling without continuous allocations means the ceiling moves to a nightly batch. Continuous allocations without event-sourced accounting means a reconciliation no one can replay.
- The honest 2026 vendor question is not “do you do these?” It is “do these compose?”
What does each requirement actually rule out?
Reading the ten as a procurement list is useful. Reading them as architectural choices the vendor already made is more useful. Each requirement disqualifies a category of platform.
| Requirement | What it disqualifies | Why a 2025 LMS rarely passes |
|---|---|---|
| 01 · Maker-checker on AI actions | Bolt-on AI on a system with no native dual-control on agent commits. | Human approval was modelled on a user; an agent has no user. The data model was never extended. |
| 02 · COB at 5–10× tool-call load | Batch-window architectures that already run hot at human-only traffic. | 2025 EOD budgets were sized for screen traffic plus a few integrations. Agent traffic was not in the plan. |
| 03 · Continuous allocations | Co-lending and securitization handled in a nightly job with reconciliation the next morning. | Allocations were modelled as a daily report, not a per-event commitment. |
| 04 · One product engine | Three separate stacks (revolving / fixed / hybrid) glued together at the borrower screen. | Product engines were specialized to one repayment topology and grew into separate codebases. |
| 05 · One binary, three deployment shapes | SaaS-only vendors and on-prem “forks” that diverge from the cloud branch within a year. | The hosted artifact and the on-prem artifact were built by different teams under different contracts. |
| 06 · Bureau in configuration | Vendor SOWs for every new bureau, score, or KYC source. | Bureau integrations were point-to-point; the platform never invested in a typed adapter layer. |
| 07 · Event-sourced accounting | State-mutation ledgers that lose the why behind every adjustment. | Accounting was a system-of-record snapshot; events were a 2020s afterthought, never load-bearing. |
| 08 · A stated tool-call ceiling | ”Contact support” rate-limit answers and undocumented fair-use envelopes. | The number is a commercial lever; publishing it costs the vendor a tier conversation. |
| 09 · Policy-boundary mapping | Audit logs that record what happened but not which policy version it cleared. | Policies live in a separate engine and are versioned on a separate cycle from the audit log. |
| 10 · Operable by 20 people | Microservice menageries that need a platform team to keep alive. | The decomposition was sold as “future-proofing”; the operability cost was sold separately. |
What does the legacy LMS look like next to a Phase-2 LMS?
The honest comparison is not feature-by-feature. It is what each platform’s defaults make easy, and what each makes a project plan. A 2026 procurement decides which side of the ledger the lender’s team spends the next three years on.
| Dimension | Legacy LMS (2025-vintage) | Lokta Core Phase 2 |
|---|---|---|
| Governance over AI actions | Bolt-on logging. Agent commits sit outside the human maker-checker queue. Auditor reconciles two postures. | Maker-checker is identical for human and agent commits. One queue, one replay surface, one policy attribution. |
| End-of-day under agentic load | EOD window was sized for screen traffic. 5–10× tool-call load pushes COB past the cut-off; SLA breaches at scale. | Throughput sized for governed tool-call traffic. COB closes on time as the agent layer scales. |
| Co-lending allocations | Nightly batch reconciliation. Errors surface the next morning, often as a manual escalation to the partner. | Allocations settle continuously as events arrive. The morning report is read-only. |
| Loan product topology | Revolving, fixed, and hybrid live in separate codebases stitched at the borrower record. Cross-product reporting is a project. | One product engine. Credit line, hybrid, and traditional are variants of the same model. |
| Deployment | SaaS-only, or an on-prem fork that lags the cloud branch. The lender does not choose; the vendor does. | One binary, three deployment shapes: on-prem, VPC, single-tenant cloud. The lender chooses. |
| Bureau / KYC integration time | New bureau or score is a vendor SOW. Six to twelve months is the optimistic case. | Bureau is configuration against a typed adapter layer. New source is a sprint. |
| Accounting model | State-mutation ledger. Audit reconstructs intent from screenshots and side-tables. | Event-sourced accounting. Every balance is replayable from a typed event stream. |
| Capacity claim | ”Contact support” rate limits and undocumented fair-use envelopes. The number is a relationship. | A tool-call ceiling, in writing, per tenant, sustained through COB. |
| Policy attribution | Logs record what happened. Policy version that cleared it lives in a different system on a different cycle. | Every AI action references the policy version it cleared. Audit-by-design, not bolt-on. |
| Operability footprint | Microservice estate needs a platform team to keep alive. 20 people is the floor, not the team. | Polylithic — modules at code time, single binary at deploy time. A 20-person team can run it. |
What does this mean for a 2026 RFP?
A 2026 Loan Management System RFP that does not probe these ten is asking 2025 questions of 2026 platforms. The procurement team’s job is no longer to discover what the vendor can do. It is to discover which gaps the lender’s project plan will absorb.
”How does your platform handle agentic load?” gets a slide. “What is the tool-call ceiling per tenant, sustained through COB, in writing?” gets a number. The number tells the lender what the agentic roadmap is allowed to ship.
Ask the vendor to demonstrate the same maker-checker queue receiving a human commit and an agent commit, with identical replay and policy attribution. If the demo needs two tabs, the audit needs two reconciliations.
The deployment shape decides who owns the data, the upgrade cycle, and the exit. One binary, three shapes (on-prem / VPC / single-tenant cloud) is a 2026 baseline — not a roadmap item.
For every requirement the vendor does not natively ship, ask whose engineering project plan absorbs it. The licence fee is rarely the issue; the project plan around the gap is.
The Lokta read
Lokta Core Phase 2 was not designed against this list. The list was extracted from what Phase 2 already enforces — because the architectural decisions that produce the ten are decisions a platform makes once, at the deterministic core, and either inherits or does not for the next ten years. For lenders evaluating origination alongside servicing, Lokta Originate runs on the same canonical model, so the LOS-to-LMS handoff at disbursement is a state transition, not a cross-system integration.
A vendor that ships eight of these has a roadmap problem. Nine, a quarter of project plan. Ten, a platform.
If yours does not, the gap is the project plan. The honest 2026 procurement question is no longer “can your LMS do this?” — it is “whose project plan absorbs the gap?”
Frequently asked questions
What is an agentic LMS, and what does it need to ship in 2026?
An agentic LMS is a Loan Management System engineered for AI agents as first-class operators on the loan book — not just human users on screens. Three properties qualify in 2026. (1) Maker-checker, dual-control, and replay surfaces apply identically to human and agent commits — the loan book has one compliance posture, not two. (2) The platform publishes a tool-call ceiling per tenant, sustained through COB, that absorbs the 5–10× backend load governed agentic operations generate. (3) Every AI action references the policy version it cleared, so each agent commit is audit-by-design. An LMS that ships AI features without these three is a 2025 LMS with a chatbot bolted on, not an agentic LMS. Lokta Core Phase 2 ships all three as native primitives, not bolt-ons.
What does an LMS need to do differently in 2026 compared with 2025?
The 2025 LMS spec was a CRUD list — products, schedules, ledgers, screens. The 2026 spec is operational. The LMS has to govern AI actions identically to human ones (maker-checker on agent commits), close COB at 5–10× the tool-call load that agentic operations generate, allocate co-lending and securitization splits without a nightly batch, expose event-sourced accounting an auditor can replay, publish a tool-call ceiling instead of a vague capacity claim, map every AI action to a readable policy boundary, deploy as on-prem, VPC, or single-tenant cloud at the lender’s choice, integrate bureaus without a 12-month project, model credit line, hybrid, and traditional in one product engine, and stay operable by a 20-person team. Ten requirements, not features.
Why does maker-checker on AI actions matter?
Because the regulator does not distinguish between a human action and an agent action — and neither does the auditor. If an agent reschedules a loan, waives a fee, posts a write-off, or moves an account through a state transition, that action sits in the same approval, dual-control, and replay surface as a human one. An LMS that has maker-checker on human flows and bolt-on logging on AI flows is shipping two compliance postures into the same loan book. In 2026 that is not a configuration gap; it is a category mismatch.
What is a tool-call ceiling and why should a 2026 RFP ask for one?
A tool-call ceiling is the number of governed tool calls per second, per tenant, that the platform can sustain through a full COB, with every call audited and every event consumed. Agentic operations turn one human touchpoint into 60–120 tool calls; portfolio-level agentic activity easily reaches 5–10× the backend load a 2025 LMS was sized for. A vendor that cannot name the ceiling cannot tell the lender what its agentic roadmap is allowed to ship. The number, in writing, is the difference between a platform and a metered tap.
What does “the gap is the project plan” mean?
It means that if a lender’s incumbent LMS does not natively do these ten things, the missing capability is not a vendor feature ticket — it is the lender’s own engineering project plan. The lender’s team is going to wrap, queue, reconcile, instrument, and migrate around the limitation, for years. Every year of that work is a quarter the agentic roadmap is not shipping. The honest 2026 procurement question is no longer “can your LMS do this?” It is “whose project plan absorbs the gap?”
Read next:
- The LMS RFP toolkit — turn this requirements list into a running RFP: a vendor-neutral checklist, functional-requirements template, scorecard, and security and AI-governance questionnaires.
- Agentic Lending and the 5× Problem — the napkin math behind requirement #02: why governed agentic operations need 60–120 tool calls per account per touchpoint.
- The 30-Call Limit: Why Your LOS API Quietly Caps Your Lending Velocity — the commercial reason requirement #08 (a stated tool-call ceiling) matters.
- Why We Built Lokta Polylithic — the architectural decision behind requirements #05 and #10: modules at code time, single binary at deploy time.
- AI in Lending: Why a Deterministic Core — the principle behind requirements #01, #07, and #09: AI runs above the ledger, never as the ledger.
- Every Lender Replaces Their LMS Eventually — the symptoms that say the 2025 LMS is now a strategic liability.
Ashok Auty is the co-founder of Lokta and co-creator of Apache Fineract. He has spent two decades building lending infrastructure — and the ten things on this list are the ten he wishes someone had handed him every renewal year.
