What a savings group actually is

A cooperative savings group - ajo in Hausa, esusu in Yoruba, kolo in parts of Nigeria - is a set of people who agree to contribute a fixed amount on a fixed schedule, and who take the accumulated fund in rotation. Every member gets the whole pot, in a fixed order, and the cycle repeats.

That is the whole mechanism, and it is worth writing down plainly because most of the difficulty comes from the gap between that description and what a bank thinks a savings account is.

The real world around it is messier:

• The rules vary from group to group. Some groups collect weekly, some monthly. Some start with the oldest member, some with whoever needs it most.
• The rules change by agreement. A member falls behind; the group decides what to do. The model has to accommodate a decision, not prevent it.
• Membership changes. People join, people leave, people die. The rotation has to survive that.
• The book is a notebook. Contributions are written down by hand, and the notebook is the record of the group's agreement.

The mistake: modelling it as an account balance

The obvious model is a balance and a list of transactions. It fails immediately, because a savings group is not a bank account with several owners - it is a fixed sequence of payouts from a shared pot.

The structure that fits is closer to a schedule:

• The cycle - a rotation of members, each with a defined position, each position with a defined date.
• The pot - the sum of contributions received, less the payouts already made.
• The contributions - what each member has paid, against what the schedule says they should have paid.
• The decision log - the group's agreements: a schedule change, a grace period, a substitution.

The pot is then a derived value - contributions received minus payouts made - rather than a number somebody types. That distinction is the single most valuable thing in the model: a derived balance cannot drift, because there is nothing to reconcile.

Where the money actually is

The trap in fintech is the idea that the platform holds the money. It usually does not. The group collects the money - cash, transfers, a pocket - and the platform's job is to record it, and often to help the group see it.

So the model has to be honest about custody: the records show what the group says it collected, and the group is the authority. Where there is a real payment provider involved, the provider's confirmed events are the authority for the money that moved through it - the same split that a checkout has between the browser and the verified webhook.

The moment the platform starts treating its own database as the source of truth for money that is actually somewhere else, every reconciliation problem in the industry appears at once.

The fraud controls, which are the actual product

This is the part that matters most, and it is not a security feature - it is the reason a group would use software at all.

A savings group runs on trust, and trust is maintained by everyone seeing the same numbers. That is the entire value of the digital version: not efficiency, but the fact that a member can see that the pot is what it should be, without asking a person and trusting their memory.

So the controls are about making the record checkable by the people in the group:

• The balance is derived, never entered. Nobody types "the pot is 400,000". The number is what the contributions and payouts say it is.
• Every contribution is attributable. Who paid, when, how much, and which collection round it belongs to.
• Overdue is visible, but the decision is not the software's. The record can say a member is two rounds behind. What happens next - a reminder, a grace period, a substitution - is the group's decision, recorded in the decision log with a date and a note.
• The schedule is data, and a change to it is a new version. A changed rotation is not an edit; it is a new schedule with an effective date, and the history of it is kept.

That last point is what keeps the model from legislating the group. The temptation with cooperative money is to encode the rules you saw in the first group you studied - a fixed weekly amount, a fixed order, a penalty schedule - and then to be surprised when the second group is different. The rules live in a table that the group edits, and the software's job is to apply the group's rules and show the consequences, not to supply them.

The interface has to be readable by the whole group

Not just the treasurer. A member who cannot read the ledger on their phone will not check anything, and the whole trust model collapses back into asking a person.

That means:

• Plain language for the money. Not "balance" - what is in the pot now, and when it comes out.
• The schedule first. Who is next, and when. That is the question people actually open the app to answer.
• The record is visible to everyone in the group, and the decisions are attributed. An unattributed change is indistinguishable from a theft.
• It works on an old phone, on a poor connection, and in daylight. Most of the reading happens in daylight, outdoors, on a cheap device.

The rules I would keep

• Derive the balance. Never store it. Everything else follows.
• Model the rules as data, and the decisions as records. Software that supplies the rules is legislating; software that applies them is helping.
• The group's own view of the money is the authority - with verified payment events where they exist.
• Design for the member, not the treasurer. If only the treasurer can read it, the software has replaced the notebook for one person and changed nothing for anyone else.

The model in KOLO is built this way: a contribution model, a derived ledger, and fraud controls that work by making the record legible to everyone in the group rather than by policing anyone.