Kenya's Draft Payment System Reform Would Require Banks and Mobile Money Operators to Open Customer Data to Licensed Rivals

Kenya’s draft payment system reforms would reshape the country’s financial infrastructure by moving toward a model in which banks, electronic money issuers and mobile money operators such as M-Pesa may be required to share customer payment-account data with licensed third parties on customer instruction. Such reforms form part of the broader national payment system modernisation agenda led by the Central Bank of Kenya (CBK) and the National Treasury. For banks, payment service providers (PSPs), fintechs, compliance teams and foreign payment groups seeking entry to the East African market, understanding the direction of travel and engaging early in any public participation process is commercially important.

This article maps the likely licence architecture, explains the open-finance concepts under discussion, sets out capital-sizing considerations and provides a practical checklist for preparing comments on any published draft.

Executive summary and immediate actions

Reform of Kenya’s national payment system, building on the National Payment System Act and its regulations, is among the most significant developments in the country’s payments regulation in over a decade. At the centre of the open-finance debate is a framework in which, on a customer’s consent, incumbent holders of payment-account data, including banks and mobile money operators, would make that data available to licensed competitors. The intended effect is to lower barriers for new entrants, stimulate competition and give consumers greater control over their financial information.

• What could change. A more disaggregated licence architecture, dedicated open-finance licence categories, and expanded powers for the CBK to set the mechanisms through which data is shared and systems interoperate.
• Who is affected. Banks, electronic money issuers, electronic wallet providers, merchant acquirers, payment system operators, card issuers and processors, aggregators, and potential payment initiation and account information service providers.
• The process. Where a draft Bill or policy is published for public participation, written comments are typically invited within a defined window stated in the official notice. Confirm the exact deadline and channel directly from the CBK and Treasury.

Three immediate actions should be prioritised by every affected institution. First, map every service you currently offer, and intend to offer, against the likely licence categories, because many providers will span more than one. Second, model the capital consequences of holding multiple licences, since aggregation rules can materially increase the total minimum capital you must carry. Third, convene legal, compliance, product and technology teams to prepare a written submission for any comment process. Early engagement is the most effective way to shape transitional provisions, consent standards and the technical rules the CBK may later issue.

What payment system reform in Kenya is likely to address

Where to find official drafts and how to participate

Any draft legislation or policy on the national payment system should be released for public participation by the relevant authority, typically the CBK, the National Treasury, or Parliament once a Bill is formally introduced. Affected institutions should confirm the exact submission address, format and deadline on the official CBK, Treasury and Parliament portals, and should download the official text directly from those primary sources rather than relying on secondary summaries. Public participation is a constitutional requirement under Article 118 and related provisions of the Constitution of Kenya, 2010, for legislation proceeding through Parliament.

Likely scope and objects of reform

The stated purpose of payment system reform is generally to modernise the legal framework governing payment systems in Kenya, promote competition and innovation, protect consumers and strengthen the oversight of an increasingly interconnected payments ecosystem. Kenya’s payment system reforms would plausibly move away from a single, broad authorisation for payment service providers toward more granular, activity-specific authorisations, and could embed open-finance principles that provide for data portability between licensed participants. The policy intent across comparable markets is to move toward a consent-driven, interoperable payments market.

The CBK’s role

A central feature of payments reform is the role of the Central Bank of Kenya, which already supervises payment systems and PSPs under the National Payment System Act. Reform proposals typically empower the CBK to set the mechanisms by which payment-account data is shared, to prescribe technical and security standards for interoperability, and to supervise the operation of shared, clearing and settlement systems. In practice, this means the regulator, rather than individual market participants, would determine the architecture through which open-finance requests are routed, authenticated and settled.

Open-finance concepts explained, what would be treated as a data-sharing request

Defining an open-finance request

In an open-finance model, a data-sharing request is, in essence, an instruction by a customer authorising a licensed third party to access their payment-account data or to initiate a transaction on their behalf. Three categories of request illustrate the scope of open finance that Kenya may move toward:

• Account information requests. A licensed account information service provider reads a customer’s transaction history, balances and payment data to deliver services such as aggregated budgeting, affordability assessments or credit scoring.
• Payment initiation requests. A licensed payment initiation service provider instructs the customer’s bank or wallet provider to move funds directly, bypassing card rails or manual transfers.
• Recurring payment arrangements. A customer authorises standing or variable recurring payments initiated by a third party, such as subscription collections or instalment repayments.

The common thread across all three is that incumbents, including banks and mobile money operators, would respond to a valid, consented request from a licensed counterparty. The practical consequence is that data held by the largest incumbents could become a shared competitive resource rather than a proprietary advantage.

Consent requirements and minimum data standards

Consent is the cornerstone of any open-finance regime, and it must interact cleanly with the Data Protection Act, 2019. Kenya’s data-protection framework already requires that personal data be processed lawfully, with the data subject’s consent being a key lawful basis. In practical terms, institutions should expect any open-finance framework and subordinate technical rules to address the following:

