Articles

Institutional payments are a records problem before they are a money problem

Moving the money is the easy part. Agreeing on what was owed, by whom, and on what evidence, is where institutions actually get stuck.

Garang Mayom Malek · 8 September 2026 · 4 minute read

Most conversations about payments in Africa begin with the transfer. How fast does the money move, how much does it cost to move it, which rail does it use. Those are real questions. They are not the questions that hold an institution up.

An institution rarely fails to pay because the money cannot travel. It fails because nobody can agree what was owed. A cooperative cannot pay a farmer until it knows the farmer is the person named on the account. An association cannot bill a member until it agrees which category that member falls into this year. A revenue office cannot close a month until the receipts it issued match the money the bank says it received. In each case the blockage is a record, not a rail.

This is the difference between a consumer application and institutional infrastructure. A consumer wallet has one user, one balance and one decision to make. An institutional system has a register of who is entitled to what, a set of rules that decide the amount, a document trail that proves the decision, and a reconciliation at the end that has to survive somebody checking it a year later. The transfer sits in the middle of that, and it is the shortest part.

When I have seen these systems go wrong, the pattern repeats. The payment layer is modern and the record layer is a spreadsheet. Somebody exports, somebody edits, somebody imports, and the two versions drift. By the time anyone notices, the argument is no longer about software. It is about which copy is the real one, and there is no good answer.

So the first question I ask about any collection or disbursement system is not how it pays. It is where the authoritative record lives, and who is allowed to change it. If the answer is that it lives in one place, changes are written down as they happen, and every amount can be traced back to the rule and the document that produced it, then adding a payment rail is straightforward work. If the answer is that it lives in four places, the payment rail will make the disagreement faster rather than smaller.

There is a second reason to start with records. Institutions are audited. A cooperative answers to its members, an association to its board, a revenue office to the public. An audit is not a technical event, it is a request to show your working. A system that stores only the outcome can tell you that a payment of a certain amount went out on a certain day. A system that stores the working can tell you why, under which rule, on whose approval, against which document. The second one survives the question. The first one starts an argument.

None of this is exotic. Validating that a bank account belongs to the person it is supposed to belong to, before money is sent, is not clever engineering. It is a check that removes a whole category of later dispute. Issuing one certificate that several agencies can read, instead of three certificates that only their own issuers can read, is not clever either. It just means the trader stops carrying paper between offices.

CapitalPay describes its own work as digitising collections, compliance and settlement for governments, associations, cooperatives and licensed operators. That is the company's description of itself and should be read as such. What I would say more plainly is this: the useful work is almost never the payment. It is the boring layer underneath, where entitlement is decided and evidence is kept.

There is a design consequence. If the record is the product, then the system has to be legible to the people who run the institution, not only to the engineers who built it. A finance officer should be able to open a month and see what happened without asking anybody. A member should be able to see what they were charged and why. When a system can only be explained by its authors, it has failed a test that matters more than uptime.

I would rather build something that a new treasurer can understand in an afternoon than something that impresses at a conference. Institutions outlive the people who join them. The record has to outlive them too.

Filed under Payments infrastructure.