Five places your payment data is still leaving Nigeria
Moving the database is the easy part. Keys, DR replicas, observability, backups and SaaS control planes are where payment data keeps crossing the border after the migration.
When a bank tells us its payment platform "is already in Nigeria", we ask to see the data map. In most cases the primary database is indeed in Lagos. In almost every case, something else is not. The CBN directive of 15 June 2026 is explicit that scope includes backups, IAM, encryption keys and audit logs, and it prohibits both cross-border replication and dependency on foreign cloud infrastructure. These are the five places we find data still leaving the country.
1. Encryption keys held in a foreign KMS
The pattern: the database lives in a Nigerian facility, encrypted at rest. The key that encrypts it is held in a hyperscaler key management service in Frankfurt, Dublin or Virginia, because that is where the account was set up years ago.
Why it matters: without the key, the data is unreadable. The service that holds the key therefore controls access to payment data, and that service is foreign infrastructure. Every decrypt operation is also a network call across the border. On a plain reading of the directive, this is both a foreign dependency and a form of processing outside Nigeria.
What to check:
- Where is the root key for each datastore generated and stored?
- Where is the TLS certificate private key for payment APIs held?
- Which service performs envelope encryption for application secrets?
- Can the platform start, and can the database be decrypted, with all foreign network paths cut?
The fix is a Nigerian-resident key management service, typically an HSM-backed KMS in a local facility, with a documented key ceremony and in-country rotation. We cover the design choices in Encryption key management under the CBN directive.
2. Disaster-recovery replicas in a foreign region
The pattern: a well-designed DR strategy with asynchronous replication from Lagos to a second region for resilience. The second region is in South Africa or Europe because that was the nearest available zone when the design was done.
Why it matters: this is the clearest case of prohibited cross-border replication. It is also the one that engineering teams are most reluctant to remove, because it was built for a good reason.
What to check:
- Every database with streaming or log-shipping replication: where is each replica?
- Storage-level replication (SAN, object storage cross-region replication): where is the target bucket or array?
- Kubernetes cluster federation or multi-cluster service mesh spanning borders?
The fix is a second Nigerian site. With 18 commercial data centres and operators including OADC, Rack Centre, Kasi Cloud, Galaxy Backbone and Equinix, a two-site in-country topology is achievable. Our disaster recovery solution is built around exactly this: active-passive or active-active between two Nigerian facilities, with replication that never leaves the perimeter.
3. Observability and audit logs shipped to foreign SaaS
The pattern: application logs, database audit logs and security events are forwarded to a SaaS observability or SIEM platform hosted abroad. The platform is excellent, the dashboards are mature, and nobody thinks of logs as payment data.
Why it matters: audit logs are named in the directive's scope. Application logs routinely contain transaction identifiers, account numbers, amounts and timestamps. A log line with a transaction reference and an account number is payment data. Aggregating those logs outside Nigeria is storage outside Nigeria.
What to check:
- Which log forwarders, agents and exporters are installed on payment systems, and where do they send?
- Does the APM tool capture request bodies or database queries?
- Where does the SIEM store raw events and for how long?
- Are error-tracking tools capturing stack traces with local variables?
The fix is an in-country logging and observability stack. Open-source components (OpenSearch or Elasticsearch for logs and audit, Prometheus and Grafana for metrics, a self-hosted SIEM) run well in a Nigerian private cloud. Our search and text analytics platform family covers the log-analytics part of this, with official support.
4. Backups in regional object storage
The pattern: nightly database dumps and volume snapshots go to an object-storage bucket. The bucket is in a region chosen for cost or for the backup tool's default. Sometimes the bucket is in Nigeria but the backup product replicates it automatically to a second region for durability.
Why it matters: backups are explicitly in scope. A backup is a complete copy of the database, and it often has weaker access controls than the production system.
What to check:
- For every backup job: the destination, the retention, and whether the destination has cross-region replication enabled
- Whether the backup product's own metadata catalogue (which may include file names, schema, and sometimes sample data) is stored abroad
- Whether archived or "cold" tiers are in a different region from the hot tier
- Whether any developer has an ad-hoc dump on a laptop or a personal cloud drive
The fix is in-country object storage with immutability and a second in-country copy. This is a solved problem with S3-compatible storage such as MinIO or Ceph deployed in a Nigerian facility. Our data governance and storage family covers the storage, lifecycle and retention side.
5. SaaS control planes and managed services
The pattern: the data plane is in Nigeria. The control plane (the thing that provisions, configures, monitors and upgrades it) is a SaaS operated from abroad. Examples include managed Kubernetes services with a foreign control plane, database-as-a-service consoles, identity providers, secrets managers and CI/CD services that hold deployment credentials.
Why it matters: the directive prohibits dependency on foreign cloud infrastructure, not merely storage. If the service that controls the payment platform is administered from outside Nigeria, the platform is dependent on it. Identity providers are a particularly clear case, because IAM is named in scope: if your engineers authenticate to production through a foreign identity service, a foreign service controls access to payment data.
What to check:
- For each platform component, where is the control plane? Who can reconfigure it, and from where?
- Where is your identity provider hosted, and does it hold the credentials that grant production access?
- Where is your secrets manager?
- Does your CI/CD system hold credentials that could read or modify payment data?
The fix is a self-managed platform with a Nigerian-resident control plane: Kubernetes with its own control plane in-country, self-hosted identity (Keycloak is the common choice), self-hosted secrets management and CI/CD inside the perimeter. This is the core of what a private cloud provides.
A checklist you can run this week
| Area | Question | Status |
|---|---|---|
| Keys | Are all keys that protect payment data generated and held in Nigeria? | |
| DR | Are all replicas, snapshots and replicated volumes in Nigeria? | |
| Logs | Do all log, trace, APM and SIEM destinations sit in Nigeria? | |
| Backups | Are all backup destinations, catalogues and cold tiers in Nigeria? | |
| Control plane | Are orchestration, identity, secrets and CI/CD operated from Nigeria? |
Any "no" is a gap. The readiness assessment covers these five areas plus contracts, data mapping and governance, and takes about ten minutes.
Why these five are missed
The common thread is that each of these systems was chosen for a good engineering reason and is one step removed from "the database". Teams inventory the database and stop. The directive names the surrounding systems precisely because regulators have seen the same pattern. A data map that starts from data flows rather than from servers finds all five.
This is not legal advice. This article describes technical patterns for planning purposes. Consult your legal and compliance advisers on how the directive applies to your institution.
NuxFamily builds and operates the platforms that close these gaps: in-country key management, two-site disaster recovery, self-hosted observability and a private cloud with a Nigerian control plane. If you would like help with your data map or your target architecture, see our CBN data localisation resource or contact us.
