The Central Bank has set limits on how much of Nigeria's payment market any single company can control. Most of the headlines went to the giants, and we covered that decision from their side, as a business-model call, not just a compliance cost. But the new rules reach past their boardrooms. They stop the biggest operators from controlling both sides of a payment at once, issuing the cards people pay with and processing payments for merchants, and they force those operators to disclose who really owns them. If you are a customer of these services, a developer building on their APIs, or a smaller partner riding their rails, the ground is shifting under you too.
One caveat before the specifics: the effects below are reasoned, plausible consequences, not measured outcomes, and no one can tell you exactly how a particular provider will respond. Treat them as a map of what to watch, not a forecast.
If you are a consumer
The caps stop any single operator from dominating both sides of the rail at once. Over time, forced separation like this tends to open room for more competitors and more choice, which usually works in your favour on price and service. That is the upside worth being optimistic about.
The honest caveat is short-term friction. As providers restructure to comply, you may see a product folded, a service moved to a different company, or a familiar brand change hands. It is unlikely to be dramatic for most people, but if a wallet or card you rely on announces changes over the next year, this is the backdrop.
If you are a developer integrating payment APIs
Your dependency map just became more important. When operators split or restructure business lines, which provider offers which capability can move. An acquiring feature you depend on today might sit with a different licensed entity tomorrow. Two practical responses.
- Build for portability. Isolate provider-specific code behind your own interface, so swapping a provider is a contained change rather than a rewrite. If one integration is wired through your whole codebase, that is the risk to fix first.
- Design for "any compliant provider." The direction Open Banking is already setting, licensed, consent-driven, standards-based integration, makes it realistic to build against a standard rather than a single vendor's quirks. Lean into that.
If you are a smaller bank or fintech partner
If your business rides a larger partner's rails, concentration limits plus ultimate-beneficial-ownership disclosure mean that partner may have to restructure, change what it offers, or reconsider how its group is counted. That is not a reason to panic. It is a reason to read your dependencies honestly: how much of your business runs through a single partner, what an exit would actually cost you, and whether you have a second rail you could move to. Diversifying before you are forced to is almost always cheaper than scrambling after.
What to do, wherever you sit
- Map your dependencies. Name the provider or partner you actually rely on, and for exactly what.
- Design for portability. Make a provider change contained, not catastrophic.
- Watch the official signals. Track the licensing register and your providers' status, not the rumour mill.
- Treat single-provider setups as a risk to manage, not a default to keep.
None of this asks you to predict how the market will move. It asks you to know your own exposure and build so a shift does not break you.
If you want a second set of eyes on where you depend on a single provider or partner, that is the kind of review we do with teams. The first conversation is a free, no-pressure 45-minute structured call: start the conversation.
Sources: CBN Circular PSS/DIR/PUB/CIR/001/004 (15 June 2026), read directly (see our data-localisation piece and the operator-side analysis). The downstream effects described here are reasoned, plausible consequences, not measured outcomes or predictions about any specific provider.
