Microfinance Core Banking Software: What It Really Costs to Handle Group Lending, Field Officer Cash and Central Bank Returns

Why microfinance breaks every retail lending system you install

It is five in the evening at a district branch. The manager has three versions of the truth open. The core system says 1,412 active loans. A stack of paper collection sheets has come back in field officers' bags from twenty weekly group meetings. A mobile money statement shows 312 inbound transfers that arrived during the day with reference strings members typed themselves. Her job before she goes home is to make the three agree. They will not. One meeting took a partial payment from a member whose sister paid on her behalf, so the receipt has one name and the loan has another. She will fix this by calling officers on their personal phones and by memory of who sits in which group.

The stack around this is usually a legacy core built for a bank, plus the mobile money operator's web portal and a workbook where somebody computes portfolio at risk for the board. Mambu, Apache Fineract and Musoni are real systems and each is competent at what it was designed for. What none of them holds by default is the object your institution actually runs on: a group that guarantees a set of member loans, a field officer who accepted cash and now owes it to the branch, a mobile money reference that must be matched to a member who spelled her own name differently, and a regulatory arrears bucket with its own definition of a missed instalment. Every tool owns a slice. The branch manager owns the joins, at five in the evening, on paper.

Problem 1: the borrower is a group and a person at the same time

In solidarity group lending the loan sits with the member, the guarantee sits with the group, and the repayment discipline sits with the meeting. A member misses. The group covers her from the meeting collection or from the group fund. Somebody has to decide whether that covered payment was a loan from the group to the member, a drawdown against her compulsory savings, or a straight arrears event that still counts against portfolio at risk.

Fineract has a group and centre model and Mambu supports group clients, so this is not a case of the vendor ignoring the concept. The gap is that the guarantee is modelled as a relationship rather than as a balance that moves. How a group covers, what it costs the member and whether her savings lien is called are your credit policy, not a vendor's. A custom build makes the group fund a real ledger account, records the cover as a posting with a counter-entry against the member, keeps the arrears clock running on the original instalment because the regulator does not care who paid, and recalculates group and member tier eligibility as a rule set your credit committee can change without a vendor ticket.

Problem 2: field officer cash is a custody problem, not a payment

When an officer accepts 40,000 shillings at a meeting, no money has moved anywhere yet. She is holding it, sometimes overnight if the meeting is far and the branch closed. That cash is an asset of the institution sitting in a bag on a motorbike, and the single largest operational loss most institutions carry is the slow leak in that window.

Loan servicing platforms treat a repayment as a payment: it either happened or it did not. They have no concept of an officer float, a cash-in-transit balance, a banking slip that closes the float, or a shortfall recovered from an officer's salary under a documented process. A custom build gives every officer a cash account that opens at zero each morning, credits every receipt she issues, and only clears when a branch cashier accepts and counts. Receipt numbers are issued to her device in blocks so a voided or missing number is visible immediately, and the float carries a ceiling that forces banking before the next route. Reconciliation stops being a five o'clock argument and becomes a screen showing which officers are open and by how much.

Problem 3: offline is the normal state, not the edge case

Meetings happen under trees, in church halls and in market yards, on entry level Android phones whose batteries have to last a full route. Any design that assumes a request and response will complete is a design that will not survive its first rainy season.

Build for offline first and treat sync as an accounting event, not a data copy. The device holds the group's roster, schedules and balances before the officer leaves, records receipts locally with a device-issued identifier, prints or sends a receipt the member can hold, then replays the queue when signal returns. Conflicts are resolved by rule, not by last write wins: a receipt already posted from another device is rejected as a duplicate on its identifier, a schedule that changed at head office overrides the cached copy, and anything that cannot be settled automatically lands in a supervisor queue with both versions visible.

Problem 4: portfolio at risk belongs to the regulator, not to the vendor

Every reporting pack you produce is a different definition of the same portfolio. The central bank has a prudential classification with its own arrears bands and provisioning rates, and it wants the return on its own template by its own deadline. Your social investor wants portfolio at risk over 30 days with the internationally recognised treatment that counts the full outstanding balance of a loan with any instalment in arrears, not the arrears amount alone. Rescheduled loans must be flagged and, in most regimes, held in a worse bucket for a seasoning period.

