Most identity verification is built on a trade-off nobody questions: send the image to a server, wait, get an answer. It works, but it’s slow, and it means a photo of someone’s face travels across the internet every time they prove who they are.
VerifEye starts from a different premise. If verification runs on the device itself — no upload, no round trip — it can be both faster and more private, because the two problems share a root cause. Server round trips are what make verification slow, and they’re also what put biometric data in transit and in someone else’s infrastructure. Fix the architecture and both problems shrink together.
“The industry treats privacy and speed as a trade-off. On-device architecture is the proof that they’re actually the same problem.”
What “Fast” Actually Means
It’s easy to claim to be the fastest. Realeyes’ engineering team publishes the numbers instead. Section 7.2 of the Realeyes Face Verification whitepaper benchmarks the two components of the pipeline — face detection and face embedding — across precision levels on real consumer hardware: a Samsung S24 (Snapdragon 8 Gen 3) and an iPhone 15 (Apple A16 Bionic).
The headline number is the shift from general-purpose CPU to a dedicated on-device accelerator:
| Configuration | Face detection | Face embedding | Total |
|---|---|---|---|
| Server CPU, single core (baseline) | 17–20 ms | 55–88 ms | ~72–108 ms |
| On-device CPU, FP16 | 12.9–23 ms | 35.1–49 ms | ~48–72 ms |
| On-device accelerator (QNN / CoreML), INT8 | 2.8–6.7 ms | 2.7–3.0 ms | ~5.5–9.7 ms |
(Figures drawn from Section 7.2, “On-Device Performance,” measured over 1,000 inference cycles.)
Routing inference to the phone’s own accelerator; Qualcomm’s QNN on Android, Apple’s CoreML on iOS is what does the real work. The embedding model alone drops from 55–88 milliseconds on CPU to under 3 milliseconds on the accelerator. That’s the step that turns a verification check from something a user waits for into something that just happens.
“A user verified once at onboarding shouldn’t have to prove it from scratch every time.”
Why Speed Compounds
Speed matters beyond the benchmark table because of what happens on the other side of the screen. A verification step that takes noticeable time is a verification step users abandon. One widely cited industry study puts the abandonment rate for slow or complicated identity checks at 68%, up from 40% when the same study began tracking it. Full document-based identity verification vendors report average completion times ranging from roughly 6 seconds on the faster end to 30–60 seconds when manual review is involved. VerifEye’s category, selfie-based verification with no document upload starts from a faster baseline than that by design, and on-device acceleration compounds it further, closing the gap between “verified” and “instant.”
It also matters for hardware most competitors haven’t optimized for. Some liveness vendors’ own published documentation describes capture flows that take multiple seconds to collect 100+ video frames before a match can even run. A legitimate approach for their method, but a very different time budget than a sub-10-millisecond, single-pass embedding comparison. VerifEye isn’t just fast for a face verification product; it’s fast because the whole pipeline was built to fit inside a phone’s compute and power envelope, not to reproduce a server workload on a smaller chip.
Not Every Check Needs the Same Precision
The other half of the story is that VerifEye doesn’t force every deployment to run at maximum precision. The whitepaper documents three configurations — FP32, FP16, and INT8 — and they trade off model size, latency, and accuracy in predictable ways:
- FP32 — full precision, for server or on-premises deployment where compute isn’t constrained.
- FP16 — roughly half the model size and CPU latency of FP32, with a measured 0.996 cosine similarity against FP32 output — effectively lossless for verification accuracy. This is the default for most on-device use cases.
- INT8 on accelerator — the smallest footprint (as little as 42 MB for the embedding model) and the lowest latency, sub-3ms, at the cost of requiring platform-specific tuning to fully preserve accuracy.
“Not every decision needs six decimal places of precision. It needs the right amount, running as fast as that amount allows.”
That range matters because not every use case is asking the same question. A financial re-authentication needs a tight, high-confidence match — that’s a job for FP32 or well-tuned FP16. But confirming someone is clearly over 18, or clearly not a bot trying to farm survey rewards, doesn’t need the same bar. Those are coarse, high-confidence-at-a-glance decisions, and customers can deliberately run them on the fastest, most compressed configuration without over-engineering accuracy the use case never asked for. Speed becomes a dial customers turn to match the actual risk in front of them, not a fixed cost everyone pays regardless of need.
The Takeaway
On-device deployment was, until recently, a compromise: private, but slow enough that customers reserved it for their highest-stakes flows. VerifEye’s benchmarked numbers — sub-10-millisecond end-to-end inference on stock consumer chips, with a documented, tunable path between accuracy and speed, argue that the compromise no longer holds. Fast and private aren’t opposing goals to balance. On-device, they’re the same design decision.