Everything Banks and Fintechs Need to Know About the 2027 CBN Data Localisation Deadline

Executive summary (for CEOs, MDs, CTOs, CIOs, CISOs)

The Central Bank of Nigeria (CBN) expects payment transaction data generated in Nigeria to be stored and managed on infrastructure located in Nigeria by January 1, 2027. If your organisation processes payments, runs a wallet, switches transactions, provides payment gateways, or supports any CBN licensed payment workflow, you should assume you are in scope and start a structured programme now.

In practical business terms, this is not just an “IT project.”

It affects:

• Where your production systems run (cloud region, data centre, colocation, SaaS).
• Where data is processed and stored (databases, logs, analytics, backups, DR replicas).
• How your vendors contract and operate (subprocessors, audit rights, breach notification, residency guarantees).
• How you prove compliance (evidence, testing, controls, governance, reporting).
• How resilient and secure your payments platform is (availability, incident response, DR capability).
• Your cost base (migration, dual running, connectivity, compliance assurance, managed security).

If you wait until late 2026, you will almost certainly be forced into expensive shortcuts: rushed migrations, limited vendor choices, fragile architectures, compliance gaps, and avoidable downtime risk.

A realistic approach is to run this as a 24 month programme with clear milestones: assessment, architecture, vendor selection, migration waves, security hardening, DR testing, and audit ready evidence.

If you want an implementation partner that has done this in regulated environments, RJB World supports infrastructure assessment, cloud and data migration, compliance readiness, DevOps, cybersecurity, and disaster recovery planning. See the primary service page: https://rjbworld.org/services/fintech-infrastructure-migration

What the January 1, 2027 deadline means in plain English

“Data localisation” here means that payment transaction data generated within Nigeria must be stored and managed on infrastructure physically located in Nigeria by the deadline.

For executives, translate this into six decisions:

1. Which systems are in scope? (payments core, switching, wallets, settlement, fraud, reconciliation, ledgers, reporting, logs).
2. Where do they run today? (AWS eu-west, Azure UK, GCP Belgium, offshore hosting, SaaS).
3. What needs to move to Nigeria? (compute, databases, object storage, message queues, SIEM logs, backups, DR).
4. What must be redesigned? (latency, connectivity, encryption, key management, HA/DR, monitoring).
5. What evidence will CBN expect? (data flow maps, residency proofs, contracts, test results, controls).
6. What is the commercial plan? (budget, vendor lock in risks, execution timeline, governance).

CBN data localisation 2027 means payment transaction data generated in Nigeria must be stored and managed on infrastructure located in Nigeria by January 1, 2027, requiring affected banks and fintechs to migrate in scope systems, update vendor contracts, implement security and DR controls, and maintain audit ready evidence.

Who is affected (assume you are, if you touch payments)

If your organisation is licensed or regulated for payment activities in Nigeria, or you provide core technology used by regulated entities, you are likely affected.

In scope organisations (explicitly mentioned in common CBN communications and generally implicated by payment data rules)

• Deposit Money Banks (DMBs)
• Microfinance Banks (MFBs)
• Payment Service Providers (PSPs)
• Payment Solution Service Providers (PSSPs)
• Payment Terminal Service Providers (PTSPs)
• Switching companies
• Mobile Money Operators (MMOs)
• Super Agents and agency banking networks
• Fintechs providing wallets, collections, disbursements, card processing, lending with embedded payments, or merchant acquiring
• Processors and payment gateways
• Technology service providers hosting or processing transaction data on behalf of regulated entities

Also impacted (often forgotten)

• SaaS providers touching transaction data: reconciliation tools, fraud tooling, customer support platforms with transaction views, analytics tools.
• Cloud and security vendors: SIEM, logging, APM, DLP, CSPM, managed SOC.
• Data teams: data warehouses and lakehouses that ingest transaction events.
• Group structures: Nigerian subsidiaries that currently share platforms with offshore parent systems.

If you are unsure whether a dataset is “payment transaction data,” treat it as in scope until your compliance team and counsel confirm otherwise.

What “payment transaction data” includes (practical scoping)

Executives usually ask one question: “Is it just card authorisations and settlement files?”

In practice, the scope is typically broader. Most regulators view transaction data as any data created or processed to execute, authorise, route, reconcile, settle, reverse, dispute, or audit a payment.

