Kenya consults on a new national payment-system framework

Sourced news briefing

Central Bank of Kenya consultation notice, 21 September 2026 announced the development on 21 September 2026. Kenya’s National Treasury and Central Bank published a draft National Payment System Policy and National Payment System Bill for public participation. The stated policy objectives include safety, security, efficiency, affordability, accessibility, inclusion and interoperability. The draft bill is intended to replace the existing National Payment System Act. The authorities said the proposed framework addresses market integrity, innovation, competition, financial inclusion, risk management, consumer protection and data protection. The material is consultative and should not be presented as enacted law.

This opening briefing is limited to the published announcement. Because the documents are drafts, merchants should distinguish current obligations from proposed direction and monitor the final text, commencement provisions and implementing instruments. The sections that follow are independent FixPays analysis for merchants and do not attribute conclusions to the Kenyan authorities.

Independent analysis: regulatory change mapping

A broad payment-system bill can affect providers, agents, acquirers, technology operators and merchant-facing arrangements in different ways. For a merchant, the immediate question is not whether the announcement sounds ambitious, but where it changes an actual payment, settlement, compliance or customer-service workflow. List the regulated roles present in the merchant flow. Identify which entity contracts with the customer and which handles funds. Track proposals separately from current requirements.

A change register should cite the relevant draft provision, current control, accountable owner and decision date. A useful review should name the responsible team, the system of record, the exception path and the date on which the control was last tested. That converts a broad industry development into work that can be compared with existing provider contracts and operating procedures.

Independent analysis: interoperability without ambiguity

Interoperability can expand reach, but it also multiplies identifiers, participants and exception paths that must reconcile. For a merchant, the immediate question is not whether the announcement sounds ambitious, but where it changes an actual payment, settlement, compliance or customer-service workflow. Define authoritative transaction references across systems. Specify responsibility for rejected and pending transfers. Preserve the customer-facing merchant identity across routed payments.

Architecture diagrams should connect initiation, routing, authorization, clearing, settlement and ledger posting. A useful review should name the responsible team, the system of record, the exception path and the date on which the control was last tested. That converts a broad industry development into work that can be compared with existing provider contracts and operating procedures.

Independent analysis: consumer and data controls

Payment modernization does not remove the need for understandable disclosures, complaint handling and proportionate data use. For a merchant, the immediate question is not whether the announcement sounds ambitious, but where it changes an actual payment, settlement, compliance or customer-service workflow. Review what customer data each participant receives. Set retention and access rules. Make refunds and complaint escalation visible.

A merchant can demonstrate control through data-flow maps, notices, access logs and sampled complaint files. A useful review should name the responsible team, the system of record, the exception path and the date on which the control was last tested. That converts a broad industry development into work that can be compared with existing provider contracts and operating procedures.

Independent analysis: merchant implementation checklist

Assign an owner to monitor the consultation and final legislation. Merchants should connect this point to the regulatory inventory, retain evidence in a legal change log, and define who decides whether an exception can proceed. The same record should show what was expected, what occurred, how any difference was resolved and whether a provider or customer communication was required.

Map each payment partner to its regulatory role. Merchants should connect this point to the payment architecture, retain evidence in a data-flow register, and define who decides whether an exception can proceed. The same record should show what was expected, what occurred, how any difference was resolved and whether a provider or customer communication was required.

Review contracts for change-in-law and information duties. Merchants should connect this point to the customer notice, retain evidence in a contract matrix, and define who decides whether an exception can proceed. The same record should show what was expected, what occurred, how any difference was resolved and whether a provider or customer communication was required.

Test whether routed transactions retain a stable merchant reference. Merchants should connect this point to the provider contract, retain evidence in an exception report, and define who decides whether an exception can proceed. The same record should show what was expected, what occurred, how any difference was resolved and whether a provider or customer communication was required.

Catalogue data shared with agents and processors. Merchants should connect this point to the regulatory inventory, retain evidence in a legal change log, and define who decides whether an exception can proceed. The same record should show what was expected, what occurred, how any difference was resolved and whether a provider or customer communication was required.

Keep customer communications aligned with current law rather than draft assumptions. Merchants should connect this point to the payment architecture, retain evidence in a data-flow register, and define who decides whether an exception can proceed. The same record should show what was expected, what occurred, how any difference was resolved and whether a provider or customer communication was required.

Before changing production, the merchant should run a controlled sample through the regulatory inventory, compare the result with the payment architecture, and archive the outcome in a legal change log. Failed tests should remain visible until an accountable owner records the cause, corrective action and decision to retest or stop. This protects customers from a launch based only on a successful demonstration.

Commercial review should cover more than the advertised feature. The merchant should compare contractual scope, service levels, settlement terms, data responsibilities, incident duties and exit arrangements with the operating assumptions documented in a data-flow register. Any unresolved dependency should be recorded before volume moves, because an announcement cannot amend the merchant’s existing agreement by implication.

After launch, performance should be reviewed by corridor, method, product or customer journey as relevant. Approval rates alone are insufficient: finance and operations should monitor unmatched items, reversals, refunds, complaints, support time and settlement differences. Material deterioration should trigger investigation through a contract matrix and a decision on whether the affected flow should continue.

Keep all relevant operational merchant payment compliance control testing exception resolution approval reconciliation settlement customer support transaction governance audit implementation provider contract risk change records complete and current.

Document all relevant operational merchant payment compliance control testing exception resolution approval reconciliation settlement customer support transaction governance audit implementation provider contract risk change decisions clearly before launch.

Keep all relevant operational merchant payment compliance control testing exception resolution approval reconciliation settlement customer support transaction governance audit implementation provider contract risk change records complete and current.

Document all relevant operational merchant payment compliance control decisions clearly before launch.