Architecture summary

The two pillars

Pay-with-hand: a user walks up to a sensor, presents their hand, and a payment authorises or a gate opens. No card tap, no phone tap, no PIN at the moment of the gesture. The phone may be in the user's bag, switched off, or absent entirely.

Privacy-preserving architecture: that convenience is not bought by building a central biometric database. The user's private key never leaves their phone; each relying party receives a context-scoped pseudonym, never a global identifier; the biometric layer is structurally isolated from any single relying party.

These two pillars are non-negotiable and coupled. Pay-with-hand without the privacy architecture is a generic payments product; the privacy architecture without pay-with-hand is a research artefact. HamsaID delivers both in the same deployed system.

Four layers

The sensor / terminal captures palm modalities, runs liveness and presentation-attack detection on-device, transforms the feature vector under a context-bound transform key, and forwards an attested transformed query. Raw frames never leave the sensor.

The user's phone, the Identity Broker, holds a private seed in hardware-backed storage, manages consent, derives scoped pseudonyms, and issues authorization capsules. It does not see raw biometric data or the resolution corpus.

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, never the raw biometric, never a global identifier.

Authorization capsules: the pay-with-hand engine

The capsule is the technical object that lets the user be present at the gate or POS while the phone is absent. The phone issues a scoped, revocable, time-bounded credential, signed by a phone-held key derived from the seed for that relying party, 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 policy layer checks the capsule and the risk caps online. Above PSD2 step-up thresholds (typically €30 single-transaction with cumulative limits), the phone is required to re-confirm. Below those thresholds, the capsule alone suffices. The phone need not be present.

Layered privacy claim: why the MVP is honest about it

The user's authority layer (pseudonyms, capsules, consent, audit, recovery) is end-to-end user-controlled and cryptographically unlinkable across contexts. The same person looks like an unrelated subject to two unrelated merchants by construction, because each pseudonym is derived from the seed using the relying party's identifier as a domain-separation input.

The biometric layer is operator-isolated and partitioned. The resolution corpus is split into per-context partitions; there is no schema-level join that would link a user's handle in one partition to their handle in another. Cross-partition queries are not just policy-forbidden: no code path can perform them.

Honest framing of the MVP: the user must trust HamsaID to operate the resolution core honestly inside its hardware-attested execution environment. The user does not have to trust HamsaID, any merchant or any partner with respect to cross-context correlation. That is closed by the architecture, not by a promise.

Roadmap: closing the single-operator trust by construction

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.

Phone-contributed re-randomization at enrolment closes the cross-context correlation gap that partitioning alone leaves open in the MVP. Templates from different contexts use independent per-context masks contributed by the phone and then forgotten. Even a coalition of operators ends up with statistically unrelated values.

Threshold signatures for recovery (FROST / BLS), zero-knowledge proofs over capsule policy and hybrid post-quantum signing arrive in the same phase. Each strengthens an MVP property; none is what makes the MVP privacy-preserving.

Payments inside a card-network biometric checkout program

HamsaID operates as a Biometric Service Provider inside a card-network biometric checkout program. The first European pilot of this kind (PayEye + Empik, Poland, June 2024) establishes the regional precedent for the framework.

Network tokenisation handles the card. At enrolment, the program binds the user's context to a tokenised PAN; HamsaID stores only the token reference, scoped to the context. The PAN never enters HamsaID's scope, which reduces PCI DSS surface to the network tokenisation integration points.

SCA framing is provided at the network level. The biometric is the inherence factor; the tokenised PAN bound at enrolment is the possession factor. Above local low-value-transaction exemption thresholds, the step-up to phone-mediated 1:1 verification re-anchors possession at the moment of payment.

Recovery: there is no master key

MVP recovery supports end-to-end-encrypted device-to-device migration, and a user-held encrypted backup protected by hardware-backed passkeys or strong recovery factors that HamsaID cannot decrypt alone. Without backup, the user re-enrols biometrically and previously issued capsules are revoked from the recovery flow.

The full-fledged version uses threshold signatures so 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 operator-side mechanism that lets HamsaID, a partner or any backend role reconstruct a user's seed. Recovery combines only artefacts 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 is architectural: data minimisation, purpose limitation, storage limitation, integrity and confidentiality, privacy by design and by default, and effective data-subject rights. Every deployment is designed to be DPIA-ready.

PCI DSS and PSD2. Both are handled through the biometric checkout / tokenisation network-level integration. PAN data never enters HamsaID's scope; SCA framing is established by the program at the network level.

EU AI Act. HamsaID covers consented, scoped authentication and (post-scale) proof-of-humanity. Public-space remote biometric identification is explicitly outside the product. Any 1:N or 1:few mode is implemented as a scoped tenant search; the code path cannot be invoked against an unbounded corpus.

What the full whitepaper covers

Threat model and adversary capabilities (insider, network, device, supply-chain).

Cryptographic detail: seed generation in hardware-backed storage, the HKDF derivation tree, capsule issuance and rotation, revocation paths.

Sensor architecture: multimodal palm capture, optical and compute subsystems, attested firmware, on-device feature extraction, edge neural network.

Biometric Resolution Core: MVP enclave architecture, full-fledged SMPC topology, search modes (1:1, 1:few, scoped tenant 1:N).

Identity Broker app and the HamsaID API surface.

End-to-end protocol flows: enrolment, phone-present live authentication, pre-authorized hand-only authentication, recovery.

Card-network biometric checkout integration: accreditation evidence, network tokenisation, step-up handling, revocation propagation.

Performance targets per pipeline stage and FAR/FRR targets per phase.

GDPR mapping, EDPB Opinion 11/2024 implications, EU AI Act alignment, PCI / PSD2 via the biometric checkout program.