Packaged platforms give you a portfolio at risk figure computed their way. That is fine until an examiner disagrees with the arrears day count on rescheduled accounts, and then you are exporting to Excel and rebuilding the number under time pressure. The correct build stores the raw facts, meaning every instalment due date, every posting and every reschedule event, then computes each classification as a separate named policy on top. When the central bank revises a circular you change one policy, rerun history, and can show both the old and new numbers side by side.

Problem 5: savings and shares are not a loan module bolted on

Compulsory savings pledged against a loan, voluntary savings a member can withdraw, share capital in a cooperative that earns a dividend rather than interest, a lien released only when the loan closes: these are deposit products with their own rules, and in a deposit-taking institution they carry licence obligations that lending alone does not.

Lending-first platforms bolt savings on as a wallet. The failure shows up at loan disbursement, when the system must place a lien on part of a member's balance, keep it visible to her as her money but unavailable, and release it automatically on final settlement. Build savings as a first-class ledger with product rules, and liens as explicit holds with a reason and a release condition.

Problem 6: mobile money rails shift under you

M-Pesa, MTN MoMo and Airtel Money are how repayments arrive now, and each is a different integration with different callback behaviour, and callbacks are duplicated, delayed and occasionally lost. Somebody pays the right amount to the right paybill with a reference belonging to a member who left.

The build treats every inbound notification as an event stored raw before anything is interpreted, applies idempotency on the operator transaction identifier so a repeated callback cannot post twice, and runs matching in tiers: exact reference, then phone number against member records, then fuzzy name and amount against expected instalments. Anything unmatched sits in a suspense account with an ageing report, because unmatched money is a liability and pretending otherwise is how institutions end up with a balance nobody can explain. Pull the operator's own end of day reconciliation file and compare it to your postings automatically. Never trust the callback alone.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the honest shape for a microfinance core. A focused first release covering group and individual loan origination, disbursement, the offline field collection app, officer cash accounts and branch reconciliation runs $90,000 to $180,000 and ships in 16 to 22 weeks. The full core, adding savings and share products, one or two mobile money rails, prudential and investor reporting, a member self-service app and a data migration off the legacy system, runs $250,000 to $600,000 phased across 9 to 18 months.

What pushes the number up in this sector: each additional mobile money operator is real weeks, not days, because the sandbox, the go-live approval and the settlement file format are all separate work. Multi-country operation multiplies the reporting layer. Migration is usually the single most underestimated line: moving live loan balances, arrears history and savings ledgers off a legacy core without a day of downtime takes weeks of parallel running, because your members will notice a wrong balance within one meeting cycle.

Build versus buy, and when Fineract or Mambu is the right answer

Buy or configure, and do not call us, if you are under roughly 8,000 active borrowers, lend individually, and take repayment by bank transfer or a single mobile money paybill. Apache Fineract is genuinely capable, the licence costs nothing, and a good implementation partner will get you live for far less than a build. Mambu is the right answer if you want a hosted core, your products are close to standard and you would rather pay a subscription than own a system. Musoni was designed with field operations in mind and fits an institution whose model matches the way it was built.

Build when two or more of these are true. Your credit policy on group cover, savings liens and cycle eligibility is genuinely yours and you change it more than once a year. Your officers work offline for a meaningful part of the week and your losses live in the cash window between a meeting and the branch. Your regulator's classification and provisioning rules do not match what your platform computes and you are already rebuilding returns in Excel. The tipping point is not features. It is that the coordination logic between the group, the officer, the cash and the regulator has become your actual operating model, and you cannot outsource your operating model to software designed around somebody else's.

How to choose a developer for microfinance core banking

Ask them to draw the ledger before they draw a screen. A team that has done this will put member, group, loan account, savings account, officer cash account and suspense on the board as accounts with double entry between them, and they will know why the officer cash account is the one that saves you money. A team that draws users, loans and payments has built a lending app and is about to learn field banking on your budget.

Ask specifically how they handle a duplicated mobile money callback and an unmatched payment. If the answer does not include idempotency on the operator transaction identifier and an ageing suspense report, they have not run a live paybill. Ask what happens when an officer's phone is stolen with unsynced receipts on it.

Ask which operator they have integrated live, in which country, by name, because a sandbox integration is not a live one. Ask how they will migrate your existing balances and how long they expect to run both systems in parallel. Anyone who says migration is a weekend has not done it.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the cloud accounts and the unrestricted right to hire another firm. At Digital Heroes the code is yours from the first commit, and in a regulated institution a core banking system whose source you cannot access is a concentration risk an examiner will eventually write up.