When Does a Fintech Need a Payment Service Provider Licence in Kenya?

A business does not need a payment service provider licence merely because it calls itself a fintech. The real question is what the business does in the payment chain.

If a company receives or transmits payment instructions, handles or controls customer or merchant funds, processes electronic payments, issues stored value, operates a payment instrument or presents itself to users as the provider responsible for moving money, it should assume that the Central Bank of Kenya (CBK) authorisation question is live.

The legal analysis is functional. A platform described as a “gateway”, “marketplace”, “aggregator”, “embedded-finance provider” or “technology company” may still be carrying on payment service provider business. Conversely, a technology supplier that only provides software or infrastructure may have a different position—but the statutory definition is broad enough that the contract label alone is not conclusive.

The safest time to settle the licensing perimeter is before the product is launched, customer money begins to flow or commercial contracts lock the business into a regulated role.

1. Follow the payment, not the product name

Kenya’s National Payment System Act defines a payment service provider broadly. The definition covers persons providing services in relation to sending, receiving, storing or processing payments through an electronic system. It also extends to certain network operators and to persons that process or store data on behalf of payment service providers or their users.

Section 12 prohibits a person from conducting payment service provider business in Kenya without authorisation from CBK. A person carrying on the regular business of accepting money or payment instructions for the purpose of making payments to third parties also falls within a restricted area under section 11.

The analysis should therefore begin with a complete transaction-flow diagram, not the company’s website description. A fintech should identify:

1. who contracts with the payer, payee and merchant;
2. who receives the payment instruction;
3. whose account receives the money at each stage;
4. who controls routing, authorisation and settlement;
5. who performs reconciliation and controls reserves;
6. who decides whether a refund or reversal will be made;
7. who bears liability for failed or unauthorised transactions;
8. who sets the transaction fees and customer terms; and
9. which entity the customer understands to be providing the payment service.

Where the fintech occupies several of these roles, its licensing exposure is materially higher.

2. Activities that ordinarily raise a PSP authorisation question

Payment gateways and payment orchestration

A gateway that merely supplies technical connectivity is not necessarily in the same position as an entity that receives payment instructions, determines routing, onboards merchants, sets settlement terms, controls refunds or reconciles and settles funds.

The more the gateway becomes the merchant’s operational payment counterparty, the harder it is to characterise it as a passive software supplier. “We never hold funds” is relevant, but it is not always decisive: processing payment instructions is itself part of the statutory language.

Merchant aggregators and marketplaces

A marketplace may collect payment from a buyer and later remit the proceeds to a seller, less fees, commissions or reserves. That structure should be reviewed carefully. Questions arise around who accepts the buyer’s money, whether the seller has a direct acquiring relationship with a licensed provider, who controls settlement, and whether the marketplace is effectively receiving money to pay a third party.

A “merchant of record” or “super-merchant” model does not automatically solve the issue. The legal and economic substance must match the contractual description.

Wallets, stored value and e-money

A product that allows users to store monetary value, fund a wallet, transfer value or redeem it is likely to present a strong licensing case. Depending on the design, it may fall within e-money issuance or another payment service category. The regulatory work extends beyond the licence itself to safeguarding, liquidity, redemption, governance, information security, AML/CFT and consumer-protection controls.

Embedded payments and white-label products

A fintech can integrate a licensed bank or payment service provider into its app without itself becoming licensed in every case. The result depends on the allocation of functions.

The regulated provider should genuinely perform the regulated service. Customer disclosures, account structures, settlement flows, branding, complaints handling and liability clauses should support that allocation. A white-label agreement cannot transfer a function on paper while leaving the fintech to perform it in practice.

Cross-border collections and payouts

A company receiving funds in one country and arranging payment in another may engage the payments framework as well as foreign-exchange, remittance, AML/CFT, sanctions and exchange-control considerations. The presence of an offshore group company does not remove the Kenyan analysis if the service is marketed, contracted or performed in Kenya.

Virtual-asset payment products

Where the product uses virtual assets or stablecoins, the analysis is no longer confined to the National Payment System framework. Kenya’s Virtual Asset Service Providers Act, 2025 separately covers specified virtual-asset activities. Its First Schedule places virtual-asset payment processors or gateways and stablecoin issuance within CBK’s licensing mandate.

A business converting between fiat and virtual assets, accepting stablecoin payments or building virtual-asset settlement rails therefore needs a coordinated PSP and VASP perimeter assessment. The fact that the customer experiences the product as a “payment” does not mean that only one licensing regime applies.

