Questions to ask any face-KYC vendor.

Why it matters

A single accuracy percentage without FMR/FNMR curves, a named dataset and a protocol is marketing. The two error rates trade off through the threshold; you need both to predict production behaviour.

Our answer — verifiable

Yes. Our benchmarks page publishes measured figures with datasets and conditions, our full LFW View-2 results are written up with their caveats, and the eval harness ships in the repository so you can re-run it on your own data.

Why it matters

If you need a sales call to learn the price, you will also need one to learn the price increase. Public pricing is a proxy for how the rest of the relationship will work.

Our answer — verifiable

Yes. Per-check credit costs are on the pricing page, including which checks cost 1, 2, 3 or 5 credits, with 1000 free credits at signup.

Why it matters

For banks and lenders, the strongest data-residency posture is that biometric images never leave your infrastructure at all. Most verification APIs cannot offer this shape.

Our answer — verifiable

Yes. The engine ships as one pure-Rust binary with embedded migrations, runs on your VM, and — as of v0.3.0 — its face models are MIT/Apache-2.0 licensed, so there is no third-party model agreement hiding inside your deployment.

Why it matters

A mandatory capture SDK locks your roadmap to the vendor's supported platforms and release cadence, and makes leaving expensive. It should be a choice, not a requirement.

Our answer — verifiable

Bare REST is the primary interface — send a frame from any client and get a full response back. Capture SDKs exist as optional, pre-release conveniences, and are labelled as such in the documentation.

Why it matters

When an auditor or a court asks how you know the verification result wasn't altered after the fact, 'the vendor's dashboard says so' is a weak answer. A detached signature you can verify offline is a strong one.

Our answer — verifiable

Yes. Every response is Ed25519-signed, the public key is served at GET /v1/verification-key, and webhooks are HMAC-signed. Verification works offline, without us.

Why it matters

Injected virtual-camera streams bypass classical liveness entirely, and they are the growth area in face fraud. A bare live/spoof verdict tells you nothing about whether the frame ever touched a camera.

Our answer — verifiable

Yes — exact-replay hashing, capture-metadata forensics, C2PA manifest verification when present, signed capture payloads, and App Attest / Play Integrity attestation, returned as named signals rather than folded into a verdict. Honest limit: no injection defence on the market is externally certified yet, including ours — we explain why that matters.

Why it matters

“ISO certified” is not a thing for liveness: labs test conformance to ISO/IEC 30107-3 and issue a report at a stated level. A vendor loose with that language will be loose with other claims.

Our answer — verifiable

Today, nothing of ours is externally certified, and we say so plainly: iBeta ISO/IEC 30107-3 PAD testing is planned, not done. When it is done, the claim will name the lab and the level. Full status on the trust page.

Why it matters

Every disputed onboarding eventually becomes a records question: what was checked, when, with what scores, and what was decided. If that record doesn't exist per request, you are reconstructing it from logs during an audit.

Our answer — verifiable

Yes. Every API call writes an audit row — endpoint, outcome, scores, credits — queryable per tenant, with review images retained under your configured retention window.

Why it matters

Biometric images are the highest-liability data you will ever send a vendor. 'Retained for model improvement' buried in a DPA is how your customers' faces end up in someone's training set.

Our answer — verifiable

Images are processed in memory and not retained by default; we do not train on customer images and do not build cross-customer galleries. The full data-handling terms are in the privacy policy — written to be read.