Should you move your loan book?
Evaluate your current deployment, test the fit and reconcile the numbers. Leave with a written migration recommendation, including the option to stay.
Worth running if
You have a live book, a concrete operating problem and a decision to justify.
Not worth running if
Your platform is holding and you are exploring. Start with a conversation before committing your team to an assessment.
Assessment outline
A decision your team can inspect
01 · Establish the fit
Your deployment, requirements and capability gaps, in writing.
02 · Test the numbers
Reconciliation findings on your extract, with acceptance and rollback criteria for a trial.
03 · Make the decision
A migration plan or a recommendation to stay. The record is usable with another vendor.
Start with one hour. Conversation and document review have no charge. Data reconciliation and trials are scoped and priced before they start.
Bring an operator, someone who knows the deployment and a finance reviewer. Production access is not required. The assessment covers the book after approval.
The assessment at a glance
The scope, stages and team involved.
- 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.
If your current system already does what you need, keep it until a parallel run says otherwise. A sample of loans runs on both systems, and the switch happens only when the two reconcile; stage 04 below is that test. The steps on either side of it are on How we work.
What lenders said
Lenders on how fast they could start.
Asked when he wanted servicing automated
“At this point, I can start within a month.”
On why Lokta starts after sanction
“The post-sanction area is the one which still today remains a grey area.”
After the portfolio dashboards
“This kind of concise and clear dashboard I never saw.”
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.”
At the end of the demo
“You have covered all the pain points of the smaller NBFC.”
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 cover 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 cover 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.
Hundreds of collection strategies in the time a risk team ships one.
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.