Common in-scope datasets

• Transaction requests and responses (API payloads, ISO messages, switch messages)
• Ledger entries and journal lines related to payment events
• Reconciliation data and settlement files
• Chargeback, disputes, reversals, refunds
• Merchant and terminal transaction logs
• Audit trails showing who did what and when
• Fraud decisioning inputs and outputs tied to a transaction
• Customer activity logs that directly capture transaction details
• KYC and account metadata when directly tied to payment execution (scope depends on your internal classification)

Frequently missed

• Application logs that contain transaction payloads.
• APM traces capturing request bodies.
• Analytics pipelines (Segment like event collection, warehouses).
• Customer support exports where agents download transaction histories.
• Backups and archive stores sitting offshore.

Why you should not wait until late 2026

Late 2026 is where good compliance plans go to die.

Here is what typically happens when organisations delay:

• Vendor capacity dries up. Local data centres, colocation, and Nigeria cloud availability become constrained.
• Long lead items bite. Circuits, cross connects, HSM procurement, secure cages, enterprise firewall lead times.
• Architecture shortcuts become “permanent.” You end up with fragile lift and shift, no DR, weak monitoring, and risky manual operations.
• Dual running costs explode. You run offshore and onshore in parallel, but without a clean cutover plan.
• Audit evidence is missing. You migrate workloads, but cannot prove data flow, residency, and controls.

Do not wait until late 2026 because infrastructure procurement, vendor contracting, architecture redesign, migration waves, security hardening, DR testing, and compliance evidence typically require 12 to 24 months, and vendor capacity constraints increase cost and execution risk.

The directive is not only about localisation (what else executives should notice)

Many CBN directives in this area also reference broader governance themes such as Ultimate Beneficial Ownership (UBO) disclosure, market concentration limits, and stronger regulatory oversight.

For an executive team, the message is simple:

• Expect more questions about who owns and controls critical vendors.
• Expect scrutiny on single points of failure, including one hyperscaler, one processor, one switch, one data centre.
• Expect higher expectations for resilience and operational risk controls.

Treat localisation as the forcing function to upgrade your platform and your compliance posture at the same time.

Quick self-assessment: Are you already at risk?

Use this as a board level screening tool.

If you answer “yes” to any, you need a formal programme.

• Are any payment databases hosted outside Nigeria?
• Is your primary cloud region outside Nigeria?
• Are transaction logs exported to an offshore SIEM or analytics tool?
• Does your DR site replicate offshore?
• Do third parties (fraud, CRM, support) store transaction details outside Nigeria?
• Do you lack a complete data flow map for payment data?
• Do you lack tested DR with documented RTO and RPO for payment systems?

Implementation steps (high level plan)

This is the simplest way to run the programme without losing control.

1. Establish governance and accountability. Name an executive sponsor and a programme owner.
2. Define scope. Systems, datasets, vendors, environments, and geographies.
3. Map data flows. Where data is created, processed, stored, replicated, logged, and backed up.
4. Select target architecture. Nigeria region or data centre, HA, DR, security model.
5. Execute migration in waves. Prioritise highest risk systems first.
6. Implement security and resilience controls. IAM, encryption, monitoring, SOC, DR tests.
7. Validate and evidence compliance. Residency proofs, contracts, test reports, runbooks.
8. Operationalise. Train teams, handover to operations, implement KPIs and continuous compliance.

If you want RJB World to lead the assessment and migration plan, start here:

https://rjbworld.org/services/fintech-infrastructure-migration

Month-by-month roadmap to January 1, 2027 (executive view)

Assumption: you start August 2026? That is too late.

This roadmap assumes you start now and run a controlled programme. Adjust dates based on when you begin, but keep the sequence.

2026 (Aug to Dec): Mobilise, scope, and lock architecture

August 2026

• Appoint sponsor, programme manager, and workstream owners (Infrastructure, Apps, Security, Compliance, Vendor Management).
• Define “in scope” payment systems and data classification.
• Freeze new offshore dependencies unless explicitly approved.

September 2026

• Complete data flow mapping for top 10 payment journeys.
• Inventory vendors and subprocessors touching transaction data.
• Identify “quick wins” (stop log exports offshore, restrict payload logging, mask sensitive fields).

