Kenya is not simply proposing more licences for its payments sector. The draft National Payment System Bill, 2026, released for consultation by the National Treasury and the Central Bank of Kenya, would move several issues often treated as technical or commercial aspirations into the realm of enforceable regulatory obligations.
Interoperability is the most visible part of the proposal. The more consequential shift may lie elsewhere: in the way the draft links interoperability with incidents, outsourcing, reconciliation, safeguarding and traceability. It does not only ask whether systems can connect. It starts to define who remains accountable when the payment chain fails.
This analysis is based on the draft Bill and draft National Payment System Policy published in September 2026. Neither document is law yet. Public comments are due by 9 October 2026.
From an interoperability goal to an enforceable duty
Kenya already has relatively advanced mobile money interoperability. The draft policy notes that person-to-person interoperability was introduced in 2018 and that, by July 2022, the Central Bank considered interoperability among participating mobile money providers to cover merchant and bill payments as well.
The official diagnosis remains qualified. Banks, mobile money operators, payment service providers, payment systems and government platforms are still not seamlessly interoperable across every use case.
Clause 28 of the draft Bill changes the nature of the issue. It says that every payment service provider and payment system operator must use systems that are interoperable with those used by other providers, operators and their agents. The Central Bank could direct an institution to enter an interoperability arrangement. Failure to comply could trigger administrative enforcement.
That distinction matters. A strategy sets direction. A legal duty creates enforcement power and may reduce the ability of a dominant operator to delay a connection that would weaken its network advantage.
However, a statutory duty cannot guarantee high-quality interoperability on its own. Detailed rules will still be needed for APIs, messaging, service levels, fees, cost allocation, settlement timing, disputes and liability when a transaction fails. Without those parameters, two systems can be legally required to connect while delivering a service that remains slow, expensive or difficult to reconcile.
Payment operations move inside the legal perimeter
The draft explicitly identifies several events that sit at the centre of day-to-day payment operations. Clause 33 lists, among others:
- loss, unauthorised access to or misappropriation of customer funds;
- reconciliation variances above a threshold set by the Central Bank;
- a prolonged or systemic outage affecting processing or settlement;
- failure or material degradation of a critical third-party provider;
- a material liquidity shortfall, cybersecurity incident or data breach.
This list is more significant than a general incident-reporting obligation. It recognises that payment resilience does not depend only on the customer-facing platform. It also depends on technology suppliers, safeguarded accounts, settlement, reconciliation files and the ability to detect a gap between what the ledger says is owed to customers and the money actually held.
Two further provisions reinforce this approach. Outsourcing an operational function would require prior written approval from the Central Bank when failure could undermine continuity, soundness or compliance. Providers and operators would also have to submit an independent system audit each year.
In practical terms, a fintech could no longer treat its processor, cloud provider or KYC vendor as a black box that alone carries the risk. The regulated firm would remain responsible for its control architecture and for demonstrating operational resilience.
Regulation follows functions more closely
The draft separates licence categories that correspond to actual functions in the payment chain: payment initiation, account information, merchant acquiring, electronic wallets, money remittance, electronic money issuance, payment gateways, messaging, card schemes, and switching and clearing.
This addresses a familiar regulatory problem. Different firms can perform similar economic functions while describing themselves with different commercial labels. Function-based supervision can align regulatory requirements more closely with the risk created.
The boundaries will still require careful calibration. A gateway that never holds funds does not have the same risk profile as an electronic money issuer. An account information provider does not carry the settlement exposure of an acquirer. Capital requirements, exemptions and proportional rules will determine whether modernisation improves market integrity without creating excessive entry barriers.
Safeguarding, finality and traceability address different risks
The draft would require electronic money issuers and wallet providers to hold all customer monies in trust accounts with banks or microfinance banks. The balance could never fall below the amount owed to customers. Funds would be segregated from the company’s own money and protected from creditors in insolvency.
That mechanism addresses the solvency of the entity holding customer value. It does not replace settlement finality. Clause 42 separately addresses the point at which a payment becomes final and irrevocable under system rules, while allowing recovery for fraud, error or mistake under future procedures.
Clause 48 adds a third layer. Every payment would have to carry the information needed to identify the originator and beneficiary, or at least unique references where no account is used. That information would have to remain with the transaction throughout the payment chain.
The three protections are complementary:
| Risk | Draft response |
|---|---|
| A provider loses or uses customer money | Trust-based safeguarding |
| A settled transaction is later challenged | Finality and irrevocability rules |
| A transaction cannot be reconstructed | Persistent identifiers and payment data |
This combination is relevant to wallets and cross-border payments. It could also increase the amount of personal data exchanged between intermediaries. Traceability will therefore need to be balanced with data minimisation, secure transmission and retention rules.
Open finance is created, but not yet operationally defined
Clause 29 would require providers and operators to use systems capable of securely sharing customer data with third parties. The Central Bank could require a sharing mechanism after obtaining customer consent.
The principle is clear. The operating model is not. The draft delegates implementation to future regulations. Those rules will have to answer decisive questions: which data can be accessed, through which APIs, for how long, under what consent model, who pays for connectivity, and who is liable when data or an instruction is wrong.
This is not a secondary detail. In open finance, competitive value does not come from access rights alone. It depends on interface quality, data availability, integration costs and incident management.
Lessons for other African payment markets
Kenya’s proposal should not be copied mechanically. Market structure, central bank powers and the relative weight of banks, telecom operators and fintechs differ across Kenya, WAEMU and CEMAC.
The draft nevertheless provides a useful analytical checklist:
- Is interoperability a policy objective, a technical standard or an enforceable duty?
- Are reconciliation breaks and third-party outages defined as regulatory incidents?
- Do the rules separately protect funds, finality and traceability?
- Does licensing follow the functions actually performed?
- Do implementing rules specify costs, standards, accountability and service levels?
The draft’s most original contribution is not a promise of more innovation. It is the decision to bring payment operations inside the regulatory accountability framework. Its effectiveness will now depend on the implementing regulations and on the Central Bank’s ability to translate broad principles into measurable thresholds, standards and controls.
