Everyone focuses on moving data onshore. That is the visible part of the work. But before anything moves, an institution has to decide what to move. That decision is harder than the migration itself, and it is the one most teams skip.
The circular says payment transaction data must be stored and processed onshore. It does not say all data must be onshore. It does not say every workload must move. The circular is specific about what it covers, and it leaves room for interpretation about everything else. That room is where good architecture lives and bad decisions hide.
Move everything, and you overpay for colocation you do not need, introduce latency to workloads that were fine offshore, and add operational complexity to parts of the stack that did not need to change. Move too little, and you risk non-compliance. The difference between these outcomes is a classification framework applied before the migration starts.
This is the residency classification problem. It is an architecture problem, not a compliance checkbox.
The three categories
Every data path in a payment system falls into one of three categories.
Must be onshore. This is data the circular explicitly covers. Payment transaction records, transaction logs, switching data, settlement data, and any records the CBN or NIBSS would request as part of a payment system examination. If a regulator asks for it and it is not in Nigeria, there is a problem. This category is not negotiable.
Can stay hybrid. This is data derived from payment transactions that does not need to be onshore for the circular to be satisfied. Analytics aggregates, reporting summaries, fraud detection models that run on sampled data, and business intelligence dashboards all fall here. The source data is onshore. The processed outputs can live offshore if that gives better performance or lower cost.
Should stay offshore. This is data that is worse off onshore. AI training datasets that need GPU clusters, disaster recovery environments that require geographic diversity, performance-sensitive workloads where a Lagos colocation cannot match the latency profile of a hyperscaler region, and archival storage that does not need sub-second access. Moving this data onshore adds cost and complexity without compliance benefit.
The mistake most teams make is treating this as a binary decision. Either everything moves or nothing moves. The right answer is a three-way split, and getting the proportions right is where the architecture work lives.
How to classify your data
The process takes two to four weeks for a typical bank or large fintech, run internally or with a specialist.
Step 1: Map every data path. You cannot classify what you have not found. Start with a complete inventory of every payment data path in your systems. For each path, document:
- What data moves through it (transaction ID, amount, merchant, customer, timestamp, device ID, location)
- Where it originates (POS terminal, mobile app, USSD, web, API)
- Where it is stored (database, data warehouse, log store, cache)
- Where it is processed (batch job, real-time stream, ML model)
- Where it is backed up (DR region, archive, cold storage)
Document this as a table. One row per data path. Do not skip paths because they seem obvious. The obvious ones are usually the ones that cause trouble.
Step 2: Apply the three categories. For each data path, ask three questions:
- Does the circular explicitly cover this data type? If yes, it is in "must be onshore."
- Does this data contain or derive from payment transaction data? If yes, it is in "must be onshore" unless it is an aggregate or summary that no longer contains individual transaction records.
- Would moving this data onshore degrade performance, increase cost, or reduce resilience without a compliance benefit? If yes, it is in "should stay offshore."
Everything else is in "can stay hybrid."
Step 3: Validate against the circular. Take the "must be onshore" list and compare it with the circular's scope. The circular covers deposit money banks, microfinance banks, mobile money operators, switching and processing companies, payment terminal service providers, payment solution service providers and super agents. If your institution is in one of these categories, the circular applies to your payment transaction data.
If you are unsure whether a specific data type is covered, ask: would the CBN's Payments System Supervision Department request this record in an audit? If the answer is yes, classify it as onshore.
Step 4: Design the topology. Once you know what goes where, design the three-environment topology:
- Primary onshore: your Lagos colocation, or your provider's Lagos facility. This runs the "must be onshore" workloads with synchronous replication.
- Secondary onshore: your DR site in Kano, Abuja or Port Harcourt. This runs the same workloads with near-synchronous replication and can take over if Lagos goes down.
- Offshore: your existing hyperscaler region. This runs "can stay hybrid" and "should stay offshore" workloads.
The control plane (identity, monitoring, deployment pipeline) can be shared across all three environments or isolated per environment. Shared is simpler. Isolated is more secure. Most banks should start shared and add isolation as they mature.
Common mistakes and how to avoid them
Mistake 1: Classifying by source instead of content. A common pattern: "this data comes from our POS terminals, so it must be onshore." But not everything from a POS terminal is payment transaction data. The terminal produces transaction records (onshore), device health pings (hybrid) and firmware update logs (offshore). Classify by what the data is, not where it comes from.
Mistake 2: Over-classifying out of fear. The deadline creates pressure. The natural response is to move everything and deal with the consequences later. That response is expensive. Colocation pricing in Nigeria is not cheaper than hyperscaler pricing. You pay for the migration twice: once to move everything, once to move back what should not have moved. Classify first, then move.
Mistake 3: Under-classifying because the architecture is hard. The opposite mistake: a team decides that classifying transaction data is too complex because it touches too many systems, so they classify narrowly and assume the rest is not covered. This is the more dangerous mistake. If the CBN audits an institution and finds payment transaction data on an unclassified path, the defence that it did not seem to apply will not work.
Mistake 4: Classifying once and never revisiting. Data topology changes. New products, new payment methods, new processing pipelines. Every time the topology changes, the classification needs to be reviewed. Make the classification a living document, not a one-time exercise.
What a complete classification looks like
When the four steps are done, you should have:
- A complete inventory of every payment data path in the organisation
- Each path classified as "must be onshore," "can stay hybrid" or "should stay offshore"
- A topology diagram showing where each category lands (primary onshore, DR onshore, offshore)
- A migration sequence: what moves first, what moves second, what does not move at all
- A review cadence for new data paths (quarterly, or whenever a new payment product launches)
This is not a compliance document. It is an architecture plan. It tells the engineering team what to build and the budget holder what to pay for. Without it, the institution is guessing. With it, the position is defensible before the board, the auditors and the CBN.
The position of this Journal
The classification is the first engagement in a residency migration, and it is where Kaliabe starts work: inventory, classification, topology design, then build. Institutions that have done the classification can move with confidence. Institutions that skip it will pay for the omission twice.
FIG. J3 — RESIDENCY CLASSIFICATION · ONSHORE · HYBRID · OFFSHORE · THREE CATEGORIES, ONE DEADLINE