A chama, kept the way an accountant would
ChamaTrust runs a chama's money so that nobody has to trust one person's notebook. Here is what it does through a chama's year, and why its numbers can be believed.
- Members pay and borrowby M-Pesa, from the app or a basic phone
- Officials run itand money moves out only when two of them agree
- The database keeps the booksand refuses any entry that does not balance
- Safaricom has the last wordnothing is credited until it confirms
Part 1
Who uses it
Three kinds of people, each landing where their work is when they sign in.
Members
See their savings, what is due, their loan and when their merry-go-round turn comes.
Pay by M-Pesa, ask for a loan, download a statement, or do most of it by dialling a code.
Officials
The chair, treasurer and secretary. They approve loans and payouts, credit payments that name no member's account, and read the books and reports.
The treasurer lands on Reconcile, the chair and secretary on Approvals.
Platform admin
Sees every chama and every account, to help when something is stuck. Holds no chama's money and approves nothing inside one.
Part 2
Payments and fines
Each chama sets an amount, weekly or monthly, a due day and a few days' grace. Every shilling a member pays is then applied in one fixed order.
- 1Fines owedcleared first
- 2Contributions dueoldest first, the merry-go-round share before savings
- 3Savingsanything left over
An example from the demo
Rose owes a KES 200 fine and pays KES 3,200. KES 200 clears the fine, KES 1,000 goes to the merry-go-round pot and KES 2,000 to her savings. Her statement shows exactly that split.
Fines are judged by the deadline
A contribution still unpaid when the grace days run out is fined: KES 200 in Umoja Women Group, after three days. The check looks at what was paid by the deadline, not at when it runs, so running it a week late, or twice, fines exactly the people an on-time check would have.
Part 3
Loans, with two keys
Table banking: members borrow from the pool everyone saves into, and the interest comes back to all of them at the share-out.
- 1
Ask
Up to a multiple of your savings, three times in the demo chamas, over a term the chama allows.
- 2
Two officials approve
Neither may be the borrower, and the database itself enforces that, not a line of code someone could forget.
- 3
Sent by M-Pesa
The treasurer sends it, and the loan starts only when Safaricom confirms the money arrived.
- 4
Interest on each due date
Flat or on the reducing balance, as the chama decides: 10% a month flat in Umoja, 1% a month reducing in Tumaini.
- 5
Repay
From the app, the paybill or USSD. Pay early and no further interest is charged.
- 1Penalties
- 2Interest
- 3The loan itself
- 4Savingsif you paid more than you owe
When a repayment is late
An installment still unpaid seven days after its due date is charged one penalty, 5% of what is overdue in Umoja. It is judged on the total you have paid, so paying before the due date never counts as late.
An overdue loan says so, with the amount and the date it fell behind, to the member, to the officials and on the USSD menu.
Part 4
Merry-go-round and share-out
The merry-go-round
Members agree an order. Each period part of every contribution goes into the pot, and the pot goes to the next member in line.
The pot is sent by M-Pesa, and a turn is paid once, ever: the database refuses a second payout while the first is pending or done.
The year-end share-out
The year's interest and fines, less M-Pesa charges and a reserve the chama keeps, go back to members by their savings over time, counted in shilling-days.
KES 10,000 saved in January earns more than the same saved in December. Every cent goes to a member; none is lost to rounding.
The two-person rule
Anything that moves money out or corrects the books needs one official to ask and a different one to approve: cash recorded by hand, merry-go-round payouts, reversals and the share-out. The action runs inside the approval, so it cannot happen any other way.
Part 5
The books
Every event is one double-entry record: what came in equals where it went. The rules live in PostgreSQL itself, so even a bug in the app is refused before it can be recorded.
- Every entry balancesChecked when it is saved; an entry that does not balance is refused outright.
- Nothing is edited or deletedNot by the app, and not by anyone with a database login, unless they remove the rule first.
- Recorded onceHowever many times an event is reported, it is written once.
- Never below zeroSavings, the M-Pesa float and the pot can't go negative, even with two payouts racing.
- One chama can't touch another'sEvery line must name an account of the same chama.
- Balances are worked out, never storedEvery report, statement and dashboard sums the same records, so none can disagree.
Mistakes are reversed
A cash payment recorded against the wrong member is put right by a reversal that exactly mirrors it, with a reason, once a second official approves. Money that really moved through M-Pesa cannot be reversed, because it really moved.
What each event does to the books
| Event | Debit | Credit |
|---|---|---|
| A contribution by M-Pesa | M-Pesa float | The member's savings (and the pot) |
| Money for an account nobody holds | M-Pesa float | Suspense |
| The treasurer places it | Suspense | The member's savings |
| A late fine | Fines the member owes | Fines income |
| A loan paid out | The loan, and the M-Pesa charge | M-Pesa float |
| A due date's interest | The loan | Interest income |
| A repayment | M-Pesa float | Penalties, then interest, then the loan |
| A merry-go-round turn | The pot, and the M-Pesa charge | M-Pesa float |
| The share-out | Interest and fines income | Members' savings, by savings over time |
Part 6
M-Pesa: a message is a claim, not proof
Money comes in two ways and goes out one way. In every case ChamaTrust waits for Safaricom's own confirmation before the books move.
A prompt to pay
The member asks to pay and their phone shows the M-Pesa prompt. When Safaricom says it succeeded, ChamaTrust asks Safaricom again before crediting a shilling.
The paybill
Members pay the chama's paybill with their member number as the account, the way chamas already do. A number that matches no chama is refused before any money moves.
Payouts
Loans and merry-go-round turns go straight to the member's M-Pesa, and Safaricom's charge for each is recorded with it.
What can go wrong, and what happens
| If | Then |
|---|---|
| Safaricom sends the same confirmation twice | It is credited once. Every payment carries a key the database will not accept twice. |
| Twenty copies arrive at the same moment | Still once. They queue on a lock and nineteen find the work already done. |
| A failure notice arrives after the success | The success stands. ChamaTrust asks Safaricom for the final word rather than believing the latest message. |
| Someone forges a success message | Nothing is credited: Safaricom, asked directly, says the payment did not happen. |
| The confirmation never arrives | The nightly check asks Safaricom about every payment still pending and settles it. |
| Nobody answers the prompt on their phone | It expires, as a real prompt does, and a late answer is refused. |
| Money comes in for an account nobody holds | It waits in Suspense until the treasurer places it with a member. It is never guessed. |
| A payout is reported sent but never was | The books do not move until Safaricom itself confirms the payment. |
In this demo a simulator plays Safaricom. It sends the same messages, signed, to the same addresses Safaricom would, so every one of these paths runs for real. No real money moves.
Part 7
Any phone: USSD and SMS
Many members have a phone without internet. Everything a member does day to day also works by dialling a code.
ChamaTrust: Umoja Women Group 1. My balance 2. Pay contribution 3. Merry-go-round 4. My loan 5. Mini statement 6. Lugha/Language
- English or KiswahiliChosen on the first dial and changeable any time.
- A four-digit PINAsked every session. Three wrong tries lock it for thirty minutes; an official can reset it.
- Pay from the menuThe M-Pesa prompt starts only after the menu has replied, so a slow network never drops the session.
- An SMS for everythingA receipt for every payment, a reminder two days before a due date, and a short monthly statement.
Part 8
Every night, and the proof
What runs every night
A scheduled run charges interest and penalties that fell due, fines late contributions, sends reminders, asks Safaricom about anything still pending, and checks the M-Pesa float in the books against the payments record. On the first of the month it sends each member a statement. Every step is recorded once per day, so a run repeated, or days late, gives exactly the same result.
The claim the tests prove
After 10,000 random operations, with M-Pesa confirmations delivered twice, twenty at once, out of order, forged or never, the books balance to the cent and no receipt is credited twice.
Another test removes each of the database's 17 rules in turn and shows the tests then fail, so none is there for show. Further suites drive the API, the USSD menu, the nightly jobs and the web app in a real browser.
Part 9
Where the numbers come from
The demo chamas are made up, but their figures follow published examples rather than guesses.
- Loans of up to three times savings, at about 1% a month over longer terms: Transform Trade on table banking.
- Short table-banking loans at 10% a month over three months: Fair Planet.
- A women's group of twenty paying KES 3,000 a month: Nation, on a Kaptembwa chama.
- M-Pesa payout charges from a third-party copy of Safaricom's tariff (Safaricom's own PDF could not be reached), so treat them as approximate.
- The late fines (KES 200 and KES 500) are this project's assumption: no source found states a typical figure.
See it with a year of history behind it: sign in as a member or an official, or dial the menu on the demo phone.