October 2026

• Decide target hosting: Nigeria cloud, local DC, colocation, hybrid.
• Draft target reference architecture (HA, DR, network, IAM, key management).
• Start procurement for connectivity, HSM, firewalls, WAF, SIEM if changes are needed.

November 2026

• Contracting: add residency clauses, audit rights, breach notification SLAs, right to inspect subprocessors.
• Build migration factory plan: tooling, runbooks, cutover approach, rollbacks.
• Establish compliance evidence repository (controls, screenshots, reports, attestations).

December 2026

• Build landing zone (accounts, VPC/VNET, subnets, security baselines).
• Stand up logging, monitoring, vulnerability management, secrets management.
• Plan migration waves with business owners and customer impact windows.

2027 (Jan): Deadline month actions (you should already be compliant)

January 2027

• Final compliance validation: confirm all in-scope systems and datasets are on Nigeria infrastructure.
• Run final DR test and capture results.
• Provide internal attestation pack for compliance and regulator engagement.

Reality check: If you are reading this in 2026, compressing all of this into a few months is possible only for small platforms with limited dependencies, and it will cost more than doing it properly.

Detailed roadmap (recommended): 18 to 24 month execution plan

If you want a plan that reduces operational risk, use this structure.

Phase 1 (Months 1 to 2): Discovery and regulatory interpretation

Deliverables:

• In-scope system list and owners
• Payment data classification standard
• Data flow diagrams for key journeys
• Gap assessment against localisation requirement
• Initial risk register and programme plan

Phase 2 (Months 3 to 4): Target architecture and vendor strategy

Deliverables:

• Target architecture (Nigeria hosting, HA, DR)
• Vendor shortlist and selection criteria
• Procurement plan and lead times
• Migration approach by workload type
• Contract addenda template for residency and audits

Phase 3 (Months 5 to 12): Build and migrate in waves

Deliverables:

• Production landing zone and security baseline
• Wave based migrations (least complex to most complex)
• Data migration and validation reports
• Cutover runbooks and rollback plans
• Performance and latency validation

Phase 4 (Months 13 to 18): Resilience, security hardening, and evidence

Deliverables:

• DR environment and tested failover
• Incident response runbooks and tabletop exercises
• SOC integration, SIEM tuning, alert playbooks
• Compliance evidence pack (controls, logs, contracts, tests)

Phase 5 (Months 19 to 24): Optimisation and continuous compliance

Deliverables:

• Cost optimisation (FinOps)
• SLOs and operational KPIs
• Continuous control monitoring
• Vendor audits and annual DR drills

RJB World typically supports clients through these phases with a combined consulting and implementation model: assessment, design, migration delivery, and operational readiness. Contact: https://rjbworld.org/contact

Infrastructure readiness checklist (copy and use internally)

Use this checklist to brief leadership and create work tickets.

A. Scope and data governance

• System inventory includes production, staging, analytics, DR, and backups
• Payment data classification policy approved by Compliance and Security
• Data flow maps for every payment product and channel
• Data retention schedule aligned to regulatory and business needs

B. Hosting and network

• Primary production runs on Nigeria located infrastructure
• DR site is also Nigeria located (or explicitly approved if exceptions exist)
• Low latency connectivity to switches, processors, and bank partners
• DDoS protection and edge controls (WAF, rate limiting)
• Network segmentation for PCI like environments and sensitive services

C. Identity, access, and key management

• Centralised IAM with least privilege roles
• MFA enforced for privileged accounts
• Secrets management (no secrets in code or CI logs)
• Encryption at rest and in transit for all in-scope data
• Key management strategy (KMS, HSM where required)
• Key rotation and separation of duties documented

D. Platform operations (DevOps)

• CI/CD pipeline with approvals for production
• Infrastructure as Code (Terraform, CloudFormation, etc.)
• Standardised environments (dev, staging, prod) with policy enforcement
• Vulnerability scanning in CI and runtime
• Patch management SLAs for OS, containers, and dependencies

E. Observability and security monitoring

• Central logging retained in Nigeria
• SIEM or SOC monitoring configured with alert runbooks
• Audit logs for admin actions immutable and retained
• Monitoring dashboards for latency, errors, saturation (payments SLOs)
• Evidence capture process for audits and regulator requests

F. Data and database management

