The Realisation Arrives Quietly

It is a Tuesday morning code review. A fintech CTO is scrolling through a pull request from his backend team. The change adds a new identity verification step to the onboarding flow. The logic is straightforward enough: when a user submits their BVN, the system calls an OpenAI endpoint to help parse the NIBSS verification response and extract structured identity fields.

He reads the prompt template in the code. It includes a raw BVN number. It includes the user's date of birth. It includes the full name as returned by the NIBSS lookup.

The API call is going to a server in the United States.

He closes his laptop and sits very still for a moment.

The product launches in three weeks.

What the NDPA Actually Says

Nigeria's Data Protection Act 2023 is not aspirational language. It carries enforcement teeth. The Nigeria Data Protection Commission (NDPC) has the authority to investigate, issue compliance orders, and impose fines. The Act applies to any organisation that processes the personal data of Nigerian citizens — regardless of where that organisation is incorporated.

Section 43 of the NDPA governs international data transfers. It is specific. Personal data can only be transferred to a foreign country or international organisation if one of the following conditions is met: the receiving country has been assessed as providing an adequate level of data protection, appropriate safeguards are in place (such as standard contractual clauses), or the data subject has given explicit, informed consent for the specific transfer.

A BVN is not generic personal data. It is a biometric-linked financial identity number. It is the primary key that NIBSS uses to anchor an individual's financial identity across every bank account they hold in Nigeria. Routing it through a third-party AI API endpoint is a data transfer. It does not matter that the purpose is identity verification. It does not matter that the AI is only being used to parse text. The transfer happens the moment the BVN leaves Nigerian infrastructure and enters a foreign server.

Did your onboarding flow present the user with an explicit consent notice that told them their BVN would be processed by a US-based AI company? Did it name that company? Did it explain the data residency implications?

If not, the transfer is non-compliant. Full stop.

The NIBSS Data Residency Layer

The problem compounds when you consider the NIBSS framework.

NIBSS — the Nigeria Inter-Bank Settlement System — is the custodian of the BVN database. Access to BVN verification is governed by strict terms. Financial institutions and licensed fintechs that integrate with NIBSS for identity verification do so under agreements that carry obligations about how that data is handled, stored, and transmitted.

Sending BVN data to a global AI provider is not a use case those agreements anticipate or permit. The data is meant to be used for the specific verification purpose — confirmed, logged, and protected. It is not meant to be packaged into a prompt and dispatched to a model training pipeline infrastructure in another continent.

There is also a practical dimension. Global AI providers process API inputs according to their own terms of service. Those terms can change. Some providers have clauses that allow inputs to be used to improve models under certain configurations. Even where opt-out mechanisms exist, most Nigerian engineering teams have not explicitly configured them. The default behaviour may not be what the CTO assumed.

The gap between what the team thought was happening and what was actually happening is where regulatory exposure lives.

What a Compliant PII-Scrubbing Architecture Looks Like

The solution is not to abandon AI in the identity verification pipeline. AI has genuine utility in this space — parsing OCR output from NIN slip images, cross-referencing identity signals, detecting synthetic identity patterns. The utility is real.

The solution is to ensure that AI models never receive raw PII as input.

A compliant architecture has a PII scrubbing layer that sits between internal data systems and any external AI API call. Before a prompt is dispatched to any model — whether OpenAI, Anthropic, Google, or any other provider — it passes through a scrubbing function that replaces sensitive fields with anonymised tokens or structured placeholders.

Instead of sending: "Verify that BVN 12345678901 matches the name Adaeze Okonkwo born 1990-03-14" — the system sends: "Verify that identity_token_A matches identity_token_B with demographic_token_C." The actual resolution of those tokens to real values happens internally, within Nigerian infrastructure, after the model returns its output.

The model never sees the BVN. The model never sees the date of birth. The model never sees the name. It sees structured, tokenised representations. It does its job. The internal resolver maps the output back to real identity data.

This architecture achieves two things simultaneously. It keeps the utility of AI-assisted verification intact. And it ensures that no raw PII — no BVN, no NIN, no NIBSS-returned identity fields — ever crosses the border in a form that constitutes a regulated data transfer.

This is not a theoretical architecture. It can be built. The cost of building it is significantly lower than the cost of a NDPC investigation.

The Consent Problem Cannot Be Papered Over

Some teams, when presented with this issue, reach for a consent checkbox. They add a line to the terms of service. They tick a legal review box and move on.

This does not work.

The NDPA requires that consent be specific, informed, freely given, and unambiguous. Burying a reference to "AI-assisted processing" in a 4,000-word terms of service document does not constitute informed consent for the transfer of biometric financial identity data to a named foreign AI provider.

The NDPC has been explicit in its guidance that data controllers cannot use broad, generic consent clauses to cover high-risk processing activities. BVN transfers to foreign AI infrastructure is a high-risk processing activity. It requires a specific, prominent, layered consent mechanism — not a footnote.

More importantly, even if consent were properly obtained, it does not resolve the NIBSS agreement obligations. Those are contractual, not just regulatory. Consent from the data subject does not override the terms under which NIBSS granted BVN verification access.

The Structural Moat for Companies That Get This Right

There is a commercial argument here, not just a compliance one.

Nigerian fintech is entering a phase of regulatory maturity. The CBN, the NDPC, and the NFIU are all increasing their technical sophistication. Compliance audits are becoming more detailed. Investor due diligence on Nigerian fintechs now includes data governance questions that did not appear in term sheets two years ago.

The companies that build correct PII-scrubbing architectures now — that can demonstrate data residency compliance, that can show an auditor exactly where BVN data lives and where it does not go — will have a structural advantage. Not because they avoided a fine, though that matters. But because their compliance posture becomes a product feature.

Enterprise clients, banking partners, and international investors increasingly require demonstrated NDPA compliance before they will sign. A company that can produce a clear data flow diagram showing that its AI pipeline never touches raw PII is a company that can close deals its competitors cannot.

The companies that figure this out first will not need to scramble when the audit arrives. They will hand over the documentation and go back to building.

That is the real opportunity buried inside this compliance problem.