There is no badge row on this page. We hold no SOC 2, no ISO 27001, no penetration test report and no iBeta result, and the second half of this page says so at length. What is here instead is the architecture, stated precisely enough that you can check it during a walkthrough rather than take it on trust.
Start here, because everything else on the page is downstream of it. The correct claim is zero retention on images and biometrics, verified on disk — not that we keep nothing, which would be false.
| Data | Retention | Form |
|---|---|---|
| face images | None. | Never written as a stored artefact. |
| face templates | None. | No embeddings, no templates, no gallery. |
| document images | None. | Read, used, gone. |
| chip data | None. | Verified in the request, not stored. |
| face-derived hash A | 30 days. | One-way. Supports re-recognition inside the window. |
| face-derived hash B | 7 days. | One-way. |
| name, national ID, date of birth | Indefinite. | Encrypted at rest. This is the row other vendors' pages omit. |
| per-client token | Indefinite. | One-way, and different for every client. |
Two code paths write a temporary clip for the duration of a request. It does not survive the request. That detail is the reason we say zero retention rather than “nothing is ever written to disk” — the second sentence is the kind of thing that fails a review, and it is not true.
There is no retention window to configure, no toggle to get wrong in an onboarding call, and no per-tenant override. The images are not kept because the system has nowhere to keep them. We verify this on disk and we will verify it in front of you.
A client can be configured to receive only verified, meets_age and age_gate_min. The integration in production today takes exactly that and nothing else.
Two independent mechanisms, neither of which is a judgement about how good a picture looks.
Offline trust chain
Verified with the interface down. Nobody is told that a passport was checked, because there is nobody to ask. If the chain cannot be built from the store on the machine, the chip is refused.
A chip signature needs the state’s private key. That asymmetry is the whole argument, and it does not improve or decay with model quality.
The parts a security officer will ask about in the second half of the call.
Every vendor in this category has this list. Most do not publish it, and the list is usually what the second meeting is spent extracting. Here it is in advance.
No Type I and no Type II. No audit window has been opened and no auditor is engaged.
Not shippedSOC 2. Blocked on engaging an auditor, which is a funding and sequencing decision, not a technical one. We will not show a badge we do not hold.
No certificate, and no documented information security management system of the kind the standard requires.
Not shippedISO 27001. Blocked on the management-system documentation that certification is mostly made of.
None commissioned. There is no report to share under NDA, and if somebody offers you one with our name on it, it is not ours.
Not shippedPenetration test. Blocked on commissioning. If your procurement requires a test before signature, say so early — that is a sequencing conversation we can have honestly.
No Level 1 and no Level 2 evaluation. We therefore quote no presentation-attack detection rate, because any number we gave you would be our own and unverified.
Not shippediBeta ISO 30107-3. Blocked on evaluation. Until it exists, the provenance mechanisms above are the argument and the liveness signals are not.
The Android app ships and signs its capture manifest. Hardware attestation is not configured, so an Android capture does not carry the device proof an App Attest capture carries.
Not shippedAndroid hardware attestation. Blocked on provisioning.
Liveness and the movement ceremony are measured and recorded on every capture and they decide nothing. Two screen-and-print detectors compute on every capture and neither gates a verdict. We do not claim the system blocks a spoofed selfie, and a page that claimed it would be a page you should discount.
Not shippedScreen and print detection as an enforcing control; liveness enforcement. Blocked on a false-reject rate we are willing to publish.
The verification core runs offline, which is the architecturally hard part of an air-gapped install. Packaging it is not done, and there is no reference installation anywhere. Separately, the on-device wallet has no escrow, so a replaced phone is a new verification.
Not shippedOn-premises packaging — zero reference installations. Account recovery on a new phone — blocked on a recovery path that does not become the weakest way in. Published data-retention policy — blocked on drafting, not on behaviour.
Two founders, pre-certification, one live third-party integration since 30 August 2026. We would rather you found this list on our own site than in the third meeting.
Nothing above needs to be believed. Each line has a way to be tested, and most of them fit inside twenty minutes.
| Claim | Your test |
|---|---|
| offline trust chain | Disconnect the machine and run a passport. The chain still resolves, or the chip is refused. |
| unknown issuer refused | Present a chip signed outside the certificate store and watch it refuse. |
| zero retention | Inspect the disk after a completed verification, with us watching. |
| single-use nonce | Replay a capture manifest into a second session. It is refused. |
| token isolation | Verify the same person under two client identities and compare the two tokens. |
| no phone-home | Watch the egress during a verification. There is nothing to see. |
| signed webhooks | Alter one byte of a delivery body and confirm your verification fails. |
We will answer it with the gaps marked rather than smoothed, which is the only version of this document worth having.
Request a walkthrough