The whole system, in its parts.

JERIX decides one thing: whether the person in front of the camera is the person a government already signed for. Everything below is in service of that single verdict — how the capture is proven, what the verdict is allowed to leave behind, and what a client can and cannot learn about the people it shares with another client.

Two paths reach the verdict.

They differ in what they can prove. One proves the document and the person. The other proves only the capture — and says so.

The chip path

A passport carries an NFC chip signed by the issuing state. The app reads the chip, the signature chain is verified to a national CSCA root, and the face is taken from the chip’s own signed data server-side and matched against the live selfie. The trust store holds 588 certificates from 112 countries and resolves fully offline — no network, no CRL, no OCSP. A chip whose issuer is not in the store is refused.

The chip path is the passport path.

It is not available on every document a person might hand you. 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 lands on the capture path below. We would rather you learn that here than in the pilot.

The capture path

Where there is no readable chip, the provenance of the capture itself carries the weight. Every frame is hashed and signed on the device with a single-use nonce, so a frame cannot be swapped in or replayed, and on iOS the app is attested through Apple App Attest as a genuine unmodified build on real Apple hardware.

Android captures do not carry hardware attestation. None is configured, which is why an Android capture does not reach the same level as an attested one.

What is retained, and what never is.

Most vendors in this category publish a retention policy. A policy is a promise about a capability they still hold. The two tables below are not a policy — they are the shape of the storage.

Retained
Field	Lifetime	Why it exists
name	Encrypted, indefinitely	The identity the credential belongs to. Never returned to a client unless that client is configured to receive it.
national ID number	Encrypted, indefinitely	Needed to recognise the same person on a later verification, and to hold a lockout across operators.
date of birth	Encrypted, indefinitely	The source of an age answer. A client asking only for an age gate receives a boolean, not this field.
two face-derived hashes	30 days / 7 days	One-way values used for duplicate and lockout checks inside those windows. Not an embedding, not a template, and not reversible to a face.

Never written
Class	What that means
face images	No selfie frame survives the request that produced it.
face embeddings or templates	No biometric vector is written. There is no gallery to enrol into and none to breach.
document images	No passport page, no ID card photograph, no cropped portrait.
chip data	The signed data group is read, verified and used for the match in-request. It is not kept.

Zero retention on images and biometrics, verified on disk.

That is the exact claim, and it is narrower than the one you have probably been read by someone else. We do not tell you we keep nothing: a name, a national ID number and a date of birth are held encrypted and indefinitely, and two one-way face-derived hashes expire on the clocks above. What is gone is the part that is worth stealing and impossible to reissue — the images and the biometrics.

Two clients, one person, two tokens.

A verification does not return an identity. It returns a token derived per client. The same person verifying at two platforms produces two unrelated tokens, and neither platform can test one against the other. Joining the two user bases is not forbidden by contract — it is not computable from what either side holds.

This is the difference between privacy that is declared and privacy that is structural. There is no retention window to configure, no sharing switch in a dashboard to leave off, and no internal tool that could be pointed the other way. A subpoena to one client cannot produce the other client’s view of the same person, because that view was never derivable.

A client also chooses how little it receives. The integration running in production today takes three fields: verified, meets_age and age_gate_min. No name, no ID number, no date of birth, no image.

Same person, two clients

The first client holds one opaque token for this person, and can recognise them again on a later visit.

The second client holds a different token for the same person, and can do exactly the same thing.

Neither side can derive, confirm or search for the other's token, and JERIX publishes no endpoint that relates them. There is nothing to ask and nothing to leak.

Assurance is declared by you and enforced by us.

Each verification earns a level from how it was actually captured, and the level is frozen onto the credential. Your server states the level the action requires. Ours refuses anything weaker — it is not a score you are handed and left to interpret.

Level	Earned by	Typical use
humanity	A selfie with a detected face	Anti-bot, not identity
low	A web capture	Low-risk signup
substantial	An attested native capture	Standard onboarding
high	An attested native capture plus an NFC chip read	Banking, large loans

Liveness and the movement ceremony are measured and recorded on every capture. They do not gate a verdict today. Nothing on this page claims the system blocks a spoofed selfie.

Evidence that outlives the request.

A tamper-evident audit chain

Every verification, refusal and configuration change is written into a chain where each entry commits to the one before it. An entry cannot be edited or removed without breaking the chain from that point forward, which makes an alteration detectable rather than merely prohibited.

Signed webhooks

Results are delivered to your endpoint signed, so your server verifies the signature before it trusts the body. Replays are rejected and requests are rate limited. A webhook you did not verify is a webhook anyone could have sent you — the signature exists so that sentence stops being true.

Cross-operator identity lockout

A person refused for abuse at one operator can be held out across operators without any operator learning where else that person appears. The lockout travels; the identity does not.

What a delivered result carries
Field	What your side learns from it
event	Which thing happened — a verification completed, or was refused.
assurance	The level the capture actually earned. Your rule is applied against this, not against a score you are left to interpret.
verified	The verdict.
subject_token	Your own handle for this person, so you can recognise them next time. It means nothing to anyone else holding it.

Each delivery arrives with a signature and a send time. Your server checks the signature against the body it received and refuses anything sent too long ago, which is the whole of the work: one verification step, then four fields your own code already understands. Larger field sets exist and are configured per client, so you receive the least your product can run on rather than everything we hold.

Headers and exact shapes →

On the device.

The capture happens on a phone, and the phone is where the hardest parts of this are either won or lost.

Apps and SDKs

There are native iOS and Android apps, and verification SDKs for React Native and Flutter. None of them is required: integration is two server-to-server calls and one URL, so the language your product is written in is not a gating question. The SDKs exist for products that want the ceremony inside their own app rather than in a hosted page.

The encrypted wallet

A verified credential lives in an encrypted wallet on the device. Unlock is biometric-only — there is no passcode fallback that a shoulder-surfer or a coerced hand can use instead. A screen-capture guard covers the wallet surfaces, and the wallet is excluded from cloud backup, so a restored backup on another phone does not restore the credential with it.

Not shippedAccount recovery on a new phone. Because the wallet is excluded from backup, recovery has to be re-earned rather than restored, and the flow that does it safely is not built. Today a new phone means verifying again.

Login with JERIX

A person who has verified once can authenticate again from the wallet, with the credential and its frozen assurance level. The limit matters more than the feature: in a mobile browser the hosted login page sends the person to full verification. So this is not yet “verify once, log in anywhere”, and we will not sell it as that until the mobile-browser path stops falling back.

Not shippedSSO, OIDC and Entra endpoints. The signing core ships; the endpoints an identity provider would call do not, which is what blocks an enterprise directory integration today.

There is no certification row on this page.

No SOC 2, no ISO 27001, no penetration test, no iBeta presentation- attack certification. We hold none of them, so none of them appears here as a badge. The first third-party integration has been live since 30 August 2026, and a second, native-SDK integration follows it. That is the whole record.

Capture, verify, decide, delete — step by step →

Bring a passport. Watch the chain resolve.

Twenty minutes with the trust store running offline in front of you, the capture manifest signed on the device, and the images gone before you leave the call.

Request a walkthrough