In October 2021, we initiated a wire transfer from a bank account in Nairobi to a supplier in Kampala. Five hundred kilometres. Two countries that share a border, a common language of commerce, and, at the time, an active free trade area under the EAC. The transfer was initiated on a Monday morning. It arrived Thursday afternoon. The sending bank charged us $18. A correspondent bank in London, yes, London, charged an additional £12. Total cost on a $500 equivalent transfer: north of 6%, once you fold in the FX spreads embedded in the exchange rates used at each hop.
Nobody told us London would be involved. There was no disclosure at point of initiation that said "your money will travel from Nairobi to the United Kingdom before arriving in Kampala." We discovered it only when we requested a full transaction trace from our relationship manager, who, to his credit, was as baffled as we were. He explained, with evident discomfort, that this is simply how correspondent banking works: neither his bank nor the receiving bank in Uganda had a direct settlement relationship, so the transaction had to route through an intermediary with whom they both had accounts. That intermediary happened to be headquartered in the City of London.
That experience did not make us angry. It made us pay close attention. Because if a straightforward B2B transfer between two major East African cities, both served by sophisticated banking systems, both signatories to regional trade agreements specifically designed to reduce friction, was routing through London and costing 6%, something was fundamentally wrong with the plumbing. Not the policy. Not the regulation. The plumbing.
That is the infrastructure problem. And it has been the infrastructure problem for twenty years.
The Scale Makes the Absurdity Harder to Ignore
Sub-Saharan Africa processed over $2 trillion in mobile money transactions in 2024 alone. That number has been growing at roughly 30% annually for the better part of a decade. It is not a niche. It is not an emerging market curiosity. It is one of the largest and fastest-growing payment ecosystems on earth, and it is built on the back of infrastructure that was designed for a completely different world.
SWIFT (the Society for Worldwide Interbank Financial Telecommunication) was founded in 1973. Its messaging protocols were designed to replace Telex for communicating payment instructions between correspondent banks in the United States and Western Europe. The assumptions baked into that design: that banks are large institutions with bilateral relationships, that transactions are batch-processed overnight, that settlement happens in days not seconds, and that the system primarily needs to serve the transactional needs of large corporations and wealthy individuals moving money between New York, London, Frankfurt, and Zurich.
None of those assumptions are wrong, exactly, for the world they were designed for. The problem is that we are still using the same infrastructure for a continent of 1.4 billion people, the majority of whom transact primarily via mobile phones, often in real time, often in small amounts, often across borders that were drawn by colonial administrators with no particular interest in commerce. SWIFT was built for a different world. We are still using it, and the cost is real and ongoing and falls disproportionately on the people who can least afford it.
Why Fragmentation Persists: The Structural Explanation
People who encounter the African payment infrastructure problem for the first time often assume it is primarily a political problem: the fragmentation is caused by governments not cooperating, or by regulatory capture by incumbents who benefit from the status quo. That explanation is too simple. The fragmentation has structural roots that would be hard to eliminate even with perfect political will.
The continent has 54 countries and 42 central banks. Each central bank is legally responsible for monetary stability within its jurisdiction and has its own regulatory framework for payment system participation. There is no common settlement currency: the closest thing to a regional reserve is the CFA franc in West and Central Africa, and even that covers only a subset of the continent. Cross-border settlement requires either a direct bilateral arrangement between two central banks, or an intermediary with existing relationships to both. For most country pairs, the intermediary path wins, and the cheapest intermediary with existing relationships to African central banks is typically a major international correspondent bank based in Europe or the US.
This is not a conspiracy. It is the equilibrium outcome of a system where building direct bilateral settlement infrastructure has high fixed costs and the transaction volumes between most African country pairs have historically been too low to justify it. The volumes are no longer too low, and intra-African trade has been growing steadily and the AfCFTA is starting to have measurable effects, but the infrastructure moves slower than the economics because the institutions that would need to build it are large, risk-averse, and dealing with a dozen other priorities.
The costs of fragmentation extend well beyond the transfer fee your relationship manager quotes you. There is settlement latency: T+3 for cross-border is still common across much of the continent, which means your FX exposure window is three business days on every cross-border trade. There is counterparty risk that multiplies with each correspondent hop. And there is compliance overhead that does not scale linearly with jurisdictions: a fintech operating in five East African countries is not dealing with 5x the compliance burden of a single-country operation, it is dealing with something closer to 5² because every country pair has its own rules about what information must accompany a cross-border payment, what reporting is required, and who bears responsibility for AML screening. A payment crossing from Kenya to Uganda to Tanzania is triple-screened, each screening applying a different ruleset. That cost, like the correspondent bank fee, lands on the end customer.
PAPSS Is Real Progress. Let's Be Honest About the Timeline.
The Pan-African Payment and Settlement System (PAPSS) is the most significant structural response to this problem that has emerged in a generation. It is a real-time, multi-currency payment infrastructure designed specifically for intra-African transactions, developed by Afreximbank in collaboration with the African Union and a growing number of central banks. It mandates ISO 20022 messaging, operates in local currencies without requiring USD conversion, and aims to eliminate the correspondent bank intermediary for intra-African payments entirely.
We have integrated with PAPSS in Hyperion-X. The technical integration works. The ISO 20022 implementation is solid, the settlement mechanics are well-designed, and the people building it are serious engineers solving a real problem. When a transaction goes through PAPSS between two connected countries, the correspondent bank disappears from the routing chain. The cost savings are immediate and substantial.
Here is where honesty requires some calibration: as of mid-2026, PAPSS covers six countries with meaningful real transaction volume. The goal is continent-wide coverage: 54 countries, all 42 central banks, intra-African settlement without a correspondent intermediary for any country pair. That is a real goal. It is also, in our realistic assessment, five to seven years away from full realization. Not two.
The reasons are not technical. The PAPSS technology works. The reasons are institutional: each central bank needs to sign agreements, implement the required connectivity, satisfy its own board and ministry of finance, manage the transition from existing correspondent relationships, and train the operational staff. That process does not go fast. The East African countries are generally ahead of West Africa, which is ahead of Central and Southern Africa. The technology is not the binding constraint. Institution-building always takes longer than engineers expect it to, especially when it involves central banks.
Africa Did Not Skip the Banking Era. It Invented a Better One.
There is a narrative in fintech circles, repeated so often it has calcified into received wisdom, that Africa "leapfrogged" traditional banking by going straight to mobile money. That framing is wrong in a subtle but important way. Africa did not skip the banking era. It invented a parallel financial system that is, in many respects, technically superior to what the banking era produced, and it did so by necessity rather than by design.
M-Pesa launched in Kenya in 2007. By 2010, it was processing more transactions by volume than the Kenyan banking system. By 2015, the dollar value of transactions through M-Pesa exceeded Kenyan GDP. Today, M-Pesa is the dominant payment rail for the majority of Kenyans. It is faster than any traditional bank transfer. It works on a feature phone. It is available at a kiosk in a village 200 kilometres from the nearest bank branch. It processes a transaction in seconds rather than days. By almost any metric that matters to a retail customer, it is a better product than a bank account.
The infrastructure problem is that M-Pesa is not ISO 8583. It is not ISO 20022. It does not speak the protocols that the global banking system speaks, because it was built independently of the global banking system, by people who were solving a different problem. M-Pesa is a proprietary REST API with its own authentication model, its own retry semantics, its own callback patterns, and its own concept of a transaction identifier. Every payment switch that treats M-Pesa as an edge case, a special integration bolted onto the side of a "real" payment system built around card rails and SWIFT messaging, is solving the wrong problem for Africa.
Mobile money is the mainstream. Card payments are the edge case. Any infrastructure that does not treat mobile money as a first-class citizen at the data model level, not as an adapter pattern over card rails but as a native protocol with its own message types, retry logic, and settlement semantics, is fundamentally misaligned with how Africa transacts. This is not a criticism of global payment infrastructure. ISO 8583 and ISO 20022 are excellent standards for the use cases they were designed for. The problem is that building African payment infrastructure by starting with those standards and adding mobile money adapters produces systems that are structurally misaligned with the transaction reality of the continent. You end up with a card-shaped hole where a mobile-money-shaped hole should be, and you spend the rest of your engineering life filling it with glue code.
We Did Not Set Out to Build a Payment Switch
The origin of Hyperion-X is not a strategic insight or a market analysis. It is a debugging session that went on for six months longer than it should have.
In 2022, we were building a custom banking system for a mid-tier bank client in East Africa. The requirements were straightforward: process card transactions via ISO 8583, process mobile money via the Daraja API, send interbank settlements via RTGS. Three integrations. We expected to wire them together in a few weeks and move on to the more interesting parts of the system.
What we found instead was that those three integrations were not just technically different: they were semantically different in ways that made them very hard to compose. ISO 8583 has a concept of a message type indicator that tells you whether you are looking at an authorization request, an authorization response, a reversal, or a notification. Daraja has STK pushes and callbacks and B2B transfers and C2B payments, each with different flows and response semantics. RTGS has its own message format, its own settlement windows, and its own reconciliation process. Writing code that understood all three, that could trace a transaction across all three systems, that could reconcile the settlement state across all three: that was not a few weeks of work. That was a year of work.
We delivered the system. Then the second client came to us with the same three integrations. Then the third. After the third time building the same bridge, we stopped and built it once properly. That is Hyperion-X. Not a grand vision for African payment infrastructure: a response to a concrete problem we kept getting paid to solve in a suboptimal way.
The CBDC Wildcard: Solving a Problem Nobody Has Yet
Nigeria launched the eNaira in October 2021. If you want to understand how not to launch a CBDC, the eNaira is an instructive case study. The UX was poor, merchant adoption was marginal, and, most critically, it offered no compelling reason for a Nigerian consumer to use it instead of the mobile money services they already had. By 2023, adoption was so low that the Central Bank of Nigeria made salary payments in eNaira mandatory for civil servants to generate any transaction volume at all. That is not product-market fit. That is a government mandating usage of a product people do not want.
Ghana's eCedi pilot has been more thoughtful. The design incorporated offline capability (the ability to transact without internet connectivity, using near-field communication) which addresses a real problem in a country where network coverage is not uniform. The Bank of Ghana's approach to merchant integration was more pragmatic, building on existing POS infrastructure rather than requiring new hardware. It is still a pilot, but it is a pilot that seems to have learned from the eNaira's mistakes.
Kenya is in the research phase, which is probably the right place to be. The Central Bank of Kenya has been measured in its approach, commissioning studies rather than rushing to launch, and the research has been appropriately skeptical about what problem a Kenyan CBDC would actually solve that M-Pesa does not already solve better. That is a fair question, and the answer is not obvious.
Here is the infrastructure question that keeps us up at night: when CBDCs arrive at scale, and they will because central banks are not going to voluntarily cede the payments market to private mobile money operators indefinitely, the interoperability problem becomes more acute, not less. A CBDC that does not interoperate with M-Pesa is a government-issued solution to a problem M-Pesa already solved. It will either fail in the market (like the eNaira) or be made mandatory (which is not a payment product strategy, it is a currency control strategy).
The payment infrastructure that sits between CBDCs and mobile money networks, one that can receive a CBDC payment, settle it to a mobile money wallet, and return a confirmation in real time without the end user caring which rail their money traveled on, does not fully exist yet. That is a real engineering problem and an open market opportunity, and it is one of the reasons we are investing in Hyperion-X's protocol abstraction layer now, while the CBDC standards are still being written.
What Genuinely African Payment Infrastructure Looks Like
Not a copy of SWIFT with African branding. That sentence sounds obvious but it rules out most of what gets funded and built.
Genuinely African payment infrastructure is mobile-first at the protocol level, not card-first with mobile adapters. The native transaction type is a mobile money transfer. Card payments are supported, because cards exist and businesses need to accept them, but the data model does not bend the mobile money transaction into card-shaped fields. It models both natively and translates between them when necessary.
It is real-time by default, not batch. The reason legacy banking runs batch processes is not that batch is better: it is that the computing resources to do real-time processing of every transaction were not available when the systems were designed in the 1970s and 1980s. Those constraints have not existed for twenty years. A payment system designed today for African markets has no excuse for T+3 settlement. M-Pesa does not take three days. Your interbank settlement should not take three days either.
It is multi-currency at the data model level. Not a USD-centric system with currency conversion bolted on. Not a system where every cross-border transaction implicitly assumes a USD intermediate. A system where KES, UGX, TZS, ETB, and NGN are first-class types, where exchange rates are stored with their provenance and timestamp, where the settlement currency for a given country pair is a configuration parameter rather than a hardcoded assumption.
It is offline-capable for last-mile transactions. Significant portions of East and West Africa have intermittent connectivity. A payment infrastructure designed for the continent as it actually exists, not as it exists in Nairobi's CBD or Lagos Island, needs to handle the case where a farmer paying for inputs cannot complete the transaction because the cell tower is down. This is a genuinely hard engineering problem, and most payment infrastructure simply defers it. That is not good enough.
We are building toward this with Hyperion-X. We are not there yet on every dimension. The offline capability is still on the roadmap. The multi-currency native model is implemented. Mobile money as a first-class protocol is implemented. Real-time settlement between connected participants is implemented. The distance between where we are and where continent-scale infrastructure needs to be is still substantial, and we are honest with ourselves and our customers about that gap.
What we are not doing is building for the continent as it was thirty years ago, or as it is imagined to be by engineers in San Francisco who have read about Africa but never processed a payment in it. The gap that matters is not between Africa and some imagined global best practice. The gap is between the infrastructure that currently exists and the infrastructure that the transaction reality of this continent actually requires. Closing that gap is the work. It is not glamorous work, much of the time. But it is the work that matters.
If you are building financial infrastructure for African markets and want to talk through what we have learned, on production systems, with real money, after years of shipping and debugging and occasionally being embarrassed by our own assumptions, we are reachable. This is a problem that benefits from more people working on it seriously.