They take the database
What they hold cannot be turned back into a hand, or presented to any sensor.
Security architecture
Assume the datastore is already gone. Here is what the attacker holds.
What an attacker takes is a short irreversible record per enrolled person, held under authenticated encryption, with no image to reconstruct and nothing that can be presented to a sensor. No raw images are stored anywhere, at any tier. The design goal is simple: make the thing that lasts worth as little as possible to whoever eventually steals it.
Threat model
What an attacker actually ends up with.
Generative tooling available for under fifty dollars a month now defeats video-based KYC, and Indian institutions have documented roughly twenty crore rupees of synthetic-media fraud exposure. Any credential that can be photographed is on a clock. The useful question is not which controls exist, but what an attacker is left holding when one of them fails.
They take a terminal
There is no enrolment data stored on the device.
They present a fake hand
Without blood moving through it, there is nothing to match.
Template irreversibility
A stored template is not a picture of your hand.
What we store is not an image. It is a short mathematical record that describes your vein pattern, and it cannot be turned back into a picture of your hand or presented to a sensor as if it were one.
This is the difference between a template and a stored biometric. A fingerprint image or a face photograph is the credential itself, so a breach hands an attacker the thing they need. Our template is not the credential. On its own it authenticates nothing, which is why we treat it as a liability to be kept small rather than an asset to be collected.
Cryptography and keys
Encrypted templates are only as good as where the keys are not.
Encryption at rest is table stakes. What matters in a review is custody. We hold keys separately from the templates they protect, so a copy of the template store on its own cannot be decrypted, and a terminal can ask for a match without ever being able to read the population it is matching against.
Matching engines
One template, two very different questions.
Deployments are scoped as 1:1 or 1:N before anything is installed, because the choice changes the threshold, the population size and the risk calculus. Conflating them is one of the more common ways a biometric programme goes wrong.
01
1:1 verification
One template against one claimed identity.
Used where the person has already been named by the transaction: a payment tied to an account, a branch verification, an AePS request. The system is answering a yes-or-no question, so the decision threshold can be set tight and the comparison cost is constant no matter how large the enrolled population grows.
Payments, banking, AePS
02
1:N identification
One template against an enrolled population.
Used where the person asserts nothing at all: they walk up to a turnstile and present a palm. This is the harder problem, because false-match probability accumulates across the population, so 1:N deployments are scoped to a defined population per site rather than a national index, and the threshold is set accordingly.
Access control, attendance, transit gates
A gate is the 1:N case: nobody types an employee number, so the reader has to find the person within the site’s enrolled population and return a decision in under a second.
Put this in front of your security team.
We will provide the template format description, the key-handling design and the deployment topology for review, and answer architecture questions directly rather than through a sales channel.