The Lab's finance programme is organised around a specific diagnostic: African mobile-money markets have delivered real inclusion at the account layer while reproducing closed-loop patterns at the infrastructure layer. This entry develops the companion constructive argument — what a durable fix would actually require — in enough technical and institutional detail that a practitioner can evaluate the question on its own terms, without endorsing any specific vendor's product or protocol.
What interoperability actually means in this context
"Interoperability" is one of the most-abused words in financial-inclusion discourse. It is used to mean, at different times: bilateral bridges between two specific payment networks; real-time gross settlement between retail banks; standardised QR codes that multiple wallets can read; APIs that multiple developers can build against; cross-border remittance corridors; and dozens of other distinguishable capabilities. The Lab's use of the term is deliberately narrower.
By payment-rail interoperability we mean: the property that a user of any given payment network can receive payments from — and initiate payments to — a user of any other payment network, without either user's primary network operator having to negotiate a bilateral integration with every counterparty network, and without either user having to hold secondary accounts on multiple networks. The user's relationship with their primary network (their mobile-money wallet, their bank account, their neobank) is preserved; what changes is that the relationship becomes reachable from outside without loss of fidelity.
The definition has two specific entailments worth drawing out.
Entailment one: interoperability is an addressability question as much as a settlement question. The settlement mechanics — how value actually moves between networks — are well-studied and adequately solved by several existing approaches. The under-studied part is how the receiver of a payment is addressable to a sender on another network without exposing either the receiver's underlying account credentials or requiring bilateral identifier-exchange arrangements between the networks.
Entailment two: interoperability in this sense is layered above existing networks, not a replacement for them. A serious interoperability proposal preserves the user's primary network relationship intact. The interoperability layer provides cross-network addressability; the underlying networks continue to carry the value. This design posture is politically realistic (incumbent networks are not going to be replaced) and technically correct (the incumbents have real operational capability that a greenfield alternative would take years to reproduce).
The four design requirements
A durable interoperability layer for the Kenyan mobile-money context has to satisfy, in the Lab's reading, four distinct design requirements. Each is necessary; none is sufficient on its own.
Addressable endpoints without account-credential exposure
The user must be reachable by a portable identifier — analogous to an email address — that resolves to the user's primary account without exposing that account's underlying credentials to the sender. The identifier should be cheap to create, easy to share, and revocable by the user. The underlying technical primitives are mature; the design choices that matter are those around governance, naming, and the relationship between the identifier namespace and the existing mobile-money numbering scheme.
Scoped, revocable, fine-grained authorisation
A user must be able to authorise a specific counterparty to initiate a specific class of payment — "debit up to KES 460 per day, for 24 months, against this asset-finance contract reference, with automatic reminder on non-payment" — without granting that counterparty broader access to her account. The authorisation must be revocable by the user at any time, independent of the counterparty's cooperation, and auditable by the user through her own interface.
Low-bandwidth, feature-phone-compatible integration
The majority of users for whom interoperability matters most transact from feature phones via USSD sessions, not from smartphones with web clients. The interoperability layer has to meet them there. This is a specification-level requirement, not an afterthought — it determines which authorisation flows, which addressing schemes, and which settlement confirmations can actually be exposed to the users whose inclusion is most at stake.
Regulatory compatibility with the existing payment-systems framework
An interoperability layer that cannot be operated inside the existing regulatory perimeter is a specification, not infrastructure. The Kenyan National Payment Systems Act, the CBK Payment Systems Regulations, the Digital Credit Regulations, and the Data Protection Act together define the regulatory envelope; an interoperability proposal has to fit inside it. The Lab's regulatory-frameworks reading develops this in detail.
The four requirements are relatively easy to state in the abstract and surprisingly difficult to meet simultaneously in concrete implementations. Most of the research programme is concerned with exactly that — testing design choices against all four requirements at once and documenting where the gaps are.
The closed-loop architectures, read against the requirements
A useful exercise is to read the four financing architectures operating in Kenya against the four design requirements above. The exercise makes concrete what the closed-loop problem actually costs.
| Requirement | PAYGO | Ride-to-Own | BaaS | Concessional |
|---|---|---|---|---|
| Addressable endpoints | No — operator-internal identifier only | No — contract reference internal | No — rider credential operator-bound | N/A — wholesale layer |
| Scoped authorisation | Partial — direct-debit only | Partial — direct-debit with limits | No — per-swap interactive only | N/A |
| USSD/feature-phone compat. | Yes — via USSD initiation | Yes — via USSD initiation | Partial — interactive at station | N/A |
| Regulatory compatibility | Yes — licensed under DCR | Yes — licensed under DCR | Yes — till-number regime | Yes — financial-institution licensed |
The table makes the pattern visible. The existing architectures score well on USSD compatibility and regulatory compatibility — they have to, to operate — and poorly on addressable endpoints and scoped authorisation. The gaps are exactly the gaps that an interoperability layer could close.
What a minimum-viable interoperability layer looks like
The Lab's view — developed through design work and refined in fieldwork — is that a minimum-viable interoperability layer for the Kenyan context consists of four modules. Each is independently useful; together they produce the interoperability outcome the finance programme is organised around.
Each module is designed to be independently useful and independently testable. The Lab's pilot work tests the modules in isolation before exercising them in combination, to ensure that the empirical evaluation of interoperability is not entangled with the specific integration design.
The deployment posture
A durable interoperability layer is only useful if it actually gets deployed. The Lab's view on deployment, informed by direct conversations with Kenyan fintech developers and with operators in the four financing architectures, is that adoption will proceed, if it proceeds at all, not by displacing existing stacks but by layering above them.
The concrete shape of that layering, for the Kenyan case, is: mobile-money accounts remain the primary user-facing relationship; interoperability identifiers are added as secondary addressability on top of existing mobile-money accounts; operators (PAYGO financiers, BaaS networks, ride-to-own financiers) add interoperability endpoints to their existing stacks without displacing their Daraja integrations; inter-operator flows and cross-border flows are routed through the interoperability layer; domestic in-network flows continue to route through existing mobile-money channels.
This is a conservative deployment posture. It is the right one. It preserves the relationships users already trust; it reduces the switching cost for operators; it concentrates the interoperability layer's distinctive value at the inter-operator and cross-border layers where closed-loop architectures create the most friction.
Working hypothesis
An interoperability layer will reach scale in African mobile-money markets not by replacing closed-loop rails but by providing the shared addressability layer above them that closed-loop architectures, on their own, cannot produce. The Lab's finance programme is organised around testing that hypothesis in a specific operational site (Kenya's boda-boda ecosystem), with enough fidelity that the results are usable beyond that site.
A note on protocols
Several open-standards proposals and reference implementations exist that address parts of the interoperability requirements outlined above. The Lab does not endorse any single protocol; different proposals address different combinations of the four design requirements, and the sensible practitioner position is to evaluate each against the operational context rather than selecting in advance. The Lab's research engages with the major open-standards families as neutral observers and, where our field evidence suggests specification-level adaptation is needed, contributes that evidence back to the relevant protocol communities through their published channels.
The Lab's commitment is to the interoperability outcome described in this entry, not to any specific protocol or vendor. If a different protocol configuration turns out to serve the four design requirements better than a Lab-favoured alternative, our research programme will say so openly.