What the CBN directive actually requires: a technical reading

Most summaries of the Central Bank of Nigeria's June 2026 circular reduce it to one sentence: "payment data must stay in Nigeria by 1 January 2027." That sentence is correct and almost useless to an architect. The directive is specific about which systems are in scope, and the specificity is where projects succeed or fail. This article reads the directive the way an engineering team needs to read it.

The document and the dates

On 15 June 2026 the CBN published the circular titled Introduction of Market Structure Requirements, Data Localisation, Ultimate Beneficial Ownership Disclosure, and Systemic Oversight Measures in the Nigeria Payments System. The data localisation section is one part of a broader package, but it is the part with a hard engineering deadline: 1 January 2027.

That gives regulated entities a little over six months from publication. For a bank running core payment workloads on a hyperscaler region outside Nigeria, six months is not a comfortable window. It is a feasible one only if the scope is understood on day one.

Who is in scope

The directive applies to participants in the Nigerian payments system, which in practice means:

• Commercial banks and other deposit-taking institutions
• Licensed payment service providers (PSPs), including switches and processors
• Mobile money operators
• Fintechs holding a CBN licence that touch payment transaction data

The test is functional, not organisational. If your organisation stores or processes Nigerian payment transaction data under a CBN licence, the obligation attaches to that data regardless of where your engineering team sits or which vendor operates the platform.

What "payment transaction data" covers

The circular does not limit itself to the transaction record. It names the environments around that record. Read as a systems inventory, the scope is:

Component	What it means in practice
Primary processing environments	The compute that executes the payment flow: core banking payment modules, switching, authorisation, settlement services, APIs that accept or return transaction data
Databases	Every datastore holding transaction records, including read replicas, caches and analytical copies
Backups	Snapshots, dumps, object-storage archives and any secondary copy, wherever the backup tool puts it
Identity and access management	The directories and IAM services that grant access to the above
Encryption keys	The key management systems holding keys that protect payment data at rest or in transit
Audit logs	The logs recording who accessed, changed or exported payment data

Two of these lines are the ones most often missed in early scoping: encryption keys and audit logs. A database in Lagos encrypted with a key held in a foreign KMS is, on a plain reading, still dependent on foreign infrastructure. Audit logs shipped to a foreign SaaS observability platform are payment data leaving the country. We cover both in separate articles: Encryption key management under the CBN directive and Five places your payment data is still leaving Nigeria.

The prohibitions

Three prohibitions are stated explicitly:

1. No storage or processing of payment data outside Nigeria. This is the headline obligation.
2. No dependency on foreign cloud infrastructure for that data. This is broader than storage. A control plane, an orchestration service or a managed database that is operated from outside Nigeria creates a dependency even if the bytes are physically in the country.
3. No cross-border replication. Disaster-recovery copies in a foreign region are the most common instance. Multi-region database clusters spanning Nigeria and Europe are another.

The second prohibition is the one that changes architecture decisions. It is not enough to select a Nigerian availability zone of a global provider if the service you consume is administered, patched and controlled from elsewhere. The conservative reading is that the full stack (infrastructure, control plane, data plane and operations) must be resident and operable within Nigeria.

The secondary obligations

The directive also lists obligations that are administrative rather than architectural, but they are auditable and they need engineering evidence:

• Localisation clauses in supplier contracts. Every vendor with access to payment data must be contractually bound to keep it in Nigeria.
• Audit rights. Your institution must be able to audit those vendors, and the CBN must be able to inspect.
• Regulatory inspection facilitation. Inspectors must be able to reach the systems physically and logically.
• Breach notification protocols. Incident processes must be documented and exercised.
• Data mapping. A current, evidenced map of where every class of payment data lives and flows.
• Updated data governance. Policies, ownership and controls aligned with the new residency perimeter.

The data map is the artefact that ties everything together. It is also the first deliverable of any serious compliance programme, because you cannot migrate what you have not enumerated.

What "compliance" looks like as evidence

Inspectors do not read intent; they read evidence. A defensible compliance position at 1 January 2027 consists of:

• A data inventory listing every system holding payment data, its location, its operator and its backup destinations
• Architecture documentation showing the Nigerian perimeter and the controls at its boundary
• Key custody records proving keys are generated, stored and rotated in-country
• Log retention evidence showing audit logs remain in Nigeria for the required period
• Contracts with localisation and audit clauses in force
• DR test results demonstrating recovery inside Nigeria

If any of these items depends on a foreign service, you have a gap, and the gap needs a closure plan with a date.

How this overlaps with other frameworks

The circular does not replace the Nigeria Data Protection Act 2023 or the CBN's risk-based cybersecurity framework. It sits on top of them. The practical consequence is that a localisation programme should be run as one governance effort covering all three, not as three parallel projects with three sets of controls. We expand on this in CBN, NDPA and the cybersecurity framework: one compliance programme, not three.

Reading the directive against the market

Nigeria has around 26 data centre facilities, 18 of them commercial, with 50–56 MW of operational capacity. Operators such as OADC, Rack Centre, Kasi Cloud, Galaxy Backbone and Equinix offer colocation that satisfies the physical residency requirement. The constraint the sector reports is not floor space; it is the availability of complete local cloud platforms and of engineers who have built and operated private cloud at scale. That is a platform-and-people problem, and it is solvable within the deadline if scoping starts now.

A practical first week

If your institution has not yet started, the first week should produce:

1. A named owner for the programme, reporting to the CTO and the chief risk officer jointly
2. A first-pass data inventory of every system that touches payment data, including backups, keys and logs
3. A classification of each system as in-country, foreign, or foreign-dependent
4. A list of every supplier contract that needs a localisation clause
5. A decision on target architecture: own facility, Nigerian colocation, or a hybrid with an isolated payment-data perimeter

The readiness assessment on this site walks through the same questions in about ten minutes and gives a structured starting point.

---

This is not legal advice. This article summarises a regulatory document for technical planning purposes. Consult your legal and compliance advisers on how the directive applies to your institution.

NuxFamily has spent two decades building and operating private cloud platforms for European banks and large enterprises, and now applies that experience to the Nigerian market. If you want a second opinion on your scoping, or an engineering partner for the migration, see our CBN data localisation resource or get in touch.