Ten questions,answered the way procurement needs them.

The integration surface is two server-to-server calls and one URL, with no SDK requirement and no constraint on your backend language. Your server starts a verification, you send the person to a URL, and a signed webhook returns the result — which can be narrowed to verified, meets_age and age_gate_min alone, with no name, no ID number, no date of birth and no image crossing into your systems. React Native and Flutter SDKs exist if you want the capture inside your own app instead, and the first third-party integration has been live since 30 August 2026.

No. JERIX holds no SOC 2 Type I or Type II, no ISO 27001, no third-party penetration test and no iBeta ISO 30107-3 result, and there is no badge row on this site because there is nothing to put in it. If a certification is a hard gate in your procurement, this is the answer that disqualifies us, and it is better read now than in week six.

Not shippedAll four are unstarted or blocked, each for a named reason: written policies and an engaged auditor for SOC 2, the management system for ISO 27001, cost and scope for a credible penetration test, and gating detectors for iBeta. What exists instead is architecture you can inspect in a walkthrough, which is evidence rather than attestation and not a substitute for one.

No. The chip in an Israeli ID card is government-locked and cannot be read by anyone outside the state's own systems, so no vendor — us included — is reading it, whatever a competing deck says. An Israeli ID card is therefore a photo-only verification in JERIX: the document is captured, read and matched, and it does not earn the chip-backed assurance level, because nothing cryptographic was proved. The chip-backed path is the passport: an NFC read whose signature chain resolves to a national root offline, against 588 certificates across 112 countries, with no network call, no CRL and no OCSP.

Not by detection, and we will not claim otherwise. Liveness and the movement ceremony are measured and recorded with every capture, and they decide nothing — no verification is refused because a detector disliked it. What actually resists a synthetic face is provenance: a state's signature on the passport chip, from which the reference face is taken server-side; a capture manifest hashed and signed on the device with a single-use nonce, so frames cannot be swapped or replayed; and Apple App Attest, proving a genuine unmodified app on real Apple hardware.

Not shippedAndroid hardware attestation is not configured, so an Android capture carries the signed manifest and the nonce but no device attestation. Screen and print detection computes on every capture and gates nothing, blocked on a threshold defensible to a security officer, which needs labelled attack data rather than an opinion.

They verify again from the beginning. The wallet is encrypted on the device and unlocks only with the holder's own biometric, which is the point of it and also the reason a replaced, lost or wiped phone cannot be recovered into. Note the related limit while you are modelling this: in a mobile browser, the hosted login page sends the person to full verification rather than recognising them, so “verify once” holds inside the app and not in every browser.

Not shippedThere is no account recovery on a new phone. Blocked on a recovery design that does not reintroduce what was removed — every quick version works by keeping a biometric centrally or escrowing a key that opens a holder's wallet without the holder, and either one would make the architecture argument false.

One of the two founders — Michael Livshitz or Ron Hillel. There is no sales engineer between you and the system, which means the person answering your security officer's questions is the person who built the thing being questioned, and can be wrong in writing rather than vague in person. A walkthrough covers what works and then the unshipped list, because a gap that blocks your procurement is cheaper for both of us in the first meeting.