Kenya's payment law is being rewritten. What the draft Bill would change for businesses.

Most businesses ignore payment law, and usually they are right to. The draft published in Nairobi on 21 September 2026 is different in one specific way: it would decide whether a business can read its customers’ payment data through software, or whether it keeps asking for screenshots and statements. That is an architecture question, not a compliance one — and the window to comment closes on 9 October 2026.

What is happening?

The National Treasury and the Central Bank of Kenya (CBK) published two documents on 21 September 2026: the draft National Payment System Policy (the text itself dated August 2026) and the National Payment System Bill, 2026, which would repeal the National Payment System Act, Cap. 491A, in force since 2011.

The public notice, signed by the Cabinet Secretary for the National Treasury, invites comments by Friday 9 October 2026, by post to the Governor of the CBK or by email to paymentslawreview@centralbank.go.ke, using the published template. Eleven county forums run between 28 September and 9 October.

Three provisions matter most.

Interoperability becomes an obligation. Clause 28 says each provider and operator “shall use systems that are interoperable with the systems used by other payment service providers and payment system operators, and their agents”. The CBK could also compel a provider into an interoperability arrangement, and failure attracts administrative enforcement.

Open finance becomes a required capability. Clause 29 says each provider “shall use systems that are capable of securely sharing customer data with third parties for open finance purposes”, and that the CBK may require a mechanism to share that data after obtaining the customer’s consent. The detail is deferred to regulations the CBK must still make. The draft Policy is blunter about direction, listing among its strategies to “mandate open API standards to facilitate seamless integration across financial systems, PSOs and PSPs”.

Licensing is rebuilt by activity. The First Schedule sets out ten categories: six for payment service providers, from payment initiation to electronic money issuance, and four for operators, from gateways to switching. The Third Schedule attaches minimum capital to each, from Ksh 5 million for a payment initiation or account information licence to Ksh 250 million for an electronic money issuer, with wallet providers and merchant acquirers at Ksh 50 million. Banks and microfinance banks, among others, would not need a licence under clause 9, but would still need CBK authorisation and the same capital. Clause 79 allows one year from commencement to comply.

What remains uncertain matters as much as what is proposed. This is a draft in public participation, not law: it must be finalised, introduced and passed, and the open-finance mechanics depend on regulations the CBK has not written. The text also carries the marks of a draft: its interpretation clause cross-refers to the wrong licensing section. Comments in this window are how details like that get fixed.

Why it matters economically

Kenya’s payment reforms so far have been about speed and reach. This one is about the cost of information.

Consider what a Kenyan business pays to know something it already has a right to know. A distributor extending 30-day terms wants evidence of a retailer’s cash flow, and receives a PDF statement. A finance team matching receipts to invoices reads an SMS log. Both are the same purchase: information that already sits in a provider’s system, retrieved by the slowest available method, at a cost paid in staff hours, delay and the credit losses that follow from deciding on thin evidence.

Clause 29 would not abolish that cost, but it would change who controls it. Consented access to customer data would become a capability providers must build rather than a commercial favour they may grant, and the marginal cost of a read moves towards the cost of an API call. The draft Policy puts the problem in the same terms: although mobile money has driven inclusion and interoperability, “the broader payments landscape remains fragmented”, and that fragmentation “has led to high transaction costs, inefficiencies and poor service”.

The Bill reprices the other direction too. Capital requirements turn “build our own wallet” from a software decision into a Ksh 50 million balance-sheet decision, and clause 36 requires customer float to sit in trust accounts, with no single bank holding more than Ksh 500 million or 25% of the monies, whichever is higher. Our reading is that this settles the build-or-integrate question in favour of a licensed provider for all but the largest operators.

What it means for African businesses

This is a Kenyan Bill; it binds nobody outside Kenya, and its significance elsewhere is directional.

South Africa is moving the same way on a slower timetable: the Reserve Bank intends to replace entity-based regulation with activity-based regulation, so that the same payment activity carries the same expectations whether a bank or a fintech performs it, and to open the national payment system to non-banks. As of 1 September 2026 its own National Payment System Bill had not gone out for public comment, and reporting on 10 September 2026 quoted Standard Bank’s head of interbank payments putting the next iteration of the framework in the first quarter of 2027. West Africa has taken a third route — regulator-built rails with approved business interfaces — which we covered when the BCEAO published its approved PI-SPI Business APIs. For a business trading across these markets, “payments integration” is not one project: licence perimeters, data-sharing rules and messaging standards will differ by country for years.

