Freshness note (16 June 2026): This guide reflects the CBN circular signed by Rakiya O. Yusuf, Director of the Payments System Supervision Department, and reported on 15 June 2026. Regulatory text and deadlines can be amended. Confirm the operative wording, reference number and any clarifications directly against the CBN circular and your legal counsel before acting. Vendor and data-centre details are accurate as of June 2026 and should be re-checked every 3–6 months.

The 18-month clock just started — and most stacks aren’t ready

On 15 June 2026, the Central Bank of Nigeria told every bank, fintech, mobile money operator and payment service provider the same thing: payment transaction data generated in Nigeria must be stored and managed in Nigeria by 1 January 2027. The operative line in the circular is unambiguous — payments transaction data generated within Nigeria must be “stored and managed in Nigeria in accordance with data protection laws” applicable locally.

That single sentence is a problem for a large share of the ecosystem, because there is still no hyperscaler region (AWS, Azure or Google Cloud) physically inside Nigeria. If your production database, your transaction logs, your reconciliation pipeline or your analytics warehouse sits in eu-west-1 (Ireland), us-east-1 (Virginia) or a European Azure region — and for most Nigerian fintechs, at least one of them does — you have roughly six months to design a migration and a little over a year to finish it.

This guide separates what the circular actually requires from the noise, gives operators a decision framework for build-vs-buy-vs-repatriate, and goes deep on the architecture: what “stored and managed in Nigeria” means in practice, which local hosting options exist, how to keep a global product running on a Nigeria-resident data plane, and how to reconcile all of this with the Nigeria Data Protection Act (NDPA) 2023. It closes with the questions operators keep asking, and the three things worth doing in the next 30 days.

What the circular actually says (and what it doesn’t)

The 15 June circular bundles four measures into one document — and only one of them is data localization. Conflating them is the fastest way to waste budget. Here is the clean breakdown.

1. Data localization (deadline: 1 January 2027). Payment transaction data generated in Nigeria must be stored and managed in Nigeria, in line with Nigerian data protection law. This is the requirement with the longest technical lead time and the one this guide focuses on.

2. Ultimate Beneficial Ownership (UBO) disclosure (compliance by 31 December 2026). Banks, PSPs and other financial institutions with digital payment operations must disclose the ultimate beneficial owners of significant shareholders, in line with AML/CFT regulations, and keep those records current and available to the CBN on request. This is a governance and company-secretarial task, not an engineering one.

3. Market-structure caps (compliance by 31 December 2026). Any institution holding more than 25% of the card-issuing market in a rolling 12-month window is capped at 15% in merchant acquiring — and vice versa. Regulated entities must file monthly market-share returns on CBN templates. This mostly affects the largest switches and acquirers, but the monthly reporting obligation touches everyone.

4. Systemic oversight / monitoring. The CBN said it will monitor compliance and impose supervisory sanctions where necessary.

Two dates matter, and they are one day apart: market-structure and UBO by 31 December 2026, then data localization from 1 January 2027. Treat them as separate workstreams with separate owners — legal/compliance for UBO and market share, engineering plus compliance jointly for localization.

What the circular does not do is define “payment transaction data” field-by-field, specify an approved hosting list, or (in the reporting to date) attach a naira penalty schedule. That ambiguity is itself a planning input: scope conservatively, document your interpretation, and keep an audit trail of the decisions you made and why.

Who is actually in scope

The directive is addressed broadly: deposit money banks, microfinance banks, mobile money operators, switching and processing companies, payment terminal service providers (PTSPs), payment solution service providers (PSSPs), super agents, and other licensed payment operators. If you hold a CBN payments licence or facilitate payments in Nigeria, assume you are in scope until your counsel tells you otherwise.

The operators with the most work ahead are the ones whose architecture was built “cloud-first, region-later”:

  • API-first fintechs running primary databases in a single overseas region.
  • Companies on managed SaaS for cards, KYC, ledgering or fraud where the vendor stores data abroad.
  • Cross-border and stablecoin players whose settlement and ledger data is deliberately multi-jurisdictional.
  • Startups using overseas analytics warehouses (BigQuery US, Snowflake on a non-Nigerian region, etc.) fed by production replication.

The operators with the least work are those already colocated in Lagos data centres or running on a Nigeria-resident managed platform — but even they need to prove managed in Nigeria, not just stored.

The operator decision framework: repatriate, rehost, or re-architect

Before any migration, run every system that touches Nigerian payment data through four questions.

Question 1 — Is this payment transaction data? Map your data estate and classify each store. Core transaction records, authorization logs, settlement and reconciliation data, and card/account identifiers are clearly in scope. Marketing analytics, anonymized/aggregated metrics and product telemetry are greyer. Scope the clear cases in, document your reasoning on the grey ones, and don’t let a debate about edge cases delay migrating the obvious core.