• Explicit and informed consent. Consent should be specific to the data being shared and the purpose for which it is requested; blanket or bundled authorisations are unlikely to satisfy the Data Protection Act.
• Time limits and renewal. Consent should be time-bound, with clear expiry and renewal mechanics so that access does not persist indefinitely without the customer’s reaffirmation.
• Revocation. Customers should be able to withdraw consent easily, and incumbents should be able to act on revocation promptly to cut off further access.
• Authentication. Strong authentication of both the customer and the requesting licensed party is essential to prevent fraudulent or unauthorised requests.
• Liability allocation. Any framework should make clear who bears responsibility where an unauthorised or erroneous data transfer or payment occurs.

Because the Office of the Data Protection Commissioner (ODPC) enforces Kenya’s data-protection regime, institutions should design consent flows that satisfy both the CBK and the ODPC. Recordkeeping, proving that valid consent was obtained, used within scope and respected on revocation, will be a practical compliance burden and a litigation risk if neglected.

A more disaggregated licence architecture, practical mapping

How activity-specific categories work

Payment system reform typically disaggregates a broad payment service provider authorisation into a set of activity-specific licences. This is a decisive shift: a provider that today operates under one broad authorisation may, under a new regime, need several. Among the likely additions are a payment initiation service provider category and an account information service provider category, dedicated open-finance authorisations that would sit at the lower end of any capital scale but carry significant data-handling obligations.

How to map an existing provider to one or more categories

Mapping begins with an honest inventory of every revenue-generating and customer-facing activity. For each activity, ask: does this involve issuing e-money, holding customer float, operating wallets, acquiring merchant payments, initiating payments on behalf of a customer, reading account data with consent, or operating a clearing and settlement system? Each affirmative answer points to a licence category, and many providers will trigger several.

Consider a bank that offers a consumer wallet, acquires merchant payments and plans to launch an aggregation service reading customer data. That institution may need to hold an electronic money or wallet authorisation, a merchant acquirer authorisation and an account information service provider authorisation, three categories under one roof. A pure-play fintech adding a payment initiation feature to an existing wallet product would, similarly, need to layer a payment initiation authorisation onto its wallet licence. The decision is rarely binary; it is a matrix that drives directly into the capital-sizing exercise discussed below.

The current minimum capital and net-worth requirements for payment service providers and e-money issuers are set out in the National Payment System Regulations and related CBK guidelines. Because any reform may revise these figures, institutions should confirm the exact amounts against the published official text before making decisions, rather than relying on indicative numbers.

Capital sizing, group rules and worked examples

A key commercial question raised by a disaggregated licence model is how much capital a multi-licence provider must hold. Some proposals contemplate an aggregation rule, for example, total required capital equalling the capital of the highest category held plus a percentage of the capital requirement of each additional category. Any such rule would penalise breadth and reward focus, and would force many diversified players to reassess which activities genuinely justify a separate authorisation. The exact formula, if any, must be confirmed against the enacted text and any explanatory notes.

To illustrate the mechanics in general terms: if a provider holds a high-capital category and adds a low-capital open-finance category under an aggregation rule, its total minimum capital would exceed the higher figure by a proportion of the additional category’s requirement. These illustrations show how an aggregation rule compounds as activities multiply, and why a mobile money operator that also acquires merchants and reads account data could face a materially higher capital floor than today. Because the precise figures and formula are not settled, institutions should model scenarios rather than treat any single number as fixed.

Practical steps for CFOs and compliance teams

Finance and compliance leaders should build a licence-by-licence capital model using the current prescribed requirements as a baseline and testing alternative aggregation assumptions. Stress-test against your most ambitious product roadmap, identify activities that could be housed in a separate legal entity to manage capital, and factor in any transitional grace period that reform may allow. Early modelling also strengthens any comment submission: a credible, numbers-backed case for a phased capital transition is far more persuasive to the regulator than a general objection.

Consent, data security and interoperability, technical and legal checklist

Minimum consent language and recordkeeping

Consent documentation must be specific, legible and auditable. Draft consent language that identifies the requesting licensed party, the exact data categories involved, the purpose, the duration and the method of revocation. Retain a reliable record of each consent event, each use of data within scope, and each revocation. These records are your primary defence if a customer or the ODPC later challenges a transfer, so build recordkeeping into the consent flow rather than bolting it on afterwards.

Security standards and API expectations

Because the CBK would be expected to set the data-sharing mechanism, institutions should anticipate standardised API requirements. Prudent preparation includes strong customer and counterparty authentication, data minimisation so that only the data necessary for the consented purpose is shared, encryption in transit and at rest, and comprehensive audit trails that log every request and response. Interoperability would demand that incumbents expose reliable, well-documented interfaces capable of handling consented requests at scale. Firms that begin building toward likely open-finance standards now will face a shorter and less costly compliance runway once any final technical rules are issued.

Preparing and submitting comments on any published draft

Practical checklist for legal, compliance, IT and product teams

