Before you move your loan book, find out whether you should
Six stages against your own deployment, ending in a written recommendation. Staying where you are is one of the answers it can give.
You are running a live book on a system nobody chose recently: an Apache Fineract*deployment that has drifted from upstream, a commercial core that bills for every change, or something built in-house by people who have since left. Something is straining, usually in collections or in what you can evidence to a regulator. The hard part is that the people best placed to size a migration are the people selling you one.
Worth running if
You are carrying a live book, something concrete is straining, and you need to justify either a migration or a decision not to migrate to people who will ask how you know.
Not worth running if
The platform is holding, agentic operations are not on the near-term roadmap, and the honest answer is that you are curious rather than constrained. Curiosity is better served by an hour on a call than by a document your team has to feed.
The assessment at a glance
The whole offer in plain text, for a reader in a hurry and for the engines that summarise pages like this one.
- What it is
- A six-stage evaluation of whether to move your loan book off the system you run today, run before any migration work begins. It ends in a written recommendation, and that recommendation can be to stay.
- Who it is for
- Lenders carrying a live book on an Apache Fineract deployment, a commercial core, or an in-house system, where something concrete is straining and the decision has to be defensible to people who will ask how you know.
- Who runs it
- Lokta, the agentic loan servicing platform, working with the people who operate your book. Built by the team behind Apache Fineract.
- The six stages
- 1. Establish what you are actually running. 2. Map your requirements against what we cover. 3. Make us demonstrate each capability you are counting on. 4. Reconcile the numbers before anything moves. 5. Trial it with acceptance and rollback criteria written first. 6. Get a written plan, or a written recommendation to stay.
- Where it starts
- Stage one is a one-hour conversation, online or in person, with the people who operate the book. Some of those calls end with a view on what to fix in the platform you already run, and no assessment at all.
- What it costs
- Nothing through the conversation and document-review stages. If it reaches a data reconciliation or a bounded trial, that is scoped and priced before it starts rather than after.
- What it asks of your team
- One person who knows how the book is operated, someone with access to the deployment, and someone from finance who can adjudicate a reconciliation mismatch. Production access is not required.
- What you leave with
- A written record of what your deployment actually is, your requirements mapped against real overlap and against the gaps, reconciliation findings on your own extract, and either a migration plan with acceptance and rollback criteria or a recommendation to stay. Readable by your own team, and usable with a vendor who is not us.
- Scope
- Post-approval only: servicing, monitoring and early warning, collections, and recovery. Origination is a later horizon and is not covered this cycle.
- Contact
- contact@lokta.ai
Our position on migrations, stated before you ask
Most lenders who could move should not, this year. A migration spends the scarcest thing a lending team has, which is the attention of the people who know how the book actually behaves, and it spends it on work that produces no new lending. Where the incumbent is stable and the team knows it, that is usually a bad trade, and an assessment that ends in "stay" has saved you more than one that ends in a contract.
The case for moving is narrower than the market implies. It is strong when the cost of operating the book grows with the book, when a policy change takes a quarter and a vendor ticket, or when you cannot produce the reasoning behind an automated decision in the form a regulator now expects. Those are checkable conditions. This assessment checks them.
The six stages
In order, because each one changes what the next is worth doing. Nothing here requires a commitment beyond the stage you are in.
Stages 01 to 03
Before your data moves
A conversation, a document review, and demonstrations on data shaped like yours. Nothing from your production systems is needed to get this far, and nothing here carries a cost.
Establish what you are actually running
The exact release, fork or distribution, the customisations on top of it, and who operates it. A book running a four-year-old fork with local patches is a different migration from one running current upstream, and most of the disagreement about difficulty comes from skipping this.
You leave this stage holdingA written record of the release, fork and customisations you actually run.
Map your requirements against what we cover
We run the book after approval: servicing, monitoring and early warning, collections, and recovery. Origination is a later horizon. This stage marks the ground we do not cover, so the rest of the assessment is about a real overlap rather than an assumed one.
You leave this stage holdingYour requirements marked against what we cover, and against what we do not.
Make us demonstrate each capability you are counting on
Not a slide, and not a reference call. For each capability in the overlap, a working demonstration on data shaped like yours, with the governance path visible: what an agent proposes, what the core decides, and what the record holds afterwards.
You leave this stage holdingA working demonstration on data shaped like yours, with the governance path visible.
Stages 04 to 06
Before anything moves
A real extract, a bounded slice of the book, and the written outcome. This is the half that is scoped and priced before it starts, so you decide to enter it with the number in front of you.
Reconcile the numbers before anything moves
Balances, schedules, accruals, charges, asset classification and the accounting entries behind them, reconciled between your system and ours on a real extract. Migrations fail here more often than they fail on features, and it is the stage that is cheapest to do early.
You leave this stage holdingReconciliation findings on your own extract, line by line.
Trial it with acceptance and rollback criteria written first
A bounded slice of the book, with the conditions for success and the conditions for stopping agreed before the trial starts. Rollback that was designed in is a different thing from rollback improvised when a trial goes badly.
You leave this stage holdingAcceptance and rollback criteria, agreed in writing before the trial runs.
Get a written plan, or a written recommendation to stay
Sequence, dependencies, what your team carries, what we carry, and the risks that remain. If the evidence does not support moving, the recommendation says so, and you keep the assessment either way.
You leave this stage holdingA migration plan with sequence, dependencies and risks, or a recommendation to stay.
Three ways this can go
Stay and invest in what you have
You keep the platform, the team's familiarity with it and the regulator relationships built around it. The strain you came in with is still there, and the cost of operating the book keeps tracking the size of the book.
Assess first, then decide
You spend a bounded amount of your team's time and come out with evidence: what you run, what actually reconciles, and what a move would cost. The decision is yours and it is defensible either way. This is the one we recommend, and it is the one that can rule us out.
Move on a vendor's timeline
Fastest to a signature, and the option most likely to discover a reconciliation problem after the contract rather than before it. If a supplier will commit to a migration timeline before seeing your data, that timeline is not about your data.
The trade-off, plainly. The middle path gives you a decision you can defend, and it costs your team real hours: someone with access to the deployment, and someone from finance who can adjudicate a reconciliation mismatch. If nobody can be spared for that, the assessment will not produce anything worth having, and it is better not to start it.
Why it is built this way
An assessment that cannot conclude against the people running it is not an assessment. It is a sales process with stages.
We run the book after approval and are not building origination this cycle, so there is ground here we will tell you we do not cover. Comparisons against named platforms, with sources, are on the comparisons hub.
What you leave with
- A written record of what your deployment actually is.
- Your requirements mapped against real overlap, and against the gaps.
- Reconciliation findings on your own extract.
- A migration plan with acceptance and rollback criteria, or a recommendation to stay.
- All of it readable by your team, and usable with a vendor who is not us.
In lending, the autonomy you can audit is the only autonomy that scales.
Start with the hour, not the document
Stage one is a conversation, online or in person, with the people who operate the book. An hour on where it strains now, what a policy change costs you today, and what you would have to produce if a regulator asked how an automated decision was reached. Some of those calls end with a view on what to fix in the system you already run.
Tell us what you are running and what is straining. If Apache Fineract is the system in question, say which release and fork if you know them, and we will come to the call having read it properly.
Frequently asked questions
What is a loan book migration assessment?
A structured evaluation of whether a lender should move its loan book off the system it runs today, carried out before any migration work is committed to. It establishes what the incumbent deployment actually is, tests the capabilities the lender is counting on against data shaped like its own, reconciles balances and accounting entries between the two systems, and ends in a written recommendation. A recommendation to stay on the current system is a valid outcome and a common one.
How long does the six-stage assessment take?
Stage one is an hour. Beyond that it depends on how far you take it. The stages that establish your deployment and map your requirements move as fast as your team can supply the material, usually days rather than weeks. The reconciliation and trial stages are scoped when you reach them, because their length is set by the size and shape of the extract, and quoting a calendar for work nobody has scoped yet is how migration timelines start going wrong.
What does the assessment cost?
Nothing, up to the point where it would need engineering time from us at a scale we cannot absorb. The first stages are a conversation and a document review. If the assessment reaches a data reconciliation or a bounded trial, that is scoped and priced like any other engagement, and you will know before it gets there rather than after.
Will this just conclude that we should buy Lokta?
It can conclude the opposite, and the last stage is written so that it can. Running a stable book on a system your team knows, with no agentic operations on the near-term roadmap, is frequently the lower-risk position, and a migration you did not need is an expensive way to learn that. We would rather be ruled out early than be a project that quietly stalls.
How much of our team does this take?
The first conversation takes an hour and needs one person who knows how the book is operated. Establishing what you run needs someone with access to the deployment. The reconciliation stage is the heaviest: it needs a real data extract and someone from finance who can adjudicate a mismatch. We do not ask for production access to run it.
We are on Apache Fineract. Is this different for us?
The stages are the same, and the first one matters more. Fineract deployments diverge widely: release, fork, distribution and local patches all differ, and a general statement about the project tells you very little about your installation. We have worked on that stack for a long time, which helps us read a fork quickly, and it is also why we will not tell you what your deployment does before we have looked at it.
What happens to the assessment if we do not proceed?
You keep it. The record of what you run, the reconciliation findings and the requirement mapping are useful to whoever you evaluate next, including a vendor who is not us. It is written to be readable by your own team rather than as a document that only makes sense with us in the room.
Can we start with a conversation instead?
That is stage one, and it is where most lenders start. An hour, online or in person, on how the book is operated now and where it strains. Some of those conversations end with a view on what to fix in the platform you already have, and no assessment at all.
Related
Apache, Apache Fineract and Fineract are trademarks of the Apache Software Foundation. Lokta is not affiliated with, sponsored by or endorsed by the Apache Software Foundation, the Mifos Initiative, or any other company named here.