E-money licensing in Africa: what regulators ask for

Before a single customer can hold e-money in your wallet, a central bank has to agree that you can be trusted with it. Licensing is usually the longest step in launching a mobile money service, and the one where preparation pays off most. This guide explains how e-money regulation works across Africa, the licensing models regulators use, what reviewers actually examine, and how to prepare your technology so it becomes evidence in your favour rather than a list of open questions.

This article is a practical overview, not legal advice. Rules change and every regulator has its own requirements; always confirm the current position with the central bank and qualified local counsel.

Why e-money is regulated at all

When a customer puts cash into a wallet, they are trusting the provider to give it back on demand. E-money regulation exists to make that trust safe. Regulators care about five things above all:

1. Safeguarding: customer funds must be backed one-to-one by money held in trust, separate from the provider's own money.
2. Integrity of the system: transactions must be accurate, final and auditable, and the system must be resilient.
3. Financial crime: KYC, anti-money laundering and counter-terrorist financing controls must work at scale.
4. Consumer protection: transparent fees, dispute resolution, data protection and fair treatment.
5. Competition and interoperability: increasingly, regulators want wallets to connect to each other and to banks.

Everything in a licence application maps back to one of these.

The three regulatory models

Across the continent, regulators have taken three broad approaches to who may issue e-money:

The model decides your route. In a non-bank-led market, a fintech or telco can apply directly. In a bank-led market, your strategy starts with finding the right bank partner.

A snapshot of selected African frameworks

The detail differs from country to country, but a few examples show the range:

• Kenya: the Central Bank of Kenya authorises payment service providers, including e-money issuers, under the National Payment System Act (2011) and the National Payment System Regulations (2014). Customer funds are held in trust accounts at banks.
• Nigeria: the Central Bank of Nigeria licenses mobile money operators and other payment service categories, and in 2018 introduced payment service banks, a restricted banking licence aimed at financial inclusion. The CBN also defines a three-tier KYC framework for accounts.
• Ghana: the Bank of Ghana issues electronic money issuer licences to non-banks and regulates payment services under the Payment Systems and Services Act, 2019 (Act 987). Ghana has also required providers to share interest earned on trust balances with customers.
• Uganda: the Bank of Uganda licenses payment service providers and issuers of e-money under the National Payment Systems Act, 2020.
• Tanzania: the Bank of Tanzania licenses e-money issuers under the National Payment Systems Act (2015) and its e-money regulations. Tanzania was also an early mover on wallet-to-wallet interoperability.
• WAEMU (West African Economic and Monetary Union): the BCEAO regulates electronic money institutions across its eight member states, allowing licensed non-bank issuers alongside banks.
• Ethiopia: a 2020 directive from the National Bank of Ethiopia opened payment instrument issuance to non-bank companies, and a telecom-run wallet launched in 2021.
• Egypt: mobile wallets are bank-led; telecom operators offer wallets in partnership with licensed banks.

The direction of travel is consistent: more regulators are opening e-money to non-banks, formalising tiered KYC, pushing interoperability and paying closer attention to consumer outcomes and operational resilience.

What a licence application usually contains

Requirements vary, but most applications cover the same ground:

• Corporate information: incorporation documents, shareholding, beneficial owners, audited financials.
• Fit and proper assessments of directors, shareholders and senior managers.
• Capital: minimum paid-up capital and, often, ongoing capital requirements.
• Business plan: products, target customers, projections, fee structure and distribution strategy.
• Safeguarding arrangements: trust deed, trustee, custodian banks and how funds will be reconciled daily.
• Risk management framework: operational, liquidity, credit (if any), fraud and technology risk.
• AML/CFT policies: KYC tiers, customer risk rating, monitoring rules, sanctions screening, reporting to the financial intelligence unit.
• Agent management: selection, due diligence, training, monitoring and termination.
• Consumer protection: fee disclosure, complaint handling, dispute resolution and data protection.
• Technology: system architecture, security controls, hosting and data location, business continuity and disaster recovery, third-party dependencies, and often an independent system audit.
• Outsourcing: contracts with technology providers, including audit rights for the regulator.

What reviewers look for in your technology

Technology sections are where many applications stall, because reviewers ask precise questions and vague answers generate rounds of follow-up. Prepare concrete evidence for each of these:

Ledger integrity

Can you prove, at any moment, that the total of all customer wallets equals the funds in trust? A double-entry ledger in which every transaction posts balanced debits and credits, and a daily reconciliation against bank statements, answers this directly. Show the reconciliation report, not just the policy.

Transaction finality and reversals

How are failed and mistaken transactions handled? Reviewers want to see that nothing is ever deleted, that reversals are controlled and approved, and that the audit trail links every reversal to its original transaction.

KYC tiers and limits

How are customers onboarded at each tier, which limits apply, and how are limits enforced in real time? A configurable tier model, as described in KYC tiers a regulator accepts, with limits enforced by the ledger rather than the app, is strong evidence.

Monitoring and reporting

Which rules run, who reviews alerts, and how quickly? Can you produce the regulator's periodic returns directly from the system?

Security

PINs, encryption in transit and at rest, access control in the back office, maker-checker on sensitive actions, device binding, penetration testing, and signed webhooks for partner integrations.

Resilience

Uptime targets, backups, a tested disaster recovery plan, and what happens to customer funds and data if the technology provider fails.

Data location and ownership

Where customer data is hosted, who can access it, and whether you own it. Many regulators prefer or require in-country hosting for core financial data, and want the licensee, not a vendor, to control it.

