Create your seed
The app generates a private seed inside your phone’s secure storage. HamsaID never sees it and keeps no copy.
How it works
A palm scan moves through four deliberately separated layers. Each knows only what it needs to do its job.
Step 0 · Enrolment
Joining works the same way as verifying: the capture is transformed at the sensor and the raw frames are overwritten. What remains is an encrypted, context-bound template. Never a picture of you.
The app generates a private seed inside your phone’s secure storage. HamsaID never sees it and keeps no copy.
One wave at an enrolment sensor. The capture is transformed on the spot and the raw frames are overwritten, exactly as in daily use.
Nothing works until you grant a permission: a place, a purpose, limits and an expiry that you control.
Architecture-level description. Operational enrolment details vary by deployment and require approval before publication.
The architecture
The sensor captures near-infrared palm-vein detail and 3D hand geometry in one gesture. It checks liveness locally, transforms the scan into a protected feature vector, then overwrites the raw frames before the next capture.
Your phone is the root of authority. It holds your private seed, records consent and issues narrowly scoped permissions. Your seed never leaves the device.
Today, transformed templates are matched inside an attested confidential-computing enclave. They are encrypted at rest and isolated in per-context partitions. The target architecture distributes custody across legally separate operators using secure multi-party computation.
The airport, stadium, bank or employer receives a signed result for one defined purpose: access granted, age verified or payment authorised. It does not receive the biometric, the seed or a global identity.
Inside the sensor
The data path is deliberately one-way: raw NIR, RGB and depth frames are processed in volatile sensor memory, transformed for one context and overwritten before the next capture.
Designed boundaries
The current deployment combines local deletion, hardware isolation, encryption and context partitioning. The target architecture adds distributed custody so no matching operator holds a complete template.
Two authentication modes
Mode A / hand only
Approve a context in the app in advance: the merchant, event, purpose, limits and expiry. At the terminal, the hand is enough. The phone can be off or absent.
Mode B / phone mediated
The terminal starts a challenge and the user confirms it on their phone. The consent is bound to that terminal, purpose and moment before the hand completes the session.
Straight answers
Recovery
Your seed lives only on that device, so its permissions stop working. After re-enrolment with a new seed, old contexts are revoked and reissued. Nothing irreplaceable was ever stored.
The basics
Only to set or change the rules. With a pre-authorised context, the hand alone is enough at the terminal.
Uniqueness
Vein patterns are not inherited the way a face is. They differ even between identical twins, and liveness checks rule out photos and replicas.
Robustness
The sensor reads vein patterns beneath the skin in near-infrared light. Surface marks rarely matter, and a fully covered hand falls back to the venue’s normal process.
Your rights
Yes. Revoking a context invalidates its template, and deleting your enrolment removes every stored transform. There is no raw capture anywhere to chase.
Operations
The venue’s standard fallback applies: staff assistance or a document check, whatever the deployment defines. A person is never stranded by the system.
Operational answers vary by deployment. Ask us the harder versions in person.