• Database HA and backup strategy tested
• Point in time recovery (PITR) validated
• Data integrity checks post migration
• Masking and tokenisation for non production environments
• Data export controls and DLP policies

G. Disaster recovery and operational resilience

• RTO and RPO defined for each payment system
• DR architecture implemented (active active or active passive)
• DR failover test completed with lessons learned closed out
• Incident response plan includes payment outages and data incidents
• Business continuity plan aligned with technology DR

Cloud migration considerations (what will make or break the programme)

Most Nigerian banks and fintechs will address localisation through one of three models:

1. Nigeria cloud region (if available and suitable for your needs)
2. Local data centre or colocation
3. Hybrid approach (on-prem core with cloud for channels, or vice versa)

Comparison table: hosting options for localisation

Cloud migration: the non-negotiables

1) Data residency is not just “where the VM is.”

It includes backups, replicas, logs, analytics exports, and support tooling.

2) Lift and shift is usually not enough.

Payments platforms often need re-architecture for HA, DR, and observability.

3) Latency will change.

If you currently run in Europe, moving to Nigeria changes round trip paths to partners, third party processors, and card networks.

4) Vendor contracts must match your compliance story.

If the contract allows offshore processing by subprocessors, you will struggle to prove compliance.

5) Migrations fail at the edges.

The core database rarely fails. Integrations, batch jobs, cron schedules, and hidden exports do.

Cybersecurity expectations (what CBN will indirectly test you on)

Even when the rule is “localise data,” the regulator’s real concern is risk: data exposure, systemic outages, and lack of oversight.

Practical security controls to prioritise

Identity and privileged access

• Enforce MFA everywhere.
• Remove shared admin accounts.
• Use just in time privileged access for production.

Encryption

• TLS in transit for all internal and external traffic.
• Encryption at rest for databases, object stores, backups.
• Document key ownership and rotation.

Logging and detection

• Centralise logs in Nigeria.
• Make audit logs immutable.
• Build alerting for fraud spikes, auth failures, privilege escalation, and data exfil patterns.

Secure SDLC

• Dependency scanning.
• Container image scanning.
• Secrets scanning.
• Signed builds and deploy approvals.

Third party risk

• Assess vendors that touch transaction data.
• Confirm residency and subcontracting.
• Validate breach notification and incident support.

If you need help implementing the security baseline as part of migration, RJB World typically embeds security engineering and compliance evidence into the delivery plan rather than adding it at the end.

Disaster recovery, database management, and operational resilience

For payment platforms, the cost of downtime is usually higher than the cost of compliance.

Localisation projects are a good time to upgrade resilience.

Define RTO and RPO per system

• RTO (Recovery Time Objective): how long the business can tolerate the system being down.
• RPO (Recovery Point Objective): how much data the business can tolerate losing measured in time.

A typical pattern:

Targets should be agreed by business owners, not only IT.

DR models that work in regulated payments

• Active passive in two Nigeria sites: common, cost effective.
• Active active: higher cost, better continuity, harder to implement.
• Pilot light: minimal footprint DR, suitable for non critical systems.

Testing is mandatory in practice. A DR plan that has not been tested is just documentation.

DevOps and operating model changes you should expect

Localisation will force platform changes. If you do not fix the operating model, the platform becomes hard to run and expensive.

What good looks like

• Infrastructure as Code for repeatability and auditability.
• CI/CD with approvals and segregation of duties.
• Standard platform templates for services (network, logging, secrets).
• SRE style monitoring with SLOs for critical payment journeys.
• Runbooks and incident management that are actually used.

Banking and fintech example

A PSP migrating from offshore Kubernetes to Nigeria hosting typically needs to:

• rebuild cluster baselines (network policies, ingress, secrets)
• replace managed services that are not available locally
• redesign logging to keep transaction payloads out of logs
• implement immutable audit logs for admin actions
• add DR replication and scheduled failover drills

This is why starting early matters.

Budgeting for compliance (what it will cost and where it hides)

Executives need a realistic view of costs, including “hidden” cost centres.

Cost categories to plan for

Budgeting approach that works

1. Fund the assessment first (it will produce credible estimates).
2. Create a wave based migration budget (per system or product line).
3. Plan for dual running (usually 2 to 6 months per major platform).
4. Include assurance and evidence costs (audit readiness is work).

