CBN Data Localisation FAQ | Nigeria Payment Data

It is a circular issued by the Central Bank of Nigeria on 15 June 2026 requiring payment transaction data belonging to the Nigerian payments system to be processed and stored inside Nigeria. It covers primary processing, databases, backups and the administrative functions around them: identity and access management, encryption keys and audit logs. It also requires localisation clauses in supplier contracts, audit and inspection rights, breach notification protocols and a documented data map.

1 January 2027. There is no published transition window after that date, so the practical planning assumption is that an inspection could follow immediately. Institutions that have not started should treat data mapping as the first task, because it determines the size of everything else.

If you process payment transactions for Nigerian customers, accounts or instruments, plan on being in scope regardless of where the company is registered. The directive follows participation in the Nigerian payments system. If you conclude you are out of scope, document that reasoning now rather than during an inspection, and expect regulated clients to impose the obligation contractually in any case.

Yes, for workloads that never hold payment transaction data: corporate collaboration, marketing analytics on non-payment data, and parts of the software supply chain. What you cannot do is depend on foreign cloud infrastructure for payment processing, storage, keys, identity or audit logs. Anything that stays outside needs controls and evidence proving payment data cannot reach it.

Yes. Backups are named explicitly, and a backup is a complete copy of payment data, so a foreign backup bucket is one of the most serious gaps an estate can carry. Archives and snapshots count too, including older copies kept under long retention policies. If your backup tier is immutable or vaulted, start the lifecycle work early because those copies cannot simply be deleted on request.

Inside Nigeria, in infrastructure you control, with custody and rotation procedures you can evidence. Envelope encryption does not solve the problem: if the root key lives in a foreign KMS, control over Nigerian payment data sits outside the country. The usual answer is an HSM cluster at the primary site with a second unit at the DR site and a documented key ceremony.

Not for payment systems. Audit logs are within the objective scope, and in practice application and database logs carry account identifiers, amounts and device data, so redaction is not a reliable defence. Run the logging and SIEM stack in-country with full retention. If a foreign tool remains for non-payment estates, use separate agents and pipelines so payment systems cannot reach it.

No. Cross-border replication of payment data is expressly prohibited, and a DR replica abroad means a full copy exists outside Nigeria continuously. Disaster recovery has to be a second Nigerian site. That has a design consequence: bandwidth and latency between two Nigerian facilities now determine your achievable recovery point objective.

A managed control plane abroad exercises administrative functions over Nigerian payment systems and holds credentials, configuration and metadata about them, which is why we treat it as in scope. Hosted CI/CD that deploys straight into production and monitoring agents with outbound tunnels fall in the same category. Bring these planes in-country, or restrict them to non-payment estates and prove the separation with network evidence.

The directive requires localisation clauses, audit rights, support for regulatory inspection and breach notification protocols in supplier agreements. In practice that means renegotiating with cloud providers, software vendors, processors and any party with remote access. Start early: contract cycles with large vendors routinely take longer than the technical migration, and a technically compliant estate with non-compliant contracts still fails.

For a mid-sized estate, eight to ten months from mapping to steady state is a realistic figure, with the build and migration phases taking most of it. Larger banks with many adjacent systems run longer, and the long tail (reporting, reconciliation, fraud tooling) usually costs more time than the core. The schedule is driven by hardware lead times, key ceremonies and cutover windows rather than by engineering effort alone.

A current data map, the target architecture with the perimeter marked, key custody and ceremony records, supplier contracts with the required clauses, network evidence that payment traffic does not leave the country, restore and DR test results, and certificates of deletion for foreign copies. Collect these continuously from the systems that produce them. An evidence pack assembled after a request arrives is both slower and less credible.