For schoolsFor parentsSecurityDownload
Talk to us

Built like it holds money, because it does

Two things here are worth protecting properly: other people’s money, and children’s fingerprints. Here is specifically how each is handled.

The ledger is the product

The till, the app, and the console are all just interfaces onto it.

Two sides, always
Every movement of money is recorded as at least two entries that sum to zero. A bug can never create or destroy money, only move it from one place to another.
Balances are not stored
A balance is added up from the entries every time it is asked for. There is no balance field for a bug or a person to overwrite, so the number cannot quietly drift away from the history.
One way in
A single function is the only code in the whole system permitted to write a ledger entry. Every top-up, purchase, and withdrawal goes through it, so the rules cannot be bypassed by a new feature.

Checked by proof, not by hope

Four rules hold at all times: entries sum to zero, a wallet never goes negative, money is conserved, and replaying the same instruction twice changes nothing. Each one is verified automatically against thousands of generated cases on every change, rather than against a handful of examples somebody thought to write down. Separately, a daily integrity job compares M-Pesa’s record against the ledger and raises the alarm on any discrepancy, so a problem is found by us rather than reported by a parent.

Biometrics of minors, treated accordingly

A child’s fingerprint deserves more care than a login password. Six rules govern how it is captured, stored, matched, and removed.

No images, ever
A fingerprint is converted to a mathematical template at the reader. The image is discarded and never leaves the device, so there is no picture of a child’s finger to lose.
Encrypted and kept apart
Templates are encrypted and stored in their own database, separate from the money system, holding no names, balances, or payment details alongside them.
A near-miss is a refusal
If two students score too closely against a scan, the till refuses rather than picking the better one. Charging the wrong child is treated as worse than an inconvenient decline.
Consent on the record
A student is only enrolled after a guardian consents, and the record stores which version of the consent terms was agreed to, not just that somebody once ticked a box.
A bounded search
A scan is only ever matched against the students at that school, and the system refuses an open-ended search once the pool grows past a safe size.
Removable
A guardian can withdraw consent and have the template deleted. The wallet keeps working, and the student is looked up by account number instead.

Things we deliberately do not do

Most of the safety in a payment system comes from what it refuses to be capable of.

  • Store a picture of anybody’s fingerprint.

  • Keep a balance as a number that a person or a bug could edit.

  • Let the till decide whether a student can afford something. The ledger decides, and it refuses to go negative.

  • Reverse a payout we are not certain failed, so a parent is never debited twice for one withdrawal.

  • Put fingerprint data in the same database as money or payment details.

Ask us the hard questions

Bring your bursar, your IT person, or your lawyer. We would much rather answer this before you sign up than after.

Talk to usEmail us

We usually reply within two working days.