RJB World typically starts with a fixed-scope assessment that produces an actionable migration and compliance roadmap with cost ranges and sequencing.

Risk assessment framework (simple and defensible)

Use this framework to prioritise what moves first.

Step 1: Score each system (1 to 5)

• Regulatory exposure: does it process core transaction data?
• Customer impact: how many customers depend on it daily?
• Operational complexity: number of dependencies and integrations
• Data sensitivity: PII, financial data, credentials
• Migration readiness: can it move with minimal refactoring?

Step 2: Calculate priority

A simple formula many executives like:

Priority = (Exposure + Customer impact + Data sensitivity) − Migration readiness

High score systems go first.

Step 3: Apply controls

• High exposure + low readiness systems need early architecture work.
• High exposure + high complexity systems need more testing budget.
• Low exposure systems can move later, but ensure they do not leak data offshore via logs or analytics.

Common mistakes to avoid (what we see repeatedly)

1. Treating localisation as only a hosting move. You must address backups, logs, and DR.
2. Ignoring vendor subprocessors. Your main vendor may be compliant, their subcontractor may not be.
3. Not freezing new offshore dependencies. Teams keep adding SaaS tools that export data.
4. Leaving observability unchanged. Transaction payloads leak into logs and traces offshore.
5. Skipping DR tests. You will not know your true RTO and RPO.
6. Underestimating data migration complexity. Especially for ledger systems and reconciliations.
7. Doing one big bang cutover. Payment systems need wave migrations and rollback options.
8. Not building evidence as you go. Retrofitting compliance proof is expensive and risky.
9. Failing to align Compliance, Legal, and Engineering. This becomes a delivery blocker.
10. Not planning for people. Your team needs training, on-call structure, and runbooks.

What Should You Do This Quarter?

If you do only one thing, do this: start a structured assessment and lock the programme plan.

The quarter plan (90 days)

1. Appoint ownership

• Executive sponsor
• Programme manager
• Workstream leads: Infrastructure, Application, Security, Compliance, and Vendor

2. Complete a transaction data discovery

• Identify where transaction data lives today
• Map data flows for top payment journeys
• List every system that stores or processes transaction events
• Identify offshore logs, backups, analytics, and DR replicas

3. Run a vendor and contract review

• Identify vendors handling transaction data
• Confirm hosting locations and subprocessors
• Draft residency and audit clauses for renewals and amendments

4. Choose a target architecture direction

• Evaluate options: Nigeria cloud region, colocation, local data centre, or hybrid
• Decide on your high availability and DR strategy
• Identify services that must be replaced or redesigned

5. Build your business case and budget

• Cost ranges by migration wave
• Dual running and testing costs
• Security and compliance tooling costs

6. Start quick risk reduction

• Stop exporting logs offshore
• Mask sensitive data in non-production environments
• Reduce payload logging and implement tokenisation where needed

If you want RJB World to run the assessment and convert it into an implementation plan your teams can execute, contact: https://rjbworld.org/contact

Practical examples (banking and fintech scenarios)

Example 1: Switching company with offshore primary region

Current state

• Switch transaction processing runs in an EU cloud region.
• DR is in another EU region.
• SIEM ingests logs into a global tenant.
• Analytics warehouse is offshore.

What must change

• Production switching workloads move to Nigeria-located infrastructure.
• DR moves to a second Nigeria site.
• SIEM and log retention for transaction systems stays in Nigeria.
• Analytics either moves to Nigeria or ingests only anonymised aggregates, depending on scope decisions.

Common execution pattern

• Wave 1: Build landing zone, logging, and IAM.
• Wave 2: Move non-critical services and edge components.
• Wave 3: Move switch processing, then databases, then DR.
• Wave 4: Cutover, validate, and run DR test.

Example 2: Fintech PSP using multiple SaaS tools

Current state

The payments API runs locally, but several SaaS integrations handle sensitive data outside Nigeria. The customer support SaaS stores transaction history, the APM tool exports traces that include transaction payloads, and the marketing analytics platform ingests transaction events.

What must change

• Remove transaction payloads from APM traces.
• Configure support tooling to store only references and masked details, or migrate to Nigeria-compliant tooling.
• Re-architect analytics to keep transaction data in Nigeria, exporting only permitted aggregates.

