Four layers, four trust boundaries
The sensor / terminal captures palm modalities, runs liveness and presentation-attack detection on-device, transforms a feature vector under a context-bound transform key, and forwards an attested transformed query. It does not hold the seed, raw frames at rest, or transform keys for other contexts.
The user phone, the Identity Broker, holds the private seed, manages consent, derives scoped pseudonyms, issues authorization capsules, and runs recovery flows. It does not see raw biometric data, the resolution corpus, or merchant account data.
The Biometric Resolution Core matches transformed queries against the partition for the relevant context. It does not hold civil identity, payment account data, the user seed, or capsule signing keys.
The relying party receives only a scoped pseudonym, an access decision or a card-network token reference. It never sees the raw biometric, the transformed template, the seed or any global identifier.
Authorization capsules
The capsule is what makes pay-with-hand possible without the phone being present. The phone issues a scoped, revocable, time-bounded credential, signed by a phone-held key derived from the seed for that relying party and context, and registers it with the authorization registry.
Each capsule encodes the relying party, the purpose (payment / access / presence), the terminal class, the validity window, the risk policy (per-transaction and daily caps for payments), the context-scoped pseudonym, and a revocation pointer. It contains neither the seed nor any biometric material.
At the touchpoint, the resolution core matches the query and the policy layer checks the capsule and risk caps online. Above PSD2 step-up thresholds, the phone is required to re-confirm in-app. Below those thresholds, the capsule alone is sufficient. The phone can be off or absent.
Partitioned resolution and the layered privacy claim (MVP)
Today, the resolution core runs in a hardware-attested execution environment (a confidential-computing enclave such as Intel TDX or AMD SEV-SNP) under HamsaID's operation. Transformed enrolment templates are stored encrypted at rest in per-context partitions; the encryption keys and the context-bound transform keys live inside the enclave.
Partitions are enforced at the storage layer and in the codebase. Cross-partition queries are not just policy-forbidden: no code path can perform them. The schema contains no join key that would link a user's handle in partition M to their handle in partition N.
The honest framing of the MVP privacy claim: the user must trust HamsaID to operate the resolution core honestly within its hardware-attested execution environment. The user does not have to trust HamsaID, any merchant, or any partner with respect to cross-context correlation or unauthorized template export. That is closed by the architecture.
Roadmap: SMPC with phone-contributed re-randomization
The full-fledged version replaces single-operator hardware isolation with Secure Multi-Party Computation across three legally and operationally separate node operators. Templates are secret-shared; no node holds a complete template at any time; the matcher runs as a multi-party protocol revealing only the per-context blind handle to the policy layer.
At enrolment, the phone contributes per-context randomness into the secret-sharing, derived from the seed and then forgotten. Even a coalition of operators that reconstructs templates from two different contexts ends up with values in statistically unrelated re-randomized spaces. This is what makes the full-fledged privacy claim structurally non-collusive rather than operator-trusted.
Pay-with-hand: inside a card-network biometric checkout program
HamsaID is a Biometric Service Provider inside a card-network biometric checkout program. The first European pilot of this kind (PayEye + Empik, Poland, June 2024) establishes regional precedent for the framework.
At enrolment, the program binds the user's context M to a tokenised PAN via the card network's tokenisation service. HamsaID stores only the token reference, scoped to context M. The PAN never enters HamsaID's scope. PCI DSS surface is reduced to the network tokenisation integration points.
At the terminal, after a successful match and capsule check, the Blind Resolution Layer issues a payment authentication assertion to the network tokenisation service with the network token reference, amount and a freshness proof. The tokenisation service presents the token to the acquirer; the acquirer authorises against the issuer; the result returns through the standard payment rail.
Recovery: there is no master key
Today the MVP supports two recovery paths: end-to-end-encrypted device-to-device migration under user-confirmed credentials, and a user-held encrypted backup protected by hardware-backed passkeys or strong recovery factors that HamsaID cannot decrypt alone. If the user loses the device without backup, they re-enrol biometrically and previously issued capsules are revoked from the recovery flow.
The full-fledged version replaces simple secret-sharing with threshold signatures (FROST for Ed25519, BLS-based for post-quantum-aware operations). The substantive improvement: the seed is never reconstructed in one place during recovery. Custodians collaboratively sign a recovery assertion; the new device verifies it and generates fresh seed material locally, bound to the user's enrolment.
There is no HamsaID master key. There is no operator-side mechanism that lets HamsaID, a partner or any backend role reconstruct a user's seed. Recovery only combines artifacts the user holds, devices the user controls, or custodians the user has explicitly chosen.
Compliance posture
GDPR. Biometric-derived material is treated as Article 9 special-category data regardless of whether it is transformed, encrypted or secret-shared. The argument we make is architectural: minimisation, scoping, separation of duties, user-held authority, demonstrable controls. The system is designed to be DPIA-ready from day one of each deployment.
PCI DSS and PSD2 SCA. Both are handled at the network level by the biometric checkout program and network tokenisation. The biometric is the inherence factor; the tokenised PAN bound at enrolment is the possession factor. Above local low-value-transaction exemption thresholds (typically €30 single-transaction with cumulative limits), the architecture steps up to phone-mediated 1:1 verification to re-anchor possession at the moment of payment.
EU AI Act. HamsaID covers consented, scoped authentication and (post-scale) proof-of-humanity, explicitly not public-space remote biometric identification. Any 1:N or 1:few resolution mode is implemented as a scoped tenant search, with no code path capable of querying an unbounded corpus.
What the architecture does not eliminate
Cryptography reduces risk, compartmentalises power and makes misuse observable. It does not eliminate coercion, implementation defects, supply-chain compromise or legal compulsion. A full compromise of an unlocked phone may compromise that user's seed-derived state until revocation or recovery. A phone-lost event without backup may require re-enrolment. In the MVP, the resolution core operator is a trusted party for the biometric layer; that gap is closed structurally in the full-fledged version via SMPC, not by trust.