Within Kenya, the businesses affected are not only the obvious ones. Clause 4(1) applies the Act to anyone who “processes, stores or shares data on behalf of a payment service provider or a user of payment services”, and to anyone engaged in “ancillary services that support the provision of a payment system or payment service”. Read literally, that reaches software vendors, marketplaces that collect and pay out, and businesses holding payment records for their own customers. Because the licence categories in the First Schedule are narrower than that application clause, a business cannot tell from the face of the Bill which side of the line it sits on — exactly the kind of gap a comment should raise.

Technology and AI implications

Where technology helps is narrow and real. Clause 52 would require each provider to keep records retrievable “without delay” for the CBK, the Financial Reporting Centre and law enforcement, and to maintain “systems and controls capable of tracing a payment through the payment chain”. An operation keeping payment records in a spreadsheet and a WhatsApp thread cannot do that. The rails have already moved this way: the CBK migrated KEPSS to the ISO 20022 messaging standard on 14 October 2024. Richer message data improves reconciliation — but only for a business whose systems read the message rather than a person reading a notification.

Where technology does not help is worth stating plainly. The uncertainty here is legal, not technical: no amount of engineering tells you whether clause 4(1)(k) catches your product. Nor should a business build against open-finance APIs yet, because the field names, consent flows and coverage will be set by regulations that do not exist.

AI has one honest use here: reading the Bill against your own operations and drafting a comment, provided a person verifies every clause reference before it is sent, because a confident summary of a law is not a reading of it. It cannot give you a compliance position, or manufacture the record-keeping clause 52 assumes. Our view is that anyone selling “AI-ready open banking” in Kenya this quarter is selling ahead of the regulations.

Practical business implications

Five questions are worth answering before 9 October.

1. Are we in scope? Read clause 4(1) against what your systems actually do, not how you describe your business. Storing payment data on behalf of customers, or collecting and paying out on a marketplace, deserves legal advice rather than an assumption.
2. If we hold customer funds, what is our position? Compare your capital and float arrangements with the Third and Fourth Schedules; clause 79’s one-year transition is short for a balance-sheet change.
3. Could we trace a payment end to end today? Take a transaction from three months ago and follow it from receipt to invoice to ledger. If that takes an afternoon, clause 52 is a systems project — the same one as fixing reconciliation, set out in mobile money is a payment method, reconciliation is the business system.
4. What would we do with consented data access? For most businesses the honest answers are faster reconciliation and better credit decisions. Both need somewhere for the data to land: one record of customers, orders and payments rather than four disconnected tools — the work described under CRM and business systems.
5. Do we want to comment? Use the CBK template, name the clause, say what it would cost your business, and send it before 9 October — or take it to your county forum.

RevenueStack perspective

Regulation is quietly writing the integration layer of African business systems. Whether a Kenyan business could read payment data through software has been a commercial question, settled by whichever provider it had leverage with. Clauses 28 and 29 would make it a legal capability.

Our interpretation, through the economics rather than the compliance: the winners from open finance will not be the businesses with the best API strategy. They will be the businesses with somewhere to put the data. Access is becoming abundant; the ability to use it is not. In the operations we see, the binding constraint is not connectivity to a provider but the absence of a system of record that could absorb a payment feed.

That gives a clean test for any project this Bill might prompt: does the work pay for itself if the Bill never passes in this form? Building one record of customers, orders and payments passes, because it reduces reconciliation hours and credit risk on its own terms. Building against unwritten API specifications fails, and applying automation to a process nobody has defined fails twice.

Conclusion

The Bill is a proposal, not a rule, and its most consequential clause — the open-finance obligation in clause 29 — is an empty frame until the CBK writes the regulations to fill it. That is why this fortnight matters more than the eventual commencement date: the shape of the obligation is being decided now, by whoever writes in by 9 October. For businesses in Kenya the immediate action is not a technology project but twenty minutes with clause 4, an honest look at whether they could trace a payment through their own records, and a memorandum if either answer is uncomfortable. The systems work follows — and the part worth starting now is the part that pays whatever Parliament decides.

Sources

1. Draft National Payment System Policy and National Payment System Bill, 2026 — Central Bank of Kenya, 2026-09-21
2. Public Notice — Draft National Payment System Policy and National Payment System Bill, 2026 — The National Treasury (Kenya), 2026-09-21
3. The National Payment System Bill, 2026 — Central Bank of Kenya, 2026-09
4. Draft National Payment System Policy, 2026 — The National Treasury and Central Bank of Kenya, 2026-08
5. New Payment Bill Wants to Force Banks and M-PESA to Open Up Their Data — Techweez, 2026-09-22
6. South Africa is changing who gets to move money — TechCabal, 2026-09-10
7. National Payment System Bill: Sarb readies overhaul — TechCentral, 2026-09-01