Instant payments are quietly rewiring MENA finance. Egypt's InstaPay moves money between bank accounts in seconds, Saudi Arabia's sarie and Jordan's CliQ do the same, and the UAE launched Aani to consolidate its instant rails. Meanwhile, much of the retail economy in the Maghreb still runs on cash, with wallets like Tunisia's D17 pushing at the edges. If you build financial software for the region, you are not integrating a payment API. You are integrating a dozen rails with different message formats, settlement rules, and certification regimes — and the integration work is systematically underestimated.
This is a field guide to the rails and, more importantly, to the engineering work around them that nobody puts in the first estimate.
The rails, country by country
- ▸Egypt: InstaPay, launched on the Instant Payment Network under the central bank, brought real-time account-to-account transfers to a huge, previously cash-heavy market. Alias-based addressing (mobile numbers) drove consumer adoption fast.
- ▸Saudi Arabia: sarie provides instant payments on ISO 20022 messaging, sitting alongside the mada card scheme; the ecosystem is tightly certified through Saudi Payments under SAMA oversight.
- ▸Jordan: CliQ, operated under JoPACC, offers instant transfers with aliases and has become the reference implementation for smaller markets in the region.
- ▸UAE and Bahrain: the UAE's Aani and Bahrain's Fawri+ deliver instant rails in markets that already had dense card and wallet coverage.
- ▸Tunisia: the picture is domestic cards through the national switch, the postal D17 wallet with a large reach through the post office network, bank wallets, and persistent cash dominance. Mobile-money-style adoption is real but uneven, and international acquiring remains a pain point for local merchants.
The strategic read: account-to-account instant payments are becoming the default rail for domestic transfers region-wide, while cards keep e-commerce and cross-border. Any product roadmap that assumes card-first economics everywhere will misprice half the region.
ISO 20022 helps less than you hope
Most of the newer schemes speak ISO 20022, and that is genuinely good news: one message grammar, rich structured fields, sane character encoding. But ISO 20022 is a vocabulary, not a contract. Every scheme publishes its own usage guide restricting which messages, which fields, and which code lists apply — and two pacs.008 implementations can disagree on everything from remittance information length to how return flows work. Treat each scheme as its own integration that happens to share a dialect. Build your internal canonical payment model once, and write per-scheme adapters, exactly as you would for invoice formats.
The work nobody budgets for
- ▸Certification is a project, not a formality: schemes and central banks require conformance testing, often with scheduled slots and re-certification when they update message versions. Put it on the roadmap with an owner and calendar time.
- ▸Sandbox fidelity is uneven: sandboxes frequently cannot simulate timeouts, partial failures, or return flows. Write down every behavior the sandbox cannot produce; that list is your production risk register.
- ▸Reconciliation is a first-class subsystem: real-time confirmation does not eliminate end-of-day settlement files, and the two views will occasionally disagree. You need automated matching, a break queue, and an operations runbook before launch, because the first mismatch will arrive in week one.
- ▸Model the unknown state explicitly: instant rails have timeouts, and a timeout does not mean failure — the transfer may have completed. Payment state machines need an in-flight/unknown state, an inquiry mechanism, and idempotency keys on every submission so retries cannot double-pay.
- ▸Webhooks are not a transport guarantee: signed callbacks get lost, delayed, and replayed. Poll as a backstop, verify signatures, and make every handler idempotent.
Open banking is arriving, unevenly
Bahrain moved first with central bank open banking rules; Saudi Arabia followed with SAMA's Open Banking Framework, phasing account information services ahead of payment initiation; the UAE is building an open finance regime under its central bank. Egypt, Morocco, and Tunisia are at earlier stages. For builders, the practical posture is an abstraction layer over per-country connectors, with no expectation of a PSD2-style single market any time soon. Where regulated APIs do not exist yet, resist screen-scraping shortcuts: the regulatory direction across the region is clearly toward licensed access, and products built on scraping inherit both fragility and licensing risk.
A pre-integration checklist
1. Obtain the scheme's local usage guide and certification requirements, not just the ISO 20022 base specs. 2. Prototype against the sandbox, then enumerate everything the sandbox cannot simulate. 3. Design the reconciliation pipeline and break-handling workflow before polishing the happy path. 4. Model payment states explicitly, including unknown, and wire idempotency keys end to end. 5. Budget calendar time for certification and for re-certification on scheme updates. 6. Settle the FX and settlement-currency questions up front for anything cross-border.
The reward for doing this properly is substantial. Instant account-to-account rails carry lower fees than cards, settle faster, and open products — payouts, collections, embedded finance — that were structurally awkward before. The regional trajectory is more rails, more aliases, more open APIs, and gradually more interconnection. Teams that build the canonical-model-plus-adapters architecture now will add each new country as an adapter; teams that hard-wire their first scheme will rebuild from scratch, at exactly the moment the market opportunity is largest.