idcheckSecurity you can verify, not just trust.
Every verification produces a hash-chained, tamper-evident audit trail. Biometrics are processed on our own infrastructure and never touch yours. This page describes what we actually do — including the parts we're still honest about improving.
Last updated: July 26, 2026How every verification is protected
These are properties of the system as built — not aspirations on a roadmap.
Append-only, hash-chained audit log
Every event on a verification — consent, captures, checks, scores, the decision — is chained to the previous event's SHA-256 hash. Any retroactive edit breaks every subsequent hash, and the chain can be recomputed on demand.
Client/server cross-decode
The PDF417 barcode is decoded in the browser and decoded again independently on the server from the uploaded image. If the client-provided data doesn't match the server-decoded data, the client was tampered with — a hard fraud signal.
Consent before capture
Two affirmative checkboxes — a biometric release and a recording consent — are captured and logged before any camera or microphone access is requested. The policy text is versioned and the version hash is stored with the consent.
Self-hosted biometric inference
Face detection, matching, and liveness run on our own GPU infrastructure — not a third-party API. Biometrics never leave our environment, and because capture runs on our hosted flow, they never touch merchant servers either.
Encryption in transit
All traffic between the capture client, the API, and merchant backends runs over TLS. Stored media is served only through short-lived signed URLs.
Short, enforced retention
Raw media and biometrics are retained 30–90 days after a decision — with hard ceilings from biometric privacy law (1 year CUBI, 3 years BIPA, 24 months Colorado). Decision records are kept 5 years for AML obligations. Details on our privacy page.
What we don't claim
Security marketing tends to overclaim. We'd rather you know where the edges are:
- Liveness is a pre-filter today. Our self-hosted liveness stack (texture analysis, screen-recapture heuristics, micro-motion, blink detection) rejects common presentation attacks — printouts, screen replays, basic masks — before face matching runs. It is not an iBeta-certified engine. A certified engine (FaceTec/Oz/Innovatrics/iProov class) is planned behind the same API interface.
- Injection defense deepens with the native SDK. Device attestation and virtual-camera/root/hook detection ship with the native SDK phase. The web phase today relies on capture UX and server-side signals — we document this openly in the merchant docs.
- SOC 2 is on the roadmap, not the wall. Our Type II program is in progress; the audit-chain and access-control design was built to map to the trust criteria.
Hard declines are reserved for cryptographic and integrity failures — a client/server barcode mismatch, detected injection, an expired document — never for a single soft signal.
Found something? Tell us.
We would rather get a bug report from you than from a fraud ring. If you've found a vulnerability in idcheck.now — our API, hosted flow, SDK, or this site — email security@idcheck.now with:
- What you did and what you expected versus what happened
- Steps to reproduce, including any request/response captures
- Whether the issue touches verification decisions, biometric data, or audit integrity
We acknowledge reports within one business day, keep you updated as we investigate, and credit researchers (with permission) once a fix ships. Our machine-readable contact lives at /.well-known/security.txt, and if you want to test our detection stack head-on, that's what the public challenge page is for.
Your first 100 verifications are free.
Five lines of JavaScript. No credit card. A decision you can defend.