3. When a fintech may be a technology supplier rather than a PSP

A lower-risk structure may exist where a fintech supplies software, cybersecurity, analytics, hosting or API connectivity while a separately licensed institution:

• contracts with the payer, merchant or account holder for the payment service;
• receives and controls the payment instruction;
• holds or safeguards the funds;
• performs settlement, refunds and chargebacks;
• sets and discloses the regulated payment terms; and
• remains responsible to the customer and CBK for the service.

Even then, caution is required. The statutory definition is broad and expressly reaches some data-processing and storage functions. Outsourcing by a licensed provider is also regulated: the National Payment System Regulations require advance notification to CBK for outsourcing and do not permit arrangements that impair the provider’s control or CBK’s supervision.

“Software-as-a-service” is therefore not a self-executing exemption. The operating model, contracts, account structure, user interface and actual conduct must tell the same story. Material product changes should trigger a fresh perimeter review.

4. A practical licensing test for founders and investors

Before concluding that no authorisation is needed, test the product against these questions:

If the answers are mixed, the correct next step is usually a written regulatory-perimeter opinion supported by the actual payment-flow diagram and draft agreements. It is risky to rely on a short description such as “we partner with a bank” or “we are only a gateway”.

5. Which authorisation category applies?

The appropriate category depends on the proposed service. The First Schedule to the National Payment System Regulations presently prescribes, among other categories:

These figures should be verified immediately before an application because prescribed fees, capital requirements and CBK practice may change. The category cannot be selected solely by reference to the lowest capital threshold; it must match the actual product and programme of operations.

6. What CBK will expect from an applicant

An application should be built around a coherent operating model. Under the Regulations, CBK’s review includes the safety and efficiency of the service, the applicant’s financial condition, the integrity and fitness of significant shareholders and management, governance, internal controls and capital.

A serious application workstream will typically include:

• proposed-name approval and the corporate structure;
• a three-year business plan and financial projections;
• a detailed programme of operations and end-to-end payment-flow maps;
• evidence of the applicable core capital;
• shareholder, director and senior-management fit-and-proper documents;
• governance, risk-management and internal-control frameworks;
• an operational AML/CFT and sanctions programme, not only a written policy;
• cybersecurity, access-control, incident-response and business-continuity arrangements;
• safeguarding, settlement, reconciliation and liquidity arrangements where applicable;
• customer terms, fee disclosures, complaints and error-resolution procedures;
• data-protection and confidentiality controls;
• material contracts with banks, processors, telecommunications providers, merchants and outsourced service providers; and
• a legal analysis showing how each party’s contractual role matches the transaction flow.

CBK may request additional information after receiving an application. The statutory process should therefore not be treated as a fixed 30-day approval timetable. A product launch should be planned around authorisation, not the other way round.

An authorisation is generally valid for twelve months and must be renewed. The Act and Regulations require a renewal application at least two months before expiry.

7. Why the perimeter decision should be made early

Unlicensed PSP business is not a technical defect that can safely be corrected after scale. Under section 12 of the National Payment System Act, conducting payment service provider business without authorisation is an offence punishable by a fine of up to KES 500,000, imprisonment for up to three years, or both. Regulatory directions and separate AML/CFT penalties may also arise depending on the breach.

There are also commercial consequences. A flawed licensing assumption can derail banking partnerships, investment due diligence, enterprise procurement and regional expansion. It may require expensive changes to settlement accounts, customer contracts, pricing, technical integrations and product branding.

Early advice is usually less costly because the business can choose deliberately between three paths:

1. apply for the appropriate authorisation;
2. redesign the product so that a licensed partner genuinely performs the regulated functions; or
3. obtain clarification on a genuinely borderline model before launch.

8. The practical next step

For most fintechs, the first deliverable should not be the licence application form. It should be a regulatory-perimeter memorandum based on the proposed transaction flow, contractual relationships and product interface.

That memorandum should identify the relevant licence category, any adjacent regimes, the functions that can or cannot be outsourced, required changes to the model, and a documentary roadmap for the CBK application. It should also flag data protection, AML/CFT, consumer protection, telecommunications, foreign-exchange, digital-credit and virtual-asset issues where they intersect with the product.

The decisive question is not whether the business looks like a technology company. It is whether, in substance, it performs a regulated role in moving, storing or processing value for others.

This article provides general information as at 12 August 2026 and does not constitute legal advice. Licensing outcomes depend on the precise product, transaction flow, contracts and current regulatory practice.