On this page
Short answer. You can verify identity without storing biometrics by processing images in memory, keeping only the decision, scores, a keyed hash of the ID number and a consent record, and deleting everything else when the check ends.
Why holding less is a feature
A database of faces and ID photos is the most dangerous asset a fintech can own. A password can be reset; a face cannot. Under the Nigeria Data Protection Act 2023 you are expected to collect only what you need and keep it only as long as you need it. Data you never store cannot leak, cannot be subpoenaed in bulk, and cannot become a liability when your retention policy changes.
What an audit actually needs
Regulators and your own risk team need to answer: who was verified, when, by what method, with what outcome, and on what consent. None of those answers requires the face itself.
| Keep | Delete |
|---|---|
| Decision (accept, review, reject) | Selfie frames and video |
| Scores, confidence and model version | Facial embeddings and templates |
| Keyed hash of the identity number | Document images, once OCR is done |
| Timestamp and verification tier | Raw identity numbers |
| Consent record: time, IP, wording version | Anything sitting in request logs |
The minimal-data flow
- Capture consent. Record the time, the version of the notice shown and the IP address.
- Receive the images in memory. Do not write them to disk, object storage or a queue.
- Run the checks. Quality, liveness, document read, face match.
- Persist the evidence, not the images. Store the result, scores and a keyed hash of the ID number.
- Return the decision and discard the inputs. Treat deletion as part of the request, not a nightly job.
The places biometric data leaks by accident
- Request logs and APM traces that capture multipart bodies or base64 images.
- Crash dumps and error trackers that attach the failing payload.
- Retry queues that park an upload until a worker picks it up.
- Staging copies made so a developer can reproduce a bug.
Audit these before you trust a "we don't store images" claim, including your own.
Handling a dispute without the photo
If a user says "I was wrongly rejected", you do not need the stored selfie to help them. You have the scores and the reason code, and the safest remedy is to let them run the check again with better capture guidance. That is faster, and it avoids retaining a face just in case.
Controller and processor roles
When you submit someone's data for verification you are normally the data controller: you decide why it is collected and you owe the person notice. The verification provider acts as your processor. Make sure the provider's retention matches what you told your users. For a keyed hash of identity numbers, read Storing Identity Numbers as Hashes.
How IDNexus is built around this
Selfie frames, embeddings and document images are processed in memory and deleted as soon as the check ends. We retain the verification result for seven years for audit and keep identity numbers only as hashes. The privacy policy lists every category and its retention period.
Verification that keeps almost nothing
IDNexus processes selfies and documents in memory and deletes them when the check ends. Only the result and hashes are retained.
Create account