Building Sacco and Chama Portals in Kenya: Architecture, Money and Security

Most Kenyan Chamas run on a WhatsApp group and one exercise book. It works, until the treasurer travels, or the book disagrees with someone's memory, or forty people want to know their balance on the same evening.

The usual next step is a portal. And this is where it is worth being blunt: a system that holds other people's savings is not a website with a login on it. It is a ledger. If the ledger is wrong, the software has not inconvenienced anybody, it has lost their money.

A Chama and a Sacco Are Not the Same Build

They get lumped together and they should not be.

If you are a Sacco under supervision, your reporting obligations shape the system and they are not something a web developer should be guessing at. Bring whoever handles your compliance into the first conversation, not the last one.

Start With the Ledger

The temptation is to design screens first. Design the record first, because every screen is a view of it and every argument in the group will be settled by it.

Three rules that are worth more than any feature:

• Entries are added, never edited. A payment recorded in error is corrected by a reversing entry that says who corrected it and why. If a row can be quietly changed, the ledger proves nothing.
• Every entry says where it came from. An M-Pesa receipt number, or the name of the official who recorded a cash payment. A balance you cannot trace back to a source is a number, not a record.
• Money has types and they do not mix. Savings, loan repayment, interest, fines, welfare and registration fees are different buckets. Saccos that keep one running balance per member eventually cannot answer what a member is actually owed.

What a Member Actually Needs

Members do not log in to browse. They log in with one of five questions, and the portal should answer each in one screen.

1. How much have I saved?
2. Did my payment go through?
3. How much do I owe, and when is the next instalment?
4. Who am I guaranteeing, and for how much?
5. How do I pay right now?

Everything else, the news section, the photo gallery, the mission statement, belongs on the public site, not in the portal. And since most members will open this on a mid-range Android on mobile data, the balance should appear without a loading spinner and without a 2MB logo above it.

One feature earns its place more than any other: an automatic statement by SMS or WhatsApp after each contribution. It answers question two before it is asked, and it quietly reduces the treasurer's phone traffic more than the portal itself does.

M-Pesa Is the Hard Part

Receiving M-Pesa is easy. Knowing whose payment it was is the actual engineering.

Members will, reliably:

• Pay from a spouse's or a friend's phone.
• Mistype the account reference, or leave it blank.
• Send one round figure covering three months.
• Send a loan repayment into the savings reference.
• Pay twice because the first one "did not show".

A system that only handles correct payments silently hands the rest back to a human, which is the work you were removing. So design the unmatched queue first: every payment the system cannot confidently match lands in one place, with the sender's number and the reference they typed, and an official assigns it in two clicks. That queue is the most important screen in the whole build, and it is the one most proposals leave out.

Two more details worth insisting on. Match on the M-Pesa receipt number and treat it as unique, so the same payment cannot be recorded twice when a callback arrives twice. And never mark money received from a page the member returns to: wait for the confirmation from Safaricom, because the member closing the browser is not the same as the payment failing. Our guide to what each M-Pesa route costs and how the callback works goes through that in detail.

Loans, Guarantors and Arrears

Once a group lends, the portal needs three things it did not need before.

A schedule that is generated, not typed. Interest method, instalment amount and dates all come from the loan terms, so that nobody is maintaining a spreadsheet alongside the system.

Guarantor exposure that is visible to the guarantor. In most Kenyan groups, members guarantee each other, and they routinely do not know their total exposure until something goes wrong. Showing each member what they are guaranteeing, and for how much, prevents more disputes than any policy document.

An arrears view the committee can act on. Who is behind, by how much, for how long, and what was already sent to them. Not a report somebody exports monthly, a screen that is right now.

Moving Money Out

Collecting is low risk: a wrong payment in can be returned. Paying out is where groups lose money, and it is where a portal can do real harm if it is built eagerly.

The safe pattern for a first version is that the system prepares the payout and records the approvals, and a human executes it. Two officials approve, the request is logged with both names, and the payment is then made. You get the audit trail and the discipline without giving software the ability to move money on its own.

Automated disbursement is a reasonable second-phase feature once those controls have been running for a while and the group trusts the numbers. It should never be in version one, whatever the demo looked like.

Security and Who Can Do What

That last one is the most commonly missed. Committees change every year or two, and in most groups the outgoing treasurer still has a working login long afterwards. Decide at build time how access ends, not after an election.

Data Protection and Member Records

Member names, phone numbers, identity numbers, savings balances and loan records are personal data. Kenya's Data Protection Act 2019 applies, including the duty to notify the Data Commissioner without delay and within seventy two hours of becoming aware of a breach where personal data has been accessed by an unauthorised person and there is a real risk of harm.

Financial records about identifiable people are near the top of the sensitivity scale, and a Sacco database is a more attractive target than most people realise. The practical consequences are the ones in the section above, plus knowing where your backups live and who can read them. This is general information rather than legal advice, and regulated Saccos have supervisory obligations beyond data protection that their compliance adviser should lead on.

What It Costs

This is custom software, not a website. Bespoke builds with real integrations start at KES 150,000 and move with the complexity of the ledger, the loan rules and the reporting. M-Pesa integration is a KES 5,000 one-time fee, all inclusive, covering the collection side and the callback wiring.

The part groups underestimate is the ongoing cost. A system holding members' savings needs monitoring, backups that are tested, and someone to call. That is KES 20,000 a month at the premium tier for a custom application. A portal nobody maintains is a liability dressed as an asset.

Frequently Asked Questions

What should a Sacco or Chama member portal do?

Let a member see their own savings balance, their contribution history, any loan and its repayment schedule, and their guarantor commitments, and let them contribute by M-Pesa without ringing the treasurer. For the committee it should produce the contribution register, arrears list and loan book on demand. Everything else is secondary to those two jobs.

Why is M-Pesa reconciliation the hard part of a Sacco system?

Because members pay in ways the system has to interpret. They use a spouse's phone, type the wrong account reference, send a round figure that covers two months, or pay a loan amount into the savings account. A portal that only matches perfect payments pushes the rest back to a human, which is the work you were trying to remove. The design question is not how to receive M-Pesa, it is what happens to a payment the system cannot confidently match.

Should a Chama portal be able to send money out?

Only with more than one person approving, and ideally not automatically at all in the first version. Collecting money is low risk because a wrong payment in can be refunded. Paying money out is where fraud and mistakes become expensive. Start by having the system prepare the payout and record the approvals, with a human executing it, and automate disbursement later once the controls are proven.

What are the real security requirements for a member portal?

Every balance-changing action recorded in an append-only log with who did it and when, no shared committee logins, two factor authentication for anyone who can approve or edit money, separate roles so the person who records a payment is not the only person who can approve one, encrypted backups held somewhere other than the server, and a documented route for removing access the day an official leaves office.

Is a Sacco portal subject to Kenyan data protection law?

Yes. Member names, phone numbers, identity numbers, savings balances and loan records are personal data, and the Data Protection Act 2019 applies, including the duty to notify the Data Commissioner without delay and within seventy two hours of becoming aware of a breach where there is a real risk of harm. Financial records about identifiable people are among the most sensitive data a small organisation holds. Take advice on your own obligations, and note that regulated Saccos have supervisory requirements beyond data protection.

What does a Sacco or Chama portal cost to build in Kenya?

This is custom software rather than a website, so it starts at KES 150,000 and the number depends on how much the ledger has to do. M-Pesa integration is a KES 5,000 one time fee on top, all inclusive. The ongoing cost matters as much as the build: a system holding members' money needs maintenance and monitoring, which is KES 20,000 a month at the premium tier for a custom application.