Question 2 — Where does it live today, and who controls it? For each in-scope store, record the physical region and the operator of record (your cloud account, a SaaS vendor, a processor). You cannot localize what a third party controls — vendor data residency is the hidden critical path.

Question 3 — Repatriate, rehost, or re-architect?

  • Repatriate — lift the existing workload into a Nigeria-resident environment (colocation or a local cloud) with minimal redesign. Fastest path; best for self-hosted databases and stateless services.
  • Rehost on a local managed platform — move to a Nigerian data-centre operator’s managed/cloud offering. Less ops burden; check the SLA, DR and certifications carefully.
  • Re-architect — split the data plane so the system of record for Nigerian payment data is resident in Nigeria, while global features read from it through APIs. Most work, but the only durable answer for genuinely multi-country products.

Question 4 — What’s the DR and latency story? Localization does not waive resilience. You need an in-country primary and a recovery posture — ideally a second Nigerian availability zone or a second Lagos/Abuja facility — plus a tested plan for the day a single data centre or power feed fails.

A practical sequencing rule: classify in month 1, fix vendor contracts in months 2–4, migrate the system of record by Q3 2026, and spend Q4 2026 on DR, testing and evidence so 1 January 2027 is a non-event.

The technical deep-dive: building a Nigeria-resident payment data plane

“Stored and managed” is the load-bearing phrase

The circular says stored and managed in Nigeria. Storage is the easy half — put the bytes on disk in Lagos. “Managed” implies the processing, administration and operational control of that data also happen within the jurisdiction. In design terms that means the system of record (the authoritative database for Nigerian payment transactions), its backups, and its day-to-day processing should run in-country. A model where data is “stored” in Lagos but every query is served by an application tier in Frankfurt that pulls full records across the border is exactly the kind of arrangement the rule is written to discourage. Keep authoritative reads and writes for Nigerian payment data inside Nigeria.

The hosting reality: no hyperscaler region, real local options

The core constraint: as of June 2026, AWS, Microsoft Azure and Google Cloud have no in-country region in Nigeria. So localization means one of three infrastructure routes:

  1. Colocation in a Lagos/Abuja data centre. Tier III facilities operated by the likes of Rack Centre, MDXi (MainOne/Equinix), Open Access Data Centres (OADC), Galaxy Backbone, Kasi Cloud and others provide carrier-neutral space and power. You bring your own hardware (or rent it) and run your own stack. Maximum control, maximum ops responsibility.
  2. Local/regional managed cloud. Nigerian providers (e.g., Layer3 Cloud, Suburban, Kasi, OADC’s cloud, Galaxy Backbone for government-adjacent workloads) offer IaaS/managed services hosted in-country. Less control than colo, far less than running your own metal, but much lighter operationally.
  3. Hybrid / edge-localized. Keep global, non-payment workloads on your existing hyperscaler footprint and move only the in-scope Nigerian payment data to a local primary, connected over private interconnect. This is usually the pragmatic answer for products that legitimately operate beyond Nigeria.

Whichever route, insist on two physically separate Nigerian sites (or two zones) so localization and disaster recovery are satisfied together — single-site localization is a compliance win and an availability time-bomb.

Reference architecture for a cross-border product

For an operator running in multiple African markets, the durable pattern is a per-country system of record with an API boundary:

  • Nigerian payment data plane (resident in Nigeria): primary transactional database (e.g., PostgreSQL/MySQL with synchronous replica in a second NG zone), the ledger, authorization and settlement services, encrypted backups, and the processing jobs (reconciliation, reporting) that operate on that data.
  • Global control plane (can remain offshore): user-facing app shells, product configuration, non-payment analytics, and orchestration — which call into the Nigerian data plane through versioned APIs rather than replicating raw payment records out of the country.
  • Data minimization at the border: when a global service genuinely needs Nigerian data, expose tokenized or aggregated responses, not full PANs or raw transaction rows. Tokenization (vault the sensitive value in Nigeria, pass a non-sensitive token abroad) is the single highest-leverage technique for shrinking what has to cross a border at all.
  • Reconciliation across providers: if you route across multiple processors or wallets (M-Pesa is Kenya, MTN MoMo spans Ghana/Uganda/CI, Paystack/Flutterwave domestically), keep the Nigerian leg’s authoritative records in Nigeria and reconcile by reference, not by shipping full datasets home.

Migrating without downtime

Treat the database move as a first-class project, not a weekend cutover:

  1. Stand up the Nigerian primary and replicate from the current overseas database (logical replication / CDC tools such as Debezium, or native replication).
  2. Dual-write or shadow-read to validate parity under production load.
  3. Cut over writes to the Nigerian primary in a maintenance window, keeping the old region as a temporary fallback.
  4. Repoint backups, jobs and analytics feeds to originate from Nigeria.
  5. Decommission the offshore copy — and prove it, because lingering replicas are a localization failure hiding in plain sight.

