Choosing Core Banking Software for a Kenyan SACCO: A Buyer's Checklist

Kenya has more than 175 licensed deposit-taking SACCOs, and most of them run software that was designed for something else. Some run a commercial banking core bent into SACCO shape. Some run a microfinance package with FOSA bolted on. A surprising number still reconcile BOSA in spreadsheets at year end.

The cost shows up in the same places every time: a trial balance that has to be explained rather than read, guarantor exposure nobody can total on demand, and a scramble every quarter to produce SASRA returns that the system cannot produce on its own.

If your society is choosing core banking software this year, here is what to test — before the demo, not after the contract.

1. Are FOSA and BOSA one ledger, or two systems?

This is the question that decides most of the others.

A SACCO's front office (FOSA) and back office (BOSA) are not two businesses. They are two segments of one balance sheet, and SASRA expects each to be reportable on its own and consolidated. Systems that model them as two ledgers force a reconciliation every reporting cycle, and that reconciliation is where errors accumulate and audits stall.

Ask the vendor to show you a trial balance filtered to FOSA, then to BOSA, then consolidated. Watch what happens to money that moves between the two — a member's BOSA deposit funding a FOSA withdrawal, say. In a correct design, each segment balances on its own, the transfer runs through an inter-segment clearing pair, and the consolidated view nets it to zero. If the answer involves an overnight job or a manual journal, you have found a system that will cost you every month you own it.

2. Can the system prove segregation of duties, or does it just promise it?

"Maker-checker" appears in every proposal. The question is whether it is enforced in code or by training.

Test it. Ask an operator to initiate a loan disbursement and then approve it themselves. A system that enforces segregation refuses with an explicit error. A system that relies on convention lets it through and leaves you explaining the control gap to your auditor.

The same test applies to GL adjustments, dividend declarations, provisioning runs, KYC verification and statutory return submission. Each one should refuse the same person twice.

3. Is guarantor exposure arithmetic, or a note in a field?

Guarantees are where SACCO credit risk actually lives, and where most systems are weakest.

If a guarantee is recorded as a row in a table, then a guarantor's available balance does not reflect what they have pledged, and nothing stops them guaranteeing five more loans they cannot cover. The society only discovers the gap when it tries to recover.

The stronger design holds the guaranteed amount against the guarantor's BOSA deposits. Their available balance drops the moment they guarantee, caps on guarantee-to-deposit ratio and active guarantee count are enforced by arithmetic rather than policy, and the exposure figure is always current because it is the same number the ledger uses.

Ask to see a member's exposure across every loan they guarantee. If it takes a report request, it is not being enforced.

4. Does it produce SASRA returns, or data you then turn into returns?

There is a large difference between a system that exports figures and one that produces a return.

A return worth having arrives as a package — financial position by segment, income statements, capital adequacy, liquidity, portfolio quality, large exposures — with reconciliation checks that must pass before anyone can submit it, and with the prudential parameters it used printed alongside the figures. Provisioning rates and aging buckets should be configuration with a recorded source, never values compiled into the software, because they change by circular and you should not need a release to follow one.

Ask one more question, and treat the answer as a test of the vendor's honesty: which figures in this return are confirmed with SASRA, and which are your defaults? Every vendor has defaults. Only some will tell you which they are.

5. What happens when M-Pesa sends the same callback three times?

It will. Mobile money callbacks are retried, duplicated and occasionally delivered out of order, and a payment integration that assumes otherwise will double-post member deposits.

The correct answer is that the provider's transaction reference is claimed in a unique database index before any ledger posting, so a duplicate cannot post twice even under concurrent delivery. Ask specifically about that ordering. "We check if it already exists" is a race condition with good intentions.

While you are there, ask what happens to a paybill credit that matches no member account. It should park in a suspense account for staff to resolve, not vanish into a log file.

6. Can the audit trail be edited by the people who run the system?

Every system has an audit log. Very few have one that survives a determined administrator.

A trail worth relying on records who did what, from which address, under which request — and the actor's name as it was at the time, so it stays readable after that user is renamed or removed. It records failures too: refused sign-ins, lockouts, blocked callbacks. And it should be append-only in the database itself, with each entry chained to the one before it, so that removing or editing history is detectable rather than invisible.

Ask whether the application's own database user can delete an audit row. If it can, the trail documents honest activity only.

7. Will members actually use the mobile app?

A member app that only shows balances gets installed once and forgotten. The ones that get used let members do the things that otherwise mean queuing at a branch: check a statement, top up by M-Pesa or Airtel Money, request a withdrawal, see their dividends.

Two details matter more than they sound. Sign-in should be a phone number and PIN with a one-time code on a new device, then biometric unlock — an OIDC redirect flow is correct for staff and miserable for members. And a withdrawal requested in the app must land in the same approval queue as one requested at the counter. If mobile requests follow a different path, you have two control regimes and one of them will be weaker.

8. Who owns the software in five years?

This is a commercial question with a technical answer.

Ask whether you are licensing a system you can host, inspect and modify, or renting access to someone else's deployment. Ask what happens to your data if the vendor is acquired or folds. Ask whether source escrow is available — a reasonable vendor will have an answer ready, because SACCO boards have been asking the question since the first core banking failure.

Then ask something concrete: can your own developer run the whole system on a laptop, with sample data and no production credentials, before you sign? If the answer is no, evaluation is something you do after committing, which is the wrong order.

What we built, and what it does not do

We built the SACCO Core Banking Platform against this checklist: FOSA and BOSA as segments of one ledger, maker-checker enforced in code on every money-moving approval, guarantees as ledger holds, statutory returns with eight reconciliation checks, idempotent M-Pesa, Airtel Money and bank integrations, a hash-chained audit trail the database refuses to edit, and a Flutter member app with phone-and-PIN sign-in. It ships as source code with a staff portal, a tenant-branded public website, seed data and mock payment gateways, so the entire system runs on a laptop with no production credentials at all.

It is also honest about what is not finished. The live payment providers are written and exercised against mock gateways but have not been certified against real provider accounts. There is no credit reference bureau integration yet. Nine SASRA prudential figures ship as configurable defaults and are printed as open items on every return until your society confirms them. It has not yet run a live SACCO.

We would rather you knew that before the demo than after the contract — which is, more or less, the point of the whole checklist.