Nigeria Data Protection Act 2023: Biometrics and KYC Compliance

A bank may delete the onboarding selfie and still retain a face template, liveness frames, a similarity score, a support screenshot and a processor's backup. If its privacy register lists only “customer photo,” the control has already lost track of the higher-risk objects. The Nigeria Data Protection Act has to cover the full verification data chain, including everything behind the most visible file.

The Nigeria Data Protection Act 2023, published through the NDPC resource portal, treats biometric data used for uniquely identifying a natural person as sensitive personal data. The Act also sets general processing principles, lawful bases, controller and processor duties, data-subject rights, data-protection impact assessment requirements and conditions for cross-border transfer; the NDPC's official FAQ summarises the Act's cross-border framework. KYC obligations may require identity processing. They do not exempt that processing from necessity, security or purpose limitation.

In brief

• Inventory raw captures, templates, scores, decision logs and review copies as separate objects.

• Document the lawful basis for each purpose and the additional statutory condition for sensitive personal data.

• Run a DPIA before high-risk biometric deployment and revisit it when models, purposes or transfer routes change.

• Make processor instructions, deletion, incident handling and cross-border safeguards verifiable in practice instead of leaving them as contract wording.

Build a purpose-to-object register

The register should also name controller, processors, location, recipients, retention trigger, deletion mechanism and the right or request process that applies.

Lawful basis is purpose-specific

An organisation may process some KYC data to comply with a legal obligation, some to enter or perform a contract, and some for another basis recognised by the Act. The correct analysis depends on the controller, sector and precise operation. A blanket line that all data are processed “for compliance” skips that analysis.

Because uniquely identifying biometric data are sensitive, the organisation must also identify the applicable condition for sensitive-data processing. If consent is used, the team should be able to show that it meets the Act's standard and that refusal or withdrawal has the stated effect. If processing relies on law, document the rule, scope and necessity rather than collecting redundant consent.

Each new purpose needs its own analysis. A selfie collected to verify an account should not end up, without one, as a training sample, a general fraud watchlist entry or a marketing attribute.

A DPIA should alter architecture

The Act requires a data-protection impact assessment before processing likely to result in high risk to individuals' rights and freedoms. Remote biometric KYC may combine sensitive data, automated evaluation, fraud signals, large-scale processing and consequential decisions. A useful DPIA tests the decision system as it will run in production.

It should cover:

• necessity of biometrics and less intrusive alternatives;

• false matches, false non-matches and demographic performance;

• tested presentation attacks versus injection threats outside that test;

• harm from wrongful rejection or impersonation;

• accessibility and a workable alternative route;

• template security and consequence of irreversible compromise;

• employee access, reviewer exports and support tooling;

• processors, subprocessors, transfer routes and government requests;

• retention, deletion and dispute holds;

• residual risk, approval and re-assessment triggers.

If the DPIA never changes a threshold, data field, storage design, fallback or contract, it probably documented the launch rather than assessed it.

Controller and processor accountability

The controller determines why and, in material respects, how personal data are processed. A processor acts on documented instructions. Biometric SaaS can blur the boundary if a provider reuses captures for its own model training, determines independent retention or supplies fraud intelligence to other customers.

Before production, obtain evidence for:

• field-level input, output and telemetry;

• prohibited and permitted reuse;

• subprocessor identity and change controls;

• encryption, key control and privileged access;

• incident notification and forensic cooperation;

• request handling for access, correction, objection and deletion where applicable;

• deletion from production, review queues, caches and backups;

• return or deletion at contract end;

• audit rights and evidence, not only a general security warranty.

Biometric.Vision Security describes encryption, access auditing, ISO/IEC 27001 controls and cloud or on-premise deployment. These measures can support a controller's programme. The lawful basis, role allocation, DPIA outcome and retention period remain the customer's decisions.

Cross-border transfer starts with remote access

A transfer map should include more than the primary hosting country. Support personnel, analytics, error traces, content-delivery services, subprocessors and model troubleshooting may expose data abroad. For each route, document the recipient, destination, transfer mechanism or adequacy basis recognised by the Act, onward-transfer limits and enforceable security duties.

On-premise deployment can reduce some transfers. Excessive collection or unjustified use stays a problem wherever the servers sit. Cloud processing can be lawful only once the applicable conditions and safeguards are in place.

Retention must reach derived data

Use an event-based schedule rather than “keep KYC for as long as needed.” Separate:

• failed and abandoned sessions;

• successful verification evidence subject to sector record duties;

• reusable authentication templates;

• fraud-investigation material under a controlled hold;

• technical security logs;

• backups and disaster-recovery copies.

Define the start event, duration, owner, exception and deletion proof for each category. A deletion API that removes the primary selfie but leaves the template and case export is incomplete.

Pre-launch adversarial review

• Could a data-subject request locate every biometric-derived object across controller and processors?

• Does each object have a named purpose, lawful basis and sensitive-data condition?

• Can the controller explain an adverse result without pretending a model score is a probability of identity?

• Does the DPIA cover people most harmed by false rejection and provide a genuine alternative?

• Are every subprocessor, remote-access path and transfer safeguard current?

• Can deletion be demonstrated after the retention event, including backups and support copies?

Biometric.Vision's identity-verification modules can return separate document, liveness, face and AML results inside an orchestrated flow. The customer remains responsible for selecting necessary checks, establishing NDPA compliance, resolving candidates and deciding what happens to the person.

A privacy notice that says “we use biometrics” covers little of this. Mature control needs an evidence system that can answer why each biometric object exists, who touched it, which decision it affected and when every authorised copy will disappear.