This is why scoping and data mapping is step one.

FAQ

1) What is the CBN data localisation deadline?

January 1, 2027, by which affected organisations must store and manage payment transaction data generated within Nigeria on infrastructure located in Nigeria.

2) Who must comply?

Banks, fintechs, mobile money operators, switching companies, PSPs, PSSPs, PTSPs, and other CBN licensed payment participants, plus service providers processing transaction data on their behalf.

3) Does this apply to foreign fintechs serving Nigerian customers?

If you process payment transaction data generated in Nigeria within a regulated Nigerian payments context, assume yes and get formal legal and compliance interpretation.

4) Does it include backups and disaster recovery replicas?

In most compliance interpretations, yes, because backups and replicas are still stored copies of transaction data. Plan for Nigeria located backup storage and DR.

5) If our application runs in Nigeria but our logs go to an offshore SIEM, is that a problem?

Potentially yes. Logs often contain transaction payloads and identifiers. You should treat logging and observability pipelines as in scope until proven otherwise.

6) Can we keep analytics offshore if we anonymise data?

Sometimes, depending on what is exported and how it can be re-identified. Many teams choose a safer approach: keep raw transaction data in Nigeria and export only aggregated metrics.

7) Does this require moving everything to a Nigeria public cloud region?

Not necessarily. You can comply using Nigeria located cloud, colocation, local data centres, or hybrid architectures. The key is that in-scope data and systems are located in Nigeria.

8) What is the first step we should take?

Run a formal infrastructure and data flow assessment across payment systems, including vendors, logs, backups, and DR.

9) How long does a typical programme take?

For mid-sized platforms, 12 to 24 months is common, depending on architecture complexity, vendor changes, and testing requirements.

10) What makes migrations fail in regulated payment environments?

Hidden data flows, untested DR, rushed cutovers, vendor contract gaps, and inadequate observability and security baselines.

11) What evidence should we maintain for compliance?

Data flow maps, architecture diagrams, residency attestations, contract clauses, access control policies, encryption and key management configurations, DR test reports, and audit logs.

12) How will this affect customer experience?

If executed well, customers may see improved latency and reliability. If rushed, customers may experience downtime during cutovers and performance regressions.

13) What is the role of Compliance and Risk teams?

They define scope and evidence expectations, align interpretation, manage vendor risk, and ensure the programme produces audit-ready artefacts, not just migrated servers.

14) What is UBO disclosure and why does it matter here?

UBO disclosure is about identifying the real individuals who ultimately own or control a company. In payments ecosystems, it affects vendor due diligence and regulator oversight.

15) How do we budget without knowing exact costs yet?

Fund a short assessment first to produce a wave-based plan with cost ranges. Then release delivery budgets per wave with clear acceptance criteria.

16) Can we do this without a consulting partner?

Some organisations can, if they have strong in-house architecture, security, and migration capability. Many still use a partner to accelerate discovery, reduce risk, and build audit-ready evidence.

17) How can RJB World help?

RJB World supports infrastructure assessments, target architecture design, cloud and data migration execution, DevOps enablement, cybersecurity hardening, and DR planning/testing for banks and fintechs. Service page: https://rjbworld.org/services/fintech-infrastructure-migration

How RJB World typically runs a localisation programme (delivery approach)

When you engage an implementation partner, you want two outcomes: a compliant end state you can prove, and a platform that is stable, secure, and operable after the consultants leave.

RJB World's approach is delivered in four practical work packages:

1. Infrastructure and data flow assessment

• System inventory
• Data flow mapping
• Gap analysis
• Target architecture options and cost ranges

2. Migration and implementation planning

• Wave plan
• Cutover runbooks
• Vendor contract requirements
• Security baseline design

3. Implementation support

• Landing zone build
• Migration execution and validation
• Observability and SOC integration
• DR implementation and testing

4. Compliance readiness

• Evidence pack creation
• Control mapping and reporting support
• Operational runbooks and training

If you need to start quickly, use the contact page: https://rjbworld.org/contact

Is your organization ready for the January 1, 2027 CBN data localisation deadline? RJB World is here to assist.

We can help you start with an assessment and implementation roadmap for your fintech infrastructure migration.

If you want to discuss this further, feel free to talk to our team.