Biometric templates, not fingerprint images
Collecting a fingerprint image creates a permanent, high-risk asset. Most attendance workflows only need a template and a match decision. The difference matters under POPIA.
A fingerprint image is a copy of a biometric identifier. It cannot be reissued. If it leaks, the learner cannot get a new finger. That makes it one of the highest-risk records a training provider can hold — and most attendance workflows do not need it.
What a template is
An ISO/IEC 19794-2 template is a mathematical representation of minutiae: ridge endings, bifurcations and their relative positions. It is sufficient to compare two fingerprints. It is not an image and cannot be rendered back into a usable fingerprint by the matcher.
A template is still personal information. It is still special personal information under POPIA section 26. But the minimisation argument is much stronger when the original image never leaves the scanner.
The design rules we apply
- The scanner SDK returns a template and a quality score. The app does not save an image.
- The server stores a template hash, not the template. Enrolment persists a SHA-256 hash, the NFIQ2 score, the minutiae count and the consent reference. The raw template stays on the device; the application database contains neither the template nor an image.
- Matching returns a decision, not a template. The matcher returns a score and a threshold decision. Probe templates are not stored after the call.
- Revocation is technical. Revoking a device invalidates its tokens and queues a wipe instruction; the local roster and templates are destroyed when the device acknowledges the wipe.
- Consent is purpose-bound. Enrolment records the privacy notice version, the purpose and the withdrawal state. A learner can withdraw; the platform records the consequence.
What about liveness?
A template match answers “is this the same finger?” It does not answer “is this a real finger?”. Presentation-attack detection (ISO/IEC 30107-3) is a separate control. A failed PAD result should reject the attendance event, not merely annotate it.
Vendors differ in how they report PAD, and not every USB scanner exposes it. Where a deployment requires PAD, the matcher contract must provide it and the result should be stored with the vendor reference so a verifier can see which control fired. The current RemoteRegister mobile contract records device integrity and environment flags, but it does not claim PAD unless a PAD-capable matcher is configured.
The honest limit
The repository defines the matcher and PAD contracts, and runs a simulator for development. It does not ship a certified matcher. Production matching requires a contracted vendor, a benchmark on your scanner models and a decision about where matching happens.
That is a commercial and certification fact, not a code fact. We would rather state it plainly than let a demo imply a certification that does not exist.
A practical checklist
- Does the scanner SDK expose a template API, or only an image?
- Where is the template encrypted, and who holds the key?
- Does the matcher run inside your environment or at the vendor?
- What happens to the template when a learner withdraws consent?
- Can you demonstrate a failed PAD result rejecting an event?
If you can answer those five questions, you are ahead of most biometric attendance deployments.
This note describes product design and South African statutory context. It is not legal advice. For an assessment of your own evidence process, book a working session.