Kenya's draft National Payment System Policy 2026: what it means for open banking

On 21 September 2026 the Central Bank of Kenya (CBK) published two documents for public consultation: the National Treasury’s Draft National Payment System Policy, dated August 2026, and the Draft National Payment System Bill, 2026. Together they set out where the government proposes to take Kenya’s payments system.

One part of the draft policy matters directly to anyone who holds customer financial data: it proposes open banking and data-sharing rules. Here is what the drafts say, what they do not yet do, and how a bank, SACCO, microfinance institution or fintech can prepare without guessing at the final rules.

Information current as of 13 October 2026. This is not legal advice; the policy and bill are drafts.

What the drafts propose

Open finance, defined

The draft policy describes open finance as a third party accessing, with the customer’s permission, the customer’s data held by a payment service provider (PSP) or a payment system operator. The two ideas in that sentence carry everything else: the data belongs in the customer’s control, and access depends on their permission.

Open banking and data governance frameworks

A section of the draft policy headed “Implement Open Banking and Data Governance Frameworks” proposes that Kenya develop clear open banking and data-sharing regulations. It points to the UK and the EU as inspiration, and links the aim, secure exchange of financial information, to Kenya’s data protection laws.

Proposed government initiatives

Among the initiatives the draft policy lists for government are:

• mandating open API standards, so financial systems, payment system operators (PSOs) and PSPs can integrate with each other;
• mandating the adoption of national or global messaging standards;
• developing a national instant payment switch; and
• implementing a regulatory sandbox.

What is not yet law

Both documents are drafts published for consultation. As at 13 October 2026:

• Kenya has no open banking regulations yet. The draft policy proposes that such rules be developed; it does not contain them.
• The bill is not an Act. It must still go through consultation and the legislative process, and its text may change.
• Standards are proposals. The draft calls for open API and messaging standards to be mandated; until rules are made, none is binding.

What does already apply is existing law, including the Data Protection Act, 2019, which governs how customer data is shared today. Your legal advisers should confirm what applies to your institution.

Why prepare before the rules are final

Partners already ask financial institutions for access to balances, transactions and payments. Each request tends to become a one-off connection with its own credentials and no common audit trail. That is a security and operational problem now, whatever the final rules say.

The groundwork for safe data sharing is the same under almost any framework: know your APIs, put a secure gateway in front of them, record permission and access, onboard partners deliberately, and watch the traffic. None of it is wasted if the final text changes.

Five practical readiness steps

1. Inventory your APIs and data

List the systems that hold the data and services partners will ask for: core banking, payments, cards, mobile and internet banking. Record which interfaces already exist, who calls them, with what credentials and under which agreement. Most institutions find connections nobody owns.

2. Put a gateway and proper security in front of them

Partners should call one gateway, never your core. The gateway authenticates every caller with OAuth2 and OpenID Connect, applies the scopes and limits each partner agreed to, and logs every call. Internal and administrative routes are never published.

3. Design consent and audit

Decide how a customer’s permission will be captured, checked on every call, and withdrawn, and how each access is traced to a partner, a purpose and a permission. Build only what your legal advisers confirm is required or allowed under current law, and keep the design flexible for the final rules.

4. Plan partner onboarding and a sandbox

Write down how a partner is approved, how it gets keys, what it may call and how it is suspended. Give partners an API catalogue, documentation and a sandbox with synthetic data, so they test against something safe before production.

5. Monitor traffic and add fraud controls

Alert on errors, latency and unusual partner behaviour. Apply fraud-risk controls to partner traffic, and feed it into your transaction monitoring where you run it. Open APIs are a new channel, and they deserve the same scrutiny as any other.

How we can help

We assess API readiness and build secure, well-governed integration for banks, SACCOs, MFIs, fintechs and PSPs. See Open Banking & API Readiness for what the work covers, and WSO2 API and integration for the gateway and integration platform we work with.

We will update this article if the drafts change status. Information current as of 13 October 2026.