Your server declares, ours refuses
A request states the assurance level the action requires — humanity, low, substantial or high. A verification that earned less does not come back as a weaker yes. It does not come back as a yes.
Capture. Verify. Decide. Delete.
Four steps, in that order, with the deletion as a step rather than a policy. The interesting part is not that each one happens — every vendor has four steps — it is what each one is allowed to assume about the step before it.
Capture
A camera cannot tell you where its frames came from. So the frames are made to say it themselves, on the device, before anything leaves it.
Every frame is hashed and signed on the device as it is taken, under a single-use nonce issued for that one capture session. A frame cannot be inserted, reordered or replayed into the set, because the nonce it would have to be signed under has already been spent. On iOS the app itself is attested through Apple App Attest, which establishes that the signing was done by a genuine, unmodified build running on real Apple hardware rather than by something wearing its name.
That is what makes a live capture distinguishable from a gallery upload, a replayed frame, or a virtual camera.
Notice the shape of that claim. It is not that the picture looks real. A graphics model can make a picture look real, and in June 2026 one did, through several banks’ remote checks. It is that the picture arrived with a provenance a graphics model cannot produce, because producing it requires a key held in hardware the attacker does not control.
Android captures do not carry hardware attestation — none is configured — so an Android capture is signed but not attested, and it does not reach the levels an attested capture reaches.
| Signed over | What it rules out |
|---|---|
| session_nonce | One nonce, issued for this one capture session and spendable once. The same set presented a second time does not verify. |
| frames | Every frame hashed as it is taken. A frame that was not in the set when it was signed cannot be slipped into it afterwards, and the order cannot be changed. |
| attestation | On iOS, Apple App Attest: the signing was done by a genuine, unmodified build on real Apple hardware. Android captures are signed but not attested. |
| signature | Made with a key held in the device. Whoever sends you a picture instead does not have it. |
None of this depends on the picture looking convincing. It depends on where the picture came from, which is the one thing a graphics model cannot forge.
Verify
Where there is a passport, the state has already done the hard part and signed its own answer. Verification is the work of following that signature all the way back to the state, without asking anyone's permission to do it.
| Link | What is checked |
|---|---|
| chip signature | The data groups on the chip are signed by the issuing state. The signature is checked against the document signer certificate the chip itself carries. |
| signer to root | That document signer is chained to the issuing country's CSCA root in the local trust store. A chip whose issuer is not in the store is refused — not flagged, not scored, refused. |
| store size | 588 certificates from 112 countries, held on the device and on the server that completes the match. |
| network calls | None. No CRL fetch, no OCSP query, no vendor callback. The whole chain resolves offline, which also means it resolves identically on a plane and inside an air-gapped deployment. |
| face source | The portrait used for the match is read out of the chip's own signed data server-side. It is not scanned off the printed page, so there is no page to forge. |
A forged image needs a graphics model. A chip signature needs the state’s private key.
Be clear about the boundary, because it decides what a pilot will actually look like: the chip path is the passport path. An Israeli ID card chip is government-locked and cannot be read at all, so every Israeli ID card verification is a photo-only verification and runs on the capture path from step 01. That is the single most important sentence on this page for an Israeli deployment, and it is the one most likely to be missing from a competitor’s.
Decide
The verdict is not a number handed to you to interpret. It is a level, earned by how the capture actually happened, and enforced on our side against the level you declared.
You receive the least you can act on
The integration in production today is answered with three fields and nothing else: whether the person verified, whether they meet the age gate, and what that gate was. No name, no ID number, no date of birth, no image. A client that holds nothing identifying has nothing identifying to lose.
A refusal is a refusal
An unknown chip issuer, a manifest that does not verify, a nonce already spent, a locked-out identity: these end the verification. They are not scored into a borderline pass for you to triage.
Back to your server
Your server receives verified, assurance, meets_age and age_gate_min — and nothing else.
Four answers your own code already knows what to do with. Larger field sets exist and are configured per client, and the handle you get for the person is derived for you alone, so the next platform they verify at holds a token unrelated to yours.
Not shippedScreen and print detection. Two detectors compute on every capture and neither decides anything yet. Liveness and the movement ceremony are likewise measured and recorded, and gate no verdict today — which is why nothing here says the system blocks a spoofed selfie.
Delete
The images and the biometrics do not survive the request that used them. Zero retention on images and biometrics, verified on disk.
No selfie frame, no document image, no chip data, and no face embedding or template. There is no gallery to enrol into, which is why there is no gallery to breach, and no re-verification revenue line that depends on keeping one.
What remains is narrower than “nothing”, and we will not round it up. A name, a national ID number and a date of birth are held encrypted and indefinitely. Two one-way face-derived hashes expire after 30 days and 7 days. Those are not images and they are not biometrics you could reconstruct a face from — and they are the whole of it.
Not shippedA published data-retention policy. The retention above is what the system does; the document that commits us to it in writing is not finished.
VERIFIED, THEN GONE
Four steps, and one of them is the product.
Capture, verify and decide are table stakes; every vendor you are comparing does all three. Delete is the one that costs an incumbent something to copy, because their retention is what they charge for.
The same system described as parts rather than steps →Watch the images not be there.
A real passport, the trust chain resolving with the network off, and then the disk, afterwards, with you looking at it.
Request a walkthrough