You’d think sending money from one African country to another would be straightforward, but it often takes a strange route. The funds move from a local bank to a correspondent bank, then offshore to clear in dollars (USD) or other foreign currencies, and only then find their way back into the destination African country. This is how most cross-border payments in Africa currently work.
The Pan-African Payment and Settlement System (PAPSS) steps in to change part of this journey for payments within the continent. While there is still room for improvement, it makes regional settlement smarter and more direct.
For developers working in fintech and building payment platforms across Africa, the key is understanding what PAPSS changes in practice. Specifically, where it sits in the payment stack and when other rails are the better choice.
In this guide, we will break down what PAPSS changes, what it leaves untouched, and how developers should think about it when designing systems for African cross-border payments.
Before diving in, let’s take a closer look at how cross-border transactions work in Africa.
How Cross-Border Payments in Africa Work
Payments across African borders are rarely a single, straightforward process. They rely on the correspondent banking model. This means that when a business in Lagos sends money to a supplier in Nairobi, the payment leaves Nigeria’s domestic rail, moves to a Nigerian correspondent bank, gets converted to USD or EUR, settles through an offshore clearing system, converts again to KES, passes through a Kenyan correspondent bank, and finally reaches the supplier’s account through Kenya’s domestic rail. These are examples of the cross-border transactions and cross-border trade that PAPSS aims to simplify.
This setup works, but it comes with overhead. Developers building on this framework deal with unpredictable timelines, complicated fees, and integration headaches from stitching together multiple APIs or legacy interfaces.
Why Funds Leave the Continent
The root issue is currency convertibility and trust. Most African currencies do not have a direct clearing relationship with each other or a shared settlement layer. Without this, banks rely on major currencies like USD or EUR as intermediaries. Most of these clearing systems sit offshore, which is why cross-border payments follow this route. This reliance on foreign currencies increases costs and complexity for African businesses and financial institutions.
This workflow is not inefficient by accident. It exists as a workaround for limited currency convertibility and the historical dominance of correspondent banking networks built around global reserve currencies. It is also simpler and less risky for banks to centralize foreign exchange and settlement through intermediaries that already handle USD and EUR clearing at scale.
Why Settlement Takes Days
Settlement delays stem from the need to move funds through multiple intermediaries operating in different time zones and regulatory environments. A payment sent from Kenya may be batched by the bank or payment service provider in the morning, since most banks wait until a threshold amount is reached. It might not clear through London until later in the day, then move onward to Ghana. The beneficiary may not see the funds until the next business day, or later if compliance checks fail.
The actual data transmission takes minutes or hours. The real delay comes from operational processes such as batching, validation checks, compliance reviews, and handoffs between intermediaries. Reconciliation issues and resolving discrepancies between what was sent and what was received can extend timelines even further.
Where Costs and Failures Occur
A typical correspondent banking flow introduces costs at every stage. The originating bank charges an outgoing wire fee, the correspondent bank charges a processing fee, and the receiving bank charges an incoming wire fee. In addition to that, banks apply an FX spread that varies by corridor, liquidity, and counterparty risk. This spread covers liquidity and minimizes risk costs. While this makes sense from the bank’s perspective, these charges compound quickly for customers.
Failures can also happen at multiple points. Insufficient correspondent account balances, compliance holds, rejected SWIFT messages, and FX rate disputes are common. Each of these usually requires manual intervention and can add days to resolution.
The end result is that intra-African payments often cost more than comparable transfers in other regions, and they take days instead of minutes.
What is PAPSS?
PAPSS is a regional clearing and settlement layer operated with participation from African central banks. It sits between domestic payment systems and handles cross-border settlement in local currencies. Operated by Afreximbank in partnership with the African Union and the African Continental Free Trade Area (AfCFTA), it connects sender and beneficiary central banks and financial institutions across participating countries. As of early 2026, it covers over 18 countries, including Morocco, Algeria, Nigeria, and Ghana, with over 150 commercial banks and 14 switches integrated.
At its core, PAPSS enables settlement for intra-African payments in local currencies without routing everything through foreign intermediaries. It acts as a bridge between the sending and receiving institutions by validating payment instructions, handling netting, and settling net positions among the involved central banks. One way to think about it is as a continental middleware layer. A local bank sends a payment in Naira, PAPSS processes it, and the recipient receives Cedis instantly or near-instantly, all without requiring USD as an intermediary settlement currency.
PAPSS doesn’t replace national rails like Nigeria's NIBSS or Kenya’s PESALINK. Instead, it creates new opportunities by providing an alternative settlement path for intra-African payments that supports local currency clearing.
How PAPSS Changes the Settlement Process
The biggest change PAPSS introduces is where and how settlement happens. Local currency settlement now takes place within Africa. Instead of converting to USD or EUR, sending funds offshore, and converting again on arrival, payments can be cleared and settled regionally without requiring an intermediary reserve currency.
This shift changes several practical aspects of how cross-border payments behave under the hood. It affects how currencies are handled, how liquidity is managed, and how much reliance there is on offshore intermediaries. In practice, this shows up in three key ways:
- Local Currency Clearing: Participating institutions can clear obligations in local currencies through the regional transfer system without needing a foreign intermediary. This reduces FX steps for eligible corridors and simplifies treasury operations.
- Net Settlement Across Participants: Instead of settling every transaction individually, PAPSS supports multilateral net settlement among participating institutions. This lowers liquidity pressure and reduces the amount of prefunding required.
- Reduced Offshore Dependencies: By keeping settlement regional, PAPSS reduces reliance on offshore correspondent banks for intra-African payments. It doesn’t remove correspondent banking entirely, but it changes when and where it’s needed.
PAPSS also aims to support increased African trade under the AfCFTA by streamlining these processes.
While PAPSS brings these advantages, it also raises a common question. What is the actual difference now between local settlement and regional settlement?
What Moves Locally vs Regionally
Domestic payment rails haven’t changed. If money moves within Nigeria, it still goes through NIBSS. Global transactions, such as Nigeria to China, still rely on correspondent banks and dollar clearing.
Regional transactions, such as Nigeria to Kenya, Ghana to South Africa, or Egypt to Morocco, can now settle through this regional infrastructure. This is where PAPSS operates. Everything before settlement, like payment initiation and domestic processing, and everything after settlement, like final credit to the beneficiary, continues to run on existing domestic systems.
Now that we have walked through how PAPSS changes settlement behind the scenes, the next question is how this compares to the system developers have been building around for years.
For most cross-border payments in Africa today, correspondent banking still sits at the center of the flow because it is familiar, widely adopted, and deeply embedded in bank infrastructure. It’s also a major reason cross-border transfers feel slow, expensive, and unpredictable for both users and developers.
To understand the real impact of PAPSS, it helps to compare it directly with correspondent banking and see where the differences show up in daily payment flows, settlement timelines, and developer experience.
PAPSS vs Correspondent Banking for Cross-Border Payments
It’s tempting to see PAPSS as a full replacement for correspondent banking, but that assumption often leads to architectural mistakes. Understanding the differences between PAPSS and correspondent banking helps teams make better design decisions. They solve similar problems, but they operate very differently.
| Feature | PAPSS | Correspondent Banking |
|---|---|---|
| Settlement Currency | Local African currencies | Typically USD, EUR, GBP |
| Intermediaries | Regional layer system coordinated through participating central banks | Multiple (originating bank → correspondent → clearing house → correspondent → beneficiary) |
| Speed | Hours to same day (depending on window) | 1-5 business days |
| Cost Drivers | Central bank levies, single FX conversion | FX spreads, correspondent fees, lifting fees |
| Failure Modes | PAPSS system issues, domestic rail failures | Correspondent account problems, SWIFT rejections, compliance holds |
| Coverage | PAPSS member countries only | Global reach |
The key point is that PAPSS reduces reliance on correspondent banking for intra-African corridors, but it does not remove correspondent banking in all cases.
At a technical level, the differences are straightforward: fewer intermediaries, faster settlement, and more predictable outcomes. The real impact, however, shows up in what developers can build on top of this infrastructure.
Once settlement becomes faster and more reliable, entirely new payment experiences become possible. This is where PAPSS moves from being background infrastructure to an actual enabler for cross-border products.
What PAPSS Enables for Developers
From a developer’s perspective, PAPSS is interesting because it opens up new options rather than forcing you to rewrite existing workflows. The benefits show up clearly in a few practical use cases.
Faster regional settlement allows you to offer same-day settlement for B2B payments between participating countries. For example, a payroll platform paying remote workers across West Africa can credibly promise that a payment sent on Thursday morning arrives Thursday afternoon, rather than the following week.
Lower FX complexity also matters for intra-African flows. Instead of quoting a naira-to-dollar rate and then a dollar-to-shilling rate, with spreads applied at each step, you can manage local currency pairs directly or rely on centralized regional liquidity. This simplifies pricing logic and reduces hedging complexity on your books.
New routing options make smarter payment orchestration possible. You can design routing logic that selects between correspondent rails for global reach and regional rails for speed and cost. A fintech facilitating merchant payouts can route Egyptian payments to Nigerian vendors through PAPSS, while still using SWIFT for payments to suppliers in Germany.
One important thing to note is that PAPSS improves settlement behind the scenes without changing the front-end payment experience. Your users still initiate payments the same way. What changes is how quickly and efficiently those payments settle after the transaction is submitted.
It may be tempting to see PAPSS as a silver-bullet solution that requires a full rewrite of your payments stack. That’s not how it should be approached. A better mental model is to treat it like an additional routing layer in your payment network that supports your existing system rather than replacing it.
Keep the following in mind when deciding how to use PAPSS:
- Domestic Rails are Still Required: PAPSS handles the cross-border settlement leg. Final settlement still runs through NIBSS, KEPSS, or the relevant real-time gross settlement system in the destination country. This means you still need integrations with local banks and mobile money operators.
- Global Corridors Still Rely on Correspondent Banks: Payments from Nigeria to the UK or Kenya to India do not use PAPSS. Those flows still go through traditional correspondent routes in London or New York. Still keep SWIFT handling as part of your stack.
- Consumer Payment UX Remains Unchanged: PAPSS is a settlement layer, not a consumer-facing product. Your mobile app flows, QR codes, authentication, and checkout experience stay the same. The change happens after the user clicks “Pay.”
How to Design a System That Uses PAPSS
The next obvious question is how to design PAPSS into your existing architecture. If your system already supports asynchronous settlement, multiple corridors, and more than one payout rail, adding this regional layer becomes a routing decision rather than a rewrite. The key principle is to treat PAPSS as one settlement option among others, not as a special workflow with its own state machine.
Treat PAPSS as a Settlement Option, Not a Payment Type
PAPSS does not change your payment initiation flow. You do not need to expose an option like “Pay with PAPSS” at checkout. That usually creates confusion, since users should not have to care about the settlement rail behind the scenes.
Instead, users initiate payments the same way they always have. Your system decides how the payment settles based on corridor, currency, and availability.
Architecturally, this logic belongs in the settlement layer, not in the payment intent model. The payment intent captures what the user wants to do, such as sending 10,000 naira to Kenya. The settlement layer decides whether the intent routes through a correspondent bank in London or through the regional switch.
Route Settlement Based on Corridor and Currency
Eligibility depends on the specific corridor and the currencies involved. Not all African countries participate yet, and even among participants, not every currency pair is supported for direct settlement.
Your routing logic should rely on configuration, not hard-coded rules. Maintain a table that defines supported corridors, currencies, liquidity thresholds, and preferred rails. When a payment enters the system, query this configuration to select the optimal path. If the regional rail offers better speed and cost for Nigeria to Kenya, use it. If the corridor is Nigeria to China, fall back to correspondent banking.
Parallel Settlement Paths, Same State Machine
Avoid creating PAPSS-specific states in your payment state machine. A payment initiated through any rail should move through the same lifecycle states, such as pending, processing, settled, or failed.
Whether a payment settles via PAPSS or through correspondent banking, the state transitions remain the same. Only the settlement rail changes. This keeps the system simpler and easier to maintain over time.
Fallback Strategies When PAPSS Is Not Available
Like any infrastructure, PAPSS has dependencies. Whether it can be used at any given time depends on corridor participation, currency support, liquidity availability, and operational uptime.
Your system should handle these cases explicitly. If the regional rail returns a timeout or rejection, your orchestrator should automatically fall back to correspondent banking, where possible, or queue the transaction for manual review. These fallbacks should be observable so your operations team knows when the system is running on backup rails, since cost and settlement timelines change.
Reconciliation and Finality with PAPSS
PAPSS operates with settlement windows, which means settlement is not always immediate. The system may run multiple settlement cycles per day, and finality only arrives when participating central banks confirm the debit and credit entries.
Design your ledger to wait for settlement confirmation events. Update internal balances and notify beneficiaries only after you receive a confirmation webhook or a successful polled response. Avoid crediting accounts based solely on payment submission acknowledgments.
Account for idempotency as well. Retries caused by network timeouts should not result in double settlement or duplicate ledger entries.
Add Observability to Your Cross-Border System
Because PAPSS spans multiple countries, central banks, and institutions, visibility becomes even more important. Track settlement latency by rail, fallback frequency, and failure rates by corridor. These metrics help you understand where the system performs well and where it struggles.
Build dashboards that show this data in near real time so that when the regional rail slows down or becomes unavailable, you know before your support queue fills up.
Wrap Up
PAPSS is an infrastructure built to simplify regional settlement across eligible African corridors. When used correctly, it reduces reliance on offshore correspondent banks, speeds up settlement timeline for intra-African payments, and lowers FX complexity.
Developers who understand where this regional layer fits, treat it as one rail among many, and maintain strong observability can build more resilient cross-border payment systems for Africa. The goal is to keep and transfer money securely within the continent when possible, and still connect seamlessly to global rails when needed.
Irrespective of the role you play in the payment flow, it is important to recognise that PAPSS introduces its own operational complexity and implementation overhead. Working across corridors still requires coordination around compliance, liquidity, and integration. This is where Flutterwave adds value. Operating across multiple African and international markets, they help reduce the overhead involved in meeting regulatory requirements, managing integrations, and running cross-border payments at scale.
Top comments (0)