The Wrong Starting Point
Every time a central bank in Africa convenes a working group on open banking, someone in the room holds up PSD2 as the reference model. It is understandable — the European Payment Services Directive is the world's most mature mandatory open banking framework, it has a decade of implementation history, and it produced a functioning ecosystem of account information and payment initiation services across 27 member states.
The problem is not that PSD2 is a bad framework. The problem is that PSD2 was designed for a specific set of infrastructure assumptions that do not hold across most of Africa. When you transplant the framework without examining the assumptions underneath it, you end up with regulation that looks correct on paper and fails in practice.
This article is about those assumptions — and what African banks and regulators should build instead.
The Three Assumptions PSD2 Makes That Africa Cannot
Assumption 1: Near-universal bank account penetration.
PSD2's architecture assumes that the primary financial instrument a consumer holds is a bank account — an account at a regulated deposit-taking institution, subject to prudential oversight, with a stable account number and transaction history. In the EU, this is a reasonable assumption. Bank account penetration across member states exceeds 95%.
Across sub-Saharan Africa, the picture is different. The World Bank's Global Findex data puts account ownership at roughly 55% across the region — and that figure includes mobile money accounts, which function differently from bank accounts and are regulated under a separate framework in most jurisdictions. In some markets — Chad, South Sudan, rural Nigeria — bank account penetration among adults is well below 30%.
When PSD2-style open banking mandates that "banks must open APIs to third parties," it is implicitly designing for a world where banks are the primary financial relationship. In markets where the primary financial relationship is a mobile money wallet — M-Pesa in Kenya, MTN Mobile Money in Ghana and Cameroon, Airtel Money across East Africa — a bank-centric API framework misses the population it is supposed to serve.
Assumption 2: A functioning credit bureau infrastructure.
One of the primary value propositions of open banking in Europe is enabling better credit decisioning. Third-party lenders can, with customer consent, access transaction history from a bank account to underwrite credit more accurately than a traditional credit bureau score alone. This works in the EU because bank accounts are the primary store of financial history.
In Africa, the credit bureau infrastructure is incomplete at best. South Africa has a mature credit bureau ecosystem. Nigeria has the Credit Bureau Association of Nigeria and several licensed bureaux, but coverage of the informal sector is thin. Across East Africa, bureau data is partial, inconsistently updated, and frequently excludes mobile money transaction history — which is precisely where the financial behaviour of the un-banked and under-banked resides.
Open banking APIs that share bank account transaction data will improve credit decisioning for the banked population. They will do nothing for the 40–50% of the adult population whose financial life runs through a mobile wallet and whose creditworthiness is invisible to the formal credit infrastructure. This is not a minor gap — it is the gap that open banking is supposed to close.
Assumption 3: Regulatory enforcement capacity at EU standards.
PSD2 works in part because the European Banking Authority provides technical standards, national competent authorities have enforcement teeth, and firms are held to a consistent compliance baseline. The regulatory infrastructure to enforce a complex API regime exists and is well-funded.
This capacity varies significantly across African markets. Nigeria's CBN is a serious regulator with real enforcement capability. The Bank of Ghana, the Central Bank of Kenya, and the South African Reserve Bank have comparable institutional weight. But a large number of African central banks are operating with constrained capacity, incomplete supervisory technology, and limited ability to audit API security compliance at scale.
An open banking framework that assumes PSD2-level enforcement capacity will produce a framework that larger, well-resourced institutions comply with and smaller institutions ignore — creating a two-tier system that undermines the interoperability the framework was supposed to create.
Who Is Getting It Right
The African markets making real progress on open banking have not simply copied PSD2. They have built frameworks that are explicit about their own infrastructure constraints.
Nigeria is the continent's clear leader. The Central Bank of Nigeria's Open Banking Regulation, released in 2021, does not mandate participation on day one — it establishes the framework, defines the API taxonomy, sets the security standards, and creates a sandbox for testing. The CBN has signalled that participation may become mandatory if voluntary adoption is insufficient, which is the correct sequencing: build the standard, observe voluntary uptake, enforce if the market does not move. Nigeria's framework also explicitly addresses mobile money operators as participants, not an afterthought — reflecting the actual financial landscape rather than an idealised one. Live API rollouts were underway through 2025.
South Africa takes a principles-based approach that reflects its more complex regulatory environment. The Intergovernmental Fintech Working Group has developed a framework that does not mandate a single technical standard, but sets clear principles around consent, security, and consumer protection. This is less prescriptive than PSD2 or the UK's Open Banking Implementation Entity model, but it is arguably better suited to a market where major banks already have sophisticated API programmes and smaller institutions need room to reach compliance incrementally. South Africa's fintechs are already consuming bank APIs for corporate treasury and cash management use cases — the B2B layer is functioning while the consumer-facing framework matures.
Kenya has taken the most pragmatic approach of any market: it has not attempted to build a bank-centric open banking framework at all. Instead, the Central Bank of Kenya has focused on mobile money interoperability — ensuring that the dominant financial instrument (the M-Pesa wallet and its equivalents) can transact across networks and eventually across the bank-wallet boundary. The CBK's regulatory sandbox allows fintechs to test interoperability solutions in controlled conditions before full deployment. This is arguably the correct priority ordering for a market where 70%+ of the adult population transacts primarily through mobile money.
The Mobile Money Interoperability Question
Any honest conversation about open banking in Africa has to address M-Pesa. Safaricom's mobile money platform processes more transactions by volume than most of sub-Saharan Africa's banking systems combined. Its API — the Daraja API — is one of the most widely integrated financial APIs on the continent, used by tens of thousands of businesses for payment collection, disbursements, and B2B settlement.
The Daraja API is not open banking in the PSD2 sense. It is a proprietary commercial API that Safaricom exposes to third parties on commercial terms. There is no regulatory mandate to expose it, no standardised consent mechanism, and no third-party payment initiation in the PISP sense. What it has is near-universal adoption, developer familiarity, and genuine transaction volume.
Banks in East Africa that are building open banking strategies face a structural question: do you build a PSD2-style bank API framework that 30% of your market's population can access, or do you prioritise interoperability with the mobile money layer where the other 70% actually transact?
The right answer is both — but the sequencing matters. Banks that launch open banking APIs without a strategy for connecting to the mobile money layer are building for the banked minority while the unbanked majority remains unreachable. PAPSS (the Pan-African Payment and Settlement System) provides a cross-border layer for interbank settlement, but the domestic connectivity between bank accounts and mobile wallets is still handled through bilateral arrangements, ATM networks, and agent banking — not through standardised open APIs in most markets.
The banks that will win in open banking across East and West Africa are those that design their API architecture to speak both languages: the bank account world and the mobile money world. That means building API gateways that abstract across both rails, not API programmes that assume bank account primacy.
What Mid-Tier Banks Should Actually Build
A mid-tier bank in Nigeria, Kenya, Ghana, or Tanzania with 500,000 to 2 million customers is not going to build a PSD2-compliant AISP/PISP ecosystem by itself. It does not have the regulatory bandwidth, the developer relations budget, or the technical capacity to maintain a standards-compliant open banking infrastructure while simultaneously running its core banking transformation.
What it can build — and what will generate measurable revenue — is a layered API gateway strategy:
Layer 1: Regulatory compliance APIs. Build to whatever the CBN, CBK, or BoG framework requires. Do this correctly, do it once, do not improvise. The regulatory floor is non-negotiable and the cost of non-compliance exceeds the cost of getting it right early. Treat this as infrastructure, not product.
Layer 2: Commercial APIs for the B2B use case. Corporate treasury, supplier payments, payroll, receivables management — these are the use cases where mid-tier banks already have relationships and where API access creates genuine stickiness. Banks that expose clean, well-documented APIs for corporate cash management retain treasury customers who would otherwise move to a tier-1 bank with better technology. This layer generates revenue through transaction fees and relationship retention.
Layer 3: Mobile money connectivity. Every bank in a market with significant mobile money penetration needs an API strategy for the wallet layer. This means bilateral integration with the dominant mobile money operators in your market, not an open standard (those do not exist yet at scale). The goal is to give your corporate and retail customers the ability to move funds between their bank account and any mobile wallet in your market without friction. Banks that solve this become the settlement layer for the informal economy.
Layer 4: Fintech partner APIs. Selective, commercial partnerships with fintechs that build products your customers want but that you do not want to build yourself. Credit scoring providers, savings apps, insurance distribution platforms. Structure these as commercial API agreements with revenue sharing, not as open regulatory compliance. The PSD2 model of mandated free access to account data is not the right model for most African markets at this stage of ecosystem development.
The Revenue Model Question
PSD2 mandated that banks expose customer account data to licensed third parties at no charge. The logic was that reducing barriers to access would accelerate competition and innovation, which would generate revenue for banks through improved customer retention and new product development rather than data access fees.
That logic may work in a mature ecosystem with deep API consumption and established third-party revenue models. It does not obviously work in a market where the API ecosystem is nascent, fintech funding is constrained, and banks are simultaneously trying to fund core banking transformations.
The African markets that are moving fastest — Nigeria in particular — have not mandated free access at launch. The voluntary phase allows banks to explore commercial models for API access. This creates space for premium API tiers (higher rate limits, richer data sets, guaranteed SLAs) that can generate revenue while the regulatory framework for any mandated access layer is developed.
Mid-tier banks in African markets should resist pressure to replicate PSD2's "free by regulatory mandate" model before the ecosystem is ready to support it. A premium API programme that generates £200,000–£500,000 per year in direct API access revenue from fintech partners is not a consolation prize — it is a proof of concept for the commercial model that funds the infrastructure investment to support broader access later.
The Strategic Question for Bank Leadership
Open banking in Africa is not a compliance exercise with a five-year horizon. It is a structural decision about where your bank sits in the financial services value chain as the mobile money and fintech layers mature.
The banks that treat open banking as a technology project to be handed to IT will produce a compliant API portal that nobody uses. The banks that treat it as a product strategy — with commercial API tiers, explicit fintech partnership programmes, and deliberate mobile money interoperability — will define their competitive position in the ecosystem before the regulatory framework forces the decision.
PSD2 is a useful reference. It is not a template. The African context requires frameworks built from African infrastructure realities outward, not European assumptions inward.
Advising on open banking strategy or API programme design for an African financial institution? Request a consultation with Charles.
Charles leads Open Banking & Digital Strategy advisory at Aicura Consulting, specialising in API regulatory frameworks, open finance programme design, and digital strategy for African banks and financial institutions.