Why a working platform speeds up approval

Regulators are more comfortable approving what they can see. An applicant who can show a live sandbox, walk the reviewer through onboarding a customer at each KYC tier, perform a transfer and a reversal, and print the reconciliation report is answering a dozen questions at once. It also demonstrates operational readiness: that you can run the service on day one, not only describe it.

This is one practical reason many new licensees use a proven white-label platform. The controls regulators ask about already exist, are documented, and can be demonstrated in a real system under the applicant's own brand and tenant. See white-label vs. build for the full comparison.

Life after the licence: ongoing obligations

Approval is the start of supervision, not the end. Expect:

• Periodic returns on customers, agents, transaction volumes and values, trust balances and complaints.
• Daily safeguarding reconciliation, with escalation rules for any difference.
• Suspicious transaction reports and responses to information requests from the financial intelligence unit.
• Change notifications or approvals for new products, tariffs, significant system changes and outsourcing arrangements.
• Onsite inspections covering compliance, technology and agent management.
• Incident reporting for outages, breaches and major fraud events.

Build these into the platform and the operating calendar from day one. A report generated automatically every month is far cheaper than a scramble every quarter.

Common reasons applications are delayed

1. Safeguarding arrangements not finalised with the trustee and custodian banks.
2. Technology documentation that describes intentions rather than an existing system.
3. No clear ownership or control of customer data when a vendor hosts the platform.
4. Agent management policies without the tools to enforce them.
5. AML monitoring rules that are generic rather than tailored to mobile money typologies.
6. Business continuity plans that have never been tested.

Preparing a technology evidence pack

Reviewers respond best to concrete evidence. Assemble a pack before you submit, and keep it current through the review:

A typical application timeline

Every regulator is different, but applications tend to move through the same stages:

1. Pre-application engagement: an introductory meeting with the central bank to present the business and understand expectations.
2. Submission of the full application with supporting documents and fees.
3. Completeness review: the regulator checks that everything required is there and asks for missing items.
4. Substantive review: detailed questions on governance, risk, AML, technology and the business plan, often in several rounds.
5. Onsite or system demonstration: reviewers see the platform and the operation.
6. Approval in principle, often with conditions such as capital injection, final hires or a system audit.
7. Final licence once conditions are met, sometimes followed by a restricted pilot period.

The fastest applications are those where the answers already exist: a live system, documented controls, and a team that can explain both.

Working with your technology provider on the review

If you use a platform provider, involve them early. A good provider will:

• supply standard documentation on architecture, security, ledger design and controls;
• join technical sessions with the regulator when needed;
• support independent audits and penetration tests on your deployment;
• deploy a dedicated environment under your name so the regulator sees your service, not a shared demo;
• agree in writing that you own your data and that the regulator can access your systems.

Partnering with a bank instead

If your own licence is not the right first step, partnering with a licensed bank can get you to market faster. The bank holds the licence and regulatory accountability; you bring distribution, product and customer focus. Expect the bank to require the same controls a regulator would: ledger integrity, KYC, AML monitoring, security and reporting. A platform that already meets those standards shortens the bank's due diligence as much as a regulator's review.

Consumer protection in detail

Consumer protection has moved from a paragraph in the application to a supervisory priority. Regulators increasingly expect:

• Fee transparency: the full tariff published, and the fee shown before each transaction is confirmed.
• Clear terms in plain language and in local languages.
• Complaint handling with defined response times, escalation to the regulator, and records of every complaint.
• Mistaken transfers: a documented process for recovering funds sent to the wrong recipient.
• Dormant accounts: rules on notifying customers and handling unclaimed balances.
• Data protection: consent for data use, security of personal data, and customers' rights to access and correct their information.
• Accessibility: services usable by customers with basic phones and limited literacy.
• Fair treatment in credit where the wallet offers loans, including disclosure of the total cost of credit.

Build these into the product rather than the manual: fee display before confirmation, receipts for every transaction, a complaints log with timestamps, and data-access controls in the back office. When the regulator asks how you treat customers, the system should answer.

More pitfalls reviewers flag

• Generic policies. Documents copied from another market, with the wrong laws and thresholds, signal that the applicant does not understand the local rules.
• Unfunded plans. Business plans that assume rapid growth without the capital to support it raise doubts about viability.
• Weak governance. Boards without independent members or relevant experience are a frequent reason for delays.
• A platform that cannot demonstrate controls. Regulators increasingly ask to see limits, audit trails and reports working, not just described.

Key terms in e-money regulation

Frequently asked questions

Can a fintech issue e-money in Africa without being a bank?

In many markets, yes, under an e-money or payment service licence. In bank-led markets, a fintech partners with a licensed bank.

Where must customer funds be held?

Typically in trust or safeguarding accounts at licensed banks, separate from the provider's own funds and matched one-to-one with e-money in circulation.

Do regulators require local hosting?

Many prefer or require that core customer and transaction data be hosted in the country, or at least accessible to the regulator on demand. Check the data protection and payment regulations in your market.

Is a technology audit required?

Often, yes: an independent review of the system's security, controls and resilience before launch, and periodically afterwards.

Can one platform serve several countries?

Yes, if it supports separate tenants, currencies, languages and rails per country, so each licence has its own ledger, data and reporting.

---

PesaBridge is built for regulated operators: a double-entry ledger with daily reconciliation, configurable KYC tiers and limits, AML screening hooks, a single reversal engine, maker-checker controls, signed webhooks and your own per-operator deployment and database. See security and compliance or request test access to walk a reviewer through the real system.