What We Learned Building Fineract - And Why We Started Over

There is a discomfort that comes from watching something you built reach its limits. Not because it was built badly - but because the world it was built for no longer exists.

I co-created Apache Fineract and built Finflux. Together, those systems have powered lending operations for institutions serving over 25 million borrowers across 15 countries. For a stretch of time, they were exactly right: reliable, open, and built for the lending operations of their era.

But that era ended. And the hardest professional decision I've made was admitting that the systems we built could not be incrementally upgraded to meet what lending demands now.

This is what we learned - and why we started over.

What We Built

Fineract began as an answer to a real problem: financial institutions in emerging markets needed loan management systems that were open, configurable, and affordable. We built one. It handled loan origination, repayment tracking, accounting, and basic reporting. It ran on sensible assumptions for its time: batch processing overnight, relational data models, and synchronous integrations between modules.

Finflux extended that foundation into a commercial product - more configurable, more scalable, purpose-built for Indian NBFCs and fintechs. It worked.

We did not build bad software. We built software for a lending world that operated at human speed.

What We Learned

Three architectural lessons became impossible to ignore.

1. Batch processing breaks when automation enters.

When a human loan officer processes 40 applications a day, a nightly batch run to update loan states, calculate interest, and generate reports is perfectly adequate. When AI-assisted workflows push that to 400 applications a day - or when real-time regulatory reporting demands intra-day state accuracy - batch processing becomes the bottleneck, not the backend.

We saw this firsthand: institutions that adopted automation on top of Fineract-era architecture found themselves waiting for yesterday's data to process today's decisions. The architecture that was invisible at human speed became the constraint at machine speed.

2. Monolithic data models create reconciliation traps.

Fineract, like most LMS platforms of its generation, stored origination data, servicing data, and collections data in structures optimized for their own module. This made each module efficient in isolation - and created a reconciliation nightmare across them.

Collections teams would reach out to borrowers without seeing origination context. Repayment data would lag behind disbursement records. Co-lending reconciliation across partner institutions required manual matching in spreadsheets. We used to call it "VLOOKUP Hell" - and every lender running fragmented systems knows exactly what that means.

The problem was not that modules were poorly built. The problem was that each module maintained its own version of the truth, and no integration layer could fully resolve the differences without a shared foundation.

3. Integration patterns become technical debt.

Early in Fineract's life, we connected modules through APIs and scheduled data syncs. It worked. Over time, every new requirement - co-lending partner onboarding, real-time compliance reporting, consent management across touchpoints — added another integration. Each integration was individually reasonable. Collectively, they formed a web that was fragile, expensive to maintain, and impossible to audit cleanly.

The insight was not that integrations are bad. The insight was that lending operations are too interconnected for a bolt-on integration approach to remain viable at scale.

Why We Started Over

We considered upgrading. Every builder's instinct is to extend what exists. But the fundamental assumptions were embedded in the architecture, not in features.

You cannot add real-time state management to a system designed around nightly batch runs without rebuilding the state management layer. You cannot unify data across modules by adding more APIs between separately modeled databases. You cannot make a monolithic system AI-ready by attaching an AI service to its endpoints - because the AI layer needs to operate on consistent, event-driven state, not on batch-refreshed snapshots.

The metaphor we kept returning to was narrow-gauge rails. You can put a faster locomotive on narrow-gauge track. You can improve the signals and the stations. But you cannot run a bullet train on it. The track width is the constraint, and the track width is the architecture.

Starting over was not admitting failure. It was the most responsible thing we could do with what we now understood.

What Connected Lending Means

Starting from scratch is a luxury most builders never get. We tried not to waste it.

Lokta is what we built with those lessons. Not a better LMS - a different foundation.

A deterministic core for money movement - because the alternative is what we lived through: state transitions triggered by batch schedules instead of business events. Loan state changes — from current to overdue, from disbursement to repayment — must be deterministic and auditable. They happen because a defined rule triggered, not because a model predicted they should. In regulated lending, this is non-negotiable.

A shared data ontology - because we spent years watching teams reconcile data that should never have been separated. Instead of separate models per module, Lokta uses a connected lending ontology that spans origination, servicing, collections, and co-lending. Every workflow, every report draws from the same truth. No reconciliation layer needed because there is nothing to reconcile.

AI that assists, not autopilots - because we saw what happens when intelligence operates on stale, inconsistent state. Workflow AI handles document verification and policy checks grounded in institutional data. Agentic AI orchestrates multi-step processes with full audit trails and human oversight at decision boundaries. Governed, explainable, auditable.

This is what we mean by Connected Lending. Not a platform that connects to everything. A platform where everything is already connected - because it was designed that way from the first line of code.

If You're Evaluating Lending Infrastructure

If you are a CTO or Head of Lending at an NBFC or fintech, you are probably living with some version of the problems we described. Your systems work - until they don't. Your integrations hold - until a new regulatory requirement exposes how fragile the connections are. Your data is accurate - in each module, but not across them.

We have been where you are. We built the systems that taught us these lessons. Lokta is what we would have built first if we had known then what we know now.

If you're wrestling with these same constraints, we're building Lokta with design partners who've lived them too. We'd welcome the conversation.

Ashok Auty is the co-founder of Lokta and co-creator of Apache Fineract. He has spent two decades building lending infrastructure for emerging markets.