Plan for higher intra-country latency tolerances than a hyperscaler gives you, budget for capacity headroom (local power and cooling realities are not Virginia’s), and load-test the reconciliation and end-of-day batch jobs specifically — they are where in-country infrastructure limits bite first.

The SaaS and vendor problem

The hardest dependencies are the ones you don’t operate. If your KYC vendor, card processor, fraud engine, ledger-as-a-service, or analytics warehouse stores Nigerian payment data abroad, their residency is now your compliance gap. Action:

  • Inventory every third party that touches in-scope data.
  • Ask each, in writing, for their Nigeria data-residency roadmap and a contractual commitment date ahead of 1 January 2027.
  • For vendors that can’t or won’t localize, line up a replacement or an in-country deployment option now — vendor migrations are slow and you have one budget cycle.

Reconciling with the NDPA 2023

Localization sits on top of, not instead of, the Nigeria Data Protection Act (NDPA) 2023 and the NDPC’s framework. Practical overlaps:

  • Cross-border transfer: the NDPA already restricts transfers of personal data abroad without an adequate legal basis. CBN localization is stricter for payment data — store it in Nigeria — so design for the tighter of the two.
  • Lawful basis, DPIA and minimization: a localization migration is a perfect trigger to refresh your Data Protection Impact Assessment and prune data you never needed to hold.
  • Security architecture: the NDPC warned in April 2026 about coordinated cyber threats to Nigeria’s financial systems; an in-country primary concentrates risk, so pair localization with encryption at rest and in transit, key management held in Nigeria, segmented networks and tested incident response.
  • Governance: confirm your Data Protection Officer signs off the new architecture and that breach-notification runbooks reflect the in-country footprint.

FAQ

Does this mean I can’t use AWS, Azure or Google Cloud at all?
No. It means Nigerian payment transaction data’s system of record must live and be managed in Nigeria. You can keep non-payment, global workloads on a hyperscaler; you cannot keep the authoritative Nigerian payment data there while no in-country region exists. Watch for any future local hyperscaler region announcement, but do not plan around one for the 2027 deadline.

Is a Lagos availability zone of a foreign cloud enough?
Only if it is genuinely an in-country region/zone with data physically resident and managed in Nigeria. A CDN edge node or a points-of-presence cache is not data residency. Verify the physical location and the contractual residency commitment.

What exactly counts as “payment transaction data”?
The circular doesn’t enumerate fields. Scope core transaction records, authorization logs, settlement/reconciliation data and card/account identifiers in; document your treatment of aggregated analytics and telemetry; and confirm the boundary with counsel.

We operate in Kenya, Ghana and South Africa too — does one localized stack cover us?
No. Localization is jurisdiction-specific. Kenya (Data Protection Act 2019, ODPC), South Africa (POPIA), and Ghana (Data Protection Act) have their own regimes, and several are tightening data-residency expectations. The per-country system-of-record pattern in this guide is exactly what lets you satisfy multiple regulators without forking your whole product.

What happens if we miss 1 January 2027?
The CBN said it will monitor compliance and impose supervisory sanctions where necessary. For licensed payment operators, supervisory action is an existential risk, not a line-item fine — treat the date as hard.

Is six months enough?
For classification, vendor contracting and a single-database repatriation: yes, if you start now. For a full multi-country re-architecture: it’s tight, which is why the system-of-record migration should land by Q3 2026, leaving Q4 for DR and evidence.

Do these three things in the next 30 days

  1. Run a data-residency inventory. List every store and every vendor that touches Nigerian payment data, with physical region and operator of record. You cannot plan a migration you haven’t mapped.
  2. Send the vendor letters. Get written Nigeria-residency commitments (with dates) from every third party in scope. This has the longest lead time and is least under your control.
  3. Pick your route and stand up a Nigerian primary in staging. Choose colo, local managed cloud, or hybrid, and prove replication from your current database into Nigeria before the quarter ends.

Need a second pair of eyes on your localization plan? We run a free payment-data localization gap-analysis for Nigerian operators: a 60-minute working session where we map your in-scope data, flag the vendor dependencies most likely to slip, and sketch the migration sequence to hit 1 January 2027. WhatsApp us to book a slot — limited availability this month.

Sources

  • TheCable, “CBN directs banks, PSPs to store, manage payment transaction data in Nigeria” (15 June 2026): link
  • Nairametrics, “CBN mandates banks, fintechs to store payment data in Nigeria” (15 June 2026, includes verbatim circular text): link
  • Technext, “CBN gives banks, fintechs 6 months to localise data” (15 June 2026): link
  • NDPC cyber-threat warning context (April 2026), via Nairametrics: link