Biometric systems designed around what you store, not just what you match.
Fingerprint, face and iris capture, matching and anti-spoofing, integrated into the systems your institution already runs — with templates rather than raw images wherever the requirement allows.
Four decisions we make explicit
- Modality choiceArgued from population, environment and assurance level, with a pilot on your own data before rollout.
- What is storedTemplates or images, retention period and deletion evidence — stated before build.
- Exception handlingA named human override path, because biometric systems always have edge cases.
- AuditabilityEvery match, rejection and override written to a trail your auditor can read.
Match the modality to the population and the environment
No single biometric is right everywhere. Field enrolment in dusty conditions and a counter-based verification both need different answers, and the choice should be argued from evidence rather than preference.
| Consideration | Fingerprint | Face | Iris |
|---|---|---|---|
| Typical field use | Enrolment and verification, high volume | Contactless verification, self-service | High-assurance enrolment |
| Hardware footprint | Compact readers, mobile units | Camera-based, works on existing devices | Dedicated capture device |
| User cooperation needed | Finger placement, guided | Minimal | Moderate — positioning and distance |
| Environmental sensitivity | Moisture, cuts, wear affect quality | Lighting and pose affect quality | Largely stable across conditions |
| Anti-spoofing focus | Latent print and replica detection | Presentation-attack detection | Live-eye detection |
| Our default pairing | Primary in most programmes | Verification and assisted onboarding | Where assurance requirements demand it |
Table describes design considerations, not performance claims. Match rates depend on population, capture hardware, thresholds and operating procedure, and are established during a pilot on your data.
Where the template lives matters more than the algorithm
The single most important design decision in a biometric system is what is stored, where, and who can reverse it. We design backwards from that question.
1 · Capture
Fixed readers, mobile kits or existing cameras. Quality checks happen at the point of capture, not later.
2 · Quality and liveness
Spoof and presentation-attack checks before anything is matched. Rejected captures are explained to the operator.
3 · Template and match
Templates generated and matched — 1:1 for verification, 1:N for deduplication against the enrolled population.
4 · Decision and audit
The consuming system makes the decision. Every match, rejection and override is written to an audit trail.
Templates, not images
Where the requirement allows, only irreversible templates are retained; raw captures are discarded after quality assessment.
Human override
An exception path with named authority is part of the design, because biometric systems always have edge cases.
Retention rules
Retention periods and deletion obligations are configured to your policy, and deletion is evidenced.
Indicative architecture for discussion. The final design, storage location and retention rule set are agreed in writing before build.
Privacy is a design input, not a policy PDF
Biometric data sits in a special category under most data-protection regimes, and the reputational cost of getting it wrong is larger than the technical cost of getting it right. Four principles shape every deployment we design.
- Minimisation. We ask for the smallest biometric set that satisfies the requirement. If fingerprint alone meets the assurance level, we do not add face.
- Irreversibility where possible. Templates rather than raw images, so that a database leak is far less likely to become a permanent identity leak.
- Purpose limitation. Data collected for onboarding is not silently reused for attendance, marketing or surveillance. Any secondary use requires a fresh legal basis.
- Data subject routes. A documented path for access, correction and deletion requests, with response ownership inside your organisation.
What we will not do
We do not deploy covert biometric capture, we do not supply systems intended to monitor individuals without their knowledge, and we do not accept a scope where the lawful basis is unclear. If a requirement arrives without a data-protection position, we will say so in writing rather than proceed.
Questions we are asked in procurement
Answers written for the people who have to defend the decision internally.
Do you store fingerprint images or templates?
Can the whole system run on our own infrastructure?
How accurate is it, realistically?
What happens when a legitimate user cannot be matched?
Is biometric data lawful to process here?
Bring us the problem, not a specification.
The most useful first conversation is a technical one: what has to work, by when, and what has already been tried. We will tell you plainly whether it is something we should be doing.