Built to be trusted with a face
Handling biometric data is a different kind of responsibility. Here's what that means in practice, organized by what it actually protects.
Data handling
Photo access is gated
The registry photo is never handed to a client before a live face proof succeeds. Validating a NIN/BVN and fetching its photo are two separate, gated steps — a validation response only ever contains a masked name and status.
One embedding per person
Every face is stored as a single canonical 512-dimension embedding per person, not a photo album. When a new proof replaces the old embedding, the prior one is archived to an audit table rather than silently overwritten.
Biometrics deleted first
Deleting an account removes the biometric record before anything else in the deletion sequence — not as an afterthought, and not left behind after the rest of the profile is gone.
Verification integrity
Liveness before matching
A liveness check runs before any face comparison. A printed photo or a screen replay is rejected at that stage — it never reaches the matching engine at all.
Near-ties are never guessed
When a 1:N comparison surfaces two or more identities that score close enough together, the result is flagged for manual review rather than auto-approved or auto-rejected.
Cross-registry consistency
If a person links both a NIN and a BVN, a consistency check confirms both resolve to the same enrolled face — one person can't quietly attach two unrelated registry numbers to the same account.
Access control
Layered staff access
Password, one-time codes, and a fresh face check are standard for staff sign-in. For the most sensitive platform actions, hardware security keys and a second person's approval are required on top of that.
Every check is logged
Every comparison, match, and mismatch is logged. Accuracy, volume, and dependency health are visible on live dashboards, not reconstructed after the fact from scattered records.
Scoped by institution
Institution Console access is scoped to the institution that owns it — branch, staff, and billing data for one institution is never visible to another.
When a verification is disputed
A no-match, an escalation, or a customer complaint doesn't just disappear into a log. Escalated 1:N comparisons land in a review queue an institution's staff work through directly in the Institution Console, and a consumer can request a review of their own account's check from the consumer app. Every dispute is tied back to the original comparison record — the confidence score, the outcome, and who reviewed it — so a resolution can point to what actually happened, not a reconstruction of it.
Bring FaceTrust AI to your business
Talk to us about a pilot, or dig into the API reference to see exactly how it fits your stack.