# TechTitans POS — Customer Biometric Verification Feasibility (assessment only)

**Date:** 2026-11-12 · **Status:** ASSESSMENT ONLY — nothing in this document is implemented. The C8 customer photo feature stores a plain operational photo and performs **no** face detection, embedding, template extraction, matching or identification. Any biometric capability requires a **separately approved** design, DPIA sign-off and legal/privacy review before a single line is written.

> **Guardrail (in force now):** do not implement biometric matching, silent identification, or automatic face-based profile opening. The C8 photo is for human visual confirmation only.

## 1. Scope being assessed
A strictly **optional, customer-initiated, 1:1 verification** ("is this person the owner of THIS account?") — e.g. a returning customer asks to confirm their own identity. Explicitly **out of scope**: 1:N identification (searching a face against the customer base), live-feed/"walk-in" recognition, surveillance, emotion/age/demographic inference, and any processing of bystanders.

## 2. Necessity & proportionality
- **Necessity:** TechTitans already has strong, non-biometric identifiers (customer number, phone, email, IPTV MC ID) plus the C8 photo for human confirmation. Biometric verification must demonstrate a *specific* problem these cannot solve (e.g. high-value account takeover) — convenience is not sufficient justification for processing a special category of data.
- **Proportionality:** biometric data is "special category" / sensitive under GDPR Art. 9, PIPEDA and Québec Law 25; the intrusion is high. A 1:1 self-verification at the counter is the **least** intrusive biometric form, but must still be weighed against the non-biometric alternatives (§7) which likely suffice for most cases.
- **Default position:** proceed only if a documented business case shows non-biometric methods are inadequate for a defined, narrow use.

## 3. Express opt-in
- **Separate, explicit, informed, freely-given** consent — never bundled with the C8 photo consent, never a pre-ticked box, never a condition of service. A customer may use the store without ever enrolling.
- Enrolment and each verification must be **customer-initiated** on a staff-facing prompt the customer can decline; withdrawal of consent is one action and triggers deletion (§9).
- Clear notice: what is captured, why, where it is processed, retention, the human fallback, and how to withdraw.

## 4. Privacy Impact Assessment (DPIA) — required before any build
Must cover: lawful basis (explicit consent + possibly legitimate-interest balancing for fraud), data flows, the special-category justification, risks to the individual (false accept/reject, discrimination/bias across skin tone/age/gender, function creep to 1:N, breach of biometric templates), mitigations, retention/deletion, cross-border/vendor processing, and residual-risk sign-off. Québec **Law 25** additionally requires notifying the CAI *before* putting a biometric system into service.

## 5. False matches (FAR) & missed matches (FRR)
- No matcher is perfect: a **false accept** could expose one customer's data to another; a **false reject** inconveniences the legitimate customer. Thresholds trade these off and **must be tuned conservatively for 1:1** (bias toward false reject, which fails safe to the human fallback).
- **Demographic bias** is well-documented (NIST FRVT) — error rates vary by skin tone, age and gender. Any vendor must publish per-demographic accuracy; unequal error rates are a discrimination risk and a blocker.

## 6. Human confirmation (mandatory)
Biometric output is **advisory only**. A positive match never *automatically* opens a profile, authorises a refund, or unlocks an account — a staff member makes the final decision with the existing non-biometric checks. A negative match routes to the human fallback, not a refusal of service. There is **no silent / automatic** action anywhere in the flow.

## 7. Non-biometric alternatives (preferred)
- Customer number + a knowledge factor (recent order, phone on file).
- One-time SMS/email code to the contact on record.
- The **C8 photo** for human visual confirmation (already implemented — covers most "is this the right record?" needs).
- Government ID check for genuinely high-risk actions.
These should be exhausted/justified-inadequate before biometrics is considered.

## 8. Security & access controls (if ever built)
- Biometric **templates**, never raw face images, and only when unavoidable; encrypted at rest with a dedicated key, strict tenant isolation, and access limited to a narrow, audited role (separate from `customers.view`/`manage`).
- On-device/edge or in-tenant processing strongly preferred over third-party cloud; no training on customer data; no secondary use.
- Full audit of every enrolment/verification; rate-limiting and liveness/anti-spoofing to resist photo/video replay.

## 9. Retention & deletion
- Templates deleted immediately on consent withdrawal, account closure, or after a short, defined inactivity window; verification logs minimised and time-boxed.
- Deletion must be verifiable and cascade to any vendor/backup. "Delete on request" is the baseline the C8 photo already honours; biometric data needs stricter, automatic expiry.

## 10. Vendor / cloud processing
- Any processor requires a DPA, documented security posture, published per-demographic accuracy, data-residency guarantees (CA/EU as applicable), no-secondary-use and no-model-training terms, and breach-notification SLAs. Prefer no vendor at all (in-tenant) for special-category data.

## 11. Independent review
Before implementation: independent **legal/privacy review** (GDPR / PIPEDA / Québec Law 25 as applicable), DPIA sign-off, and — for Québec — CAI pre-use notification. Security review of the template store and matcher. Sign-off recorded alongside the approved design.

## 12. Recommendation
**Do not build biometric verification now.** The implemented non-biometric identifiers + the C8 photo (human confirmation) meet the current need. Re-evaluate only with a concrete, narrow business case, and then only through a separately-approved design gated on the DPIA, bias evidence, and independent legal/privacy sign-off above. Until then the standing guardrail holds: no face embeddings, no matching, no silent identification, no automatic face-based profile opening.