Knowing how to respond to public participation on payments reform is a practical skill, and comment windows are often short, so coordination is essential. Use the following checklist to assemble a submission:

• Download the official draft text and any policy paper from the CBK, National Treasury or Parliament portals and confirm the exact submission channel and deadline.
• Complete the licence-mapping exercise so your comments reflect your real exposure across categories.
• Run the capital model and quantify the impact of any aggregation rule on your balance sheet.
• Identify the clauses that most affect your business, open-finance definitions, consent standards, capital tiers, CBK rule-making powers and enforcement provisions.
• Assign drafting ownership across legal, compliance, IT and product so each clause is reviewed by the team best placed to assess it.
• Consolidate into a single, clause-referenced submission and secure internal sign-off before the deadline.

Suggested comment points and template language

Effective submissions are specific and constructive. Recommend a defined capital transition period, phased implementation of any open-finance obligations, clear allocation of liability for unauthorised transfers, and an explicit commitment that the CBK will issue detailed technical standards before the data-sharing duties take effect. Two short illustrative paragraphs:

From a bank: “We support the policy objective of consent-driven data portability but request a transitional period of not less than eighteen months from publication of the final technical standards, to allow safe build-out of compliant APIs and consent-management systems. We further request that liability for losses arising from an unauthorised request rest with the licensed requesting party where our systems have correctly authenticated a valid consent.”

From a fintech: “We welcome dedicated PISP and AISP categories and proportionate capital thresholds. We ask that any aggregation rule for multiple licences be clarified in the final text, and that the Central Bank confirm standardised, openly documented API specifications to ensure a level playing field between new entrants and incumbents.”

Enforcement, transitional arrangements and business impacts

Likely enforcement approach and penalties

Payments legislation in Kenya already carries supervisory and penalty provisions enforced by the CBK under the National Payment System Act, including powers to refuse, suspend or revoke authorisations and to impose sanctions for non-compliance. Reform would likely extend these to any new data-sharing and capital obligations. Institutions should confirm the specific enforcement clauses and any transitional grace periods against the published text. A phased commencement is common, with open-finance obligations likely to follow, rather than coincide with, the issuance of detailed technical standards, though the final sequencing will depend on the enacted provisions.

Market impacts: competition, foreign entry and M-Pesa’s options

The likely practical effect of mandatory data portability is intensified competition. Lower-capital open-finance categories would reduce the barrier for fintechs and foreign PSPs eyeing the Kenyan market, while incumbents would lose the exclusive advantage of proprietary data. For a dominant mobile money operator, strategic options include embracing open finance as a platform play, monetising high-quality APIs and partnerships, rather than resisting data sharing. Providers who treat any new regime as an opportunity to build superior services on shared data, rather than merely a compliance cost, are likely to be best positioned.

Comparative view, open banking and open finance in East Africa

Kenya’s direction of travel sits within a wider regional trend toward open banking and open finance. Several of Kenya’s neighbours are at earlier stages of exploring data portability and interoperable payments, and regulatory approaches vary in scope, consent architecture and capital treatment. For cross-border PSPs, the practical significance is that regional alignment, or divergence, will shape how easily a licence and compliance build in one market can be reused in another. Firms operating across East Africa should track these parallel reforms closely, because convergence on common technical standards would lower the cost of multi-market expansion, while fragmentation would require jurisdiction-by-jurisdiction compliance. Comparative statements should be treated as directional; each neighbouring framework must be assessed against its own enacted law.

Key takeaways and recommended next steps

1. CEO: Treat payments reform as a strategic inflection point and decide whether to compete on shared data or defend existing positions.
2. CFO: Build and stress-test a multi-licence capital model, using current prescribed requirements as a baseline and testing any aggregation assumptions.
3. Head of Compliance: Map every activity to the likely licence categories and design dual-compliant consent and recordkeeping processes.
4. Head of Product: Begin scoping standardised, secure APIs for consented data sharing and payment initiation.
5. Legal counsel: Prepare and submit a clause-referenced comment on any published draft before the stated deadline.
6. Whole team: Download official drafts and policy from the CBK, Treasury and Parliament and verify every date, capital figure and clause against the primary text.

Conclusion

Payment system reform in Kenya would alter the competitive balance of the payments market by moving toward treating customer data as a shared, consent-governed resource and by replacing broad authorisations with a more granular, activity-specific architecture. For banks, PSPs, fintechs and foreign entrants, the combination of potential open-finance obligations, capital aggregation considerations and new consent duties interacting with the Data Protection Act makes early, coordinated preparation worthwhile. Institutions that map their licences, model their capital and submit substantive comments on any published draft will be better placed to shape a workable final framework and to compete in an open-finance market.

Verify every date, figure and clause against the official text published by the Central Bank of Kenya, the National Treasury or Parliament before committing to any course of action.

Sources

1. Central Bank of Kenya
2. National Treasury of Kenya
3. Parliament of Kenya
4. Law Society of Kenya
5. Office of the Data Protection Commissioner