For DPOs & security teams
No raw-data honeypot to defend.
Data minimisation is not a later cleanup exercise. The system begins with local deletion, user authority, context transformation and encryption at rest.
Why HamsaID
Biometrics.
Without the database.
The usual model puts everyone’s biometric template in one place and calls the vault secure. HamsaID refuses to retain raw captures and isolates transformed templates by context.
Side by side
Same simple gesture. Very different risk.
| Question | Centralised biometric model | HamsaID |
|---|---|---|
| Where is the raw capture processed? | Often transmitted or retained within a central service. | At the sensor, then overwritten before the next capture. |
| Where is the biometric template? | Stored in a central repository controlled by one provider. | Stored only after context transformation, encrypted at rest in a per-context partition. |
| Who holds the root of authority? | The platform or account provider. | The user’s phone, through a private seed that never leaves the device. |
| What does the venue receive? | A match tied to a persistent account or identifier. | A purpose-bound result: yes or no, not the biometric. |
| What can one breach expose? | A reusable collection of biometric templates. | Only protected data for the affected context: never raw captures, the user seed, card number (PAN) or a global identifier. |
| Can the user revoke a context? | Usually by deleting or changing an account-level setting. | Yes. Permissions can be scoped, capped, time-limited and revoked. |
| Is there a global identity? | Often a persistent ID that works across contexts. | No. Contexts remain separate by design. |
“Centralised biometric model” describes the common architecture in which a single provider retains complete biometric templates. Individual products vary in implementation.
RAW ≠
STORED.
STORED.
The practical difference
A vault invites the wrong question.
“How strong is the vault?” matters only after you decide to fill it with something irreplaceable. HamsaID asks the earlier question: why build a vault of raw, reusable identity data at all?
Local transformation, encrypted context partitions, a user-held seed and purpose-bound results prevent one reusable identity record from following a person everywhere.
Built for both sides of the buying table
Security can reduce friction instead of adding it.
For commercial & procurement teams
A clearer route to deployment.
Proven integrations and constrained data flows make the hard questions easier to answer early, before they become a six-month audit detour.
Both teams can start with the same two pages: the architecture brief.