Designing identity verification for bad cameras and slow networks

Identity verification is sold as a machine learning problem. In practice, most of the work — and almost all of the failure — happens before any model runs.

A genuine customer holding a genuine document gets rejected because of glare, because their phone compressed the image to nothing on a weak connection, or because they photographed the document at an angle that cropped a corner. The model behaved correctly. The system still failed the person it was meant to serve.

Capture is the accuracy problem

The cheapest way to improve verification accuracy is to stop accepting images that were never going to work.

Grade the capture on the device, before upload:

• Blur — variance of the Laplacian, rejected below a threshold
• Glare — blown-out highlight regions over the document surface
• Framing — all four document edges detected within frame
• Resolution — enough pixels across the text zone to read it

Then, critically, tell the user which one failed. "Move out of direct sunlight" is actionable. "Verification failed, please try again" teaches them nothing, so their second attempt has the same problem as the first, and their third attempt is a support ticket.

This is not a machine learning improvement. It is an interface decision, and it outperforms most model changes.

Assume the network is hostile

Verification flows are frequently completed on mobile data, sometimes on a connection that drops mid-upload.

Several consequences follow.

Compress deliberately, on the client. If you do not, the browser or the OS will do it for you, at a quality setting chosen for photo sharing rather than text recognition. Resize to the minimum resolution your extraction actually needs and control the quality yourself.

Make uploads resumable. A 3MB capture over a poor connection will fail sometimes. Restarting from zero after ninety seconds is how people abandon onboarding.

Never block the interface on a synchronous verification call. Accept the submission, return a reference, and notify asynchronously. Verification can legitimately take thirty seconds — or four hours if it needs human review — and a request-response API cannot express that honestly.

Scores, not verdicts

A face matching model returns a similarity score. The temptation is to compare it to a threshold immediately and store the boolean.

Store the score. All of them.

Thresholds are business decisions and they change. When someone asks to loosen matching because too many genuine customers are being rejected, stored scores let you replay the proposed threshold against every historical case and see exactly what it would have changed. Stored booleans let you guess and find out in production.

The same applies to extraction. Per-field confidence beats a single document-level score, because the useful action is field-specific: an uncertain expiry date and an uncertain surname warrant different responses.

Validate documents against themselves

Many identity documents carry internal structure that can be checked without any external data source — machine-readable zones with check digits, fixed field formats, dates that must be ordered sensibly.

A document whose OCR parses cleanly but fails its own checksum is a stronger fraud signal than almost anything a general-purpose model will tell you. It is also nearly free to compute.

The review queue is the product

Some percentage of cases will be genuinely uncertain. What happens to those decides whether your system is usable.

Auto-rejecting uncertain cases optimises the wrong thing. It produces a clean automation rate and a queue of angry customers who were, in fact, exactly who they said they were.

Build the review interface properly and build it early. A reviewer needs, on one screen: the document, the selfie, every extracted field with confidence, which specific checks failed, and why the case escalated. Add keyboard shortcuts. Someone will work through hundreds of these.

Building the queue first has a useful side effect — it forces every upstream stage to explain itself, because a reviewer staring at a blank rationale is a bug report.

Appeals are a flow, not an inbox

People will be wrongly rejected. This is certain, and designing as though it is not is how a verification system becomes a reputational problem.

Make appeals explicit: a rejected user submits a new capture against the original case, and a reviewer sees both attempts together with the original decision. If your appeal process is "email support", it is not a process.

Retention is a design constraint, not a policy document

Biometric material is among the most sensitive data a business can hold, and holding it indefinitely is a liability that grows quietly.

Separate what must persist from what must not. The decision record — scores, extracted fields, checks, reviewer actions, timestamps — is the audit trail and should outlive the raw capture. The raw images and biometric templates should expire on a schedule enforced by storage lifecycle rules, not by a cleanup job somebody remembers to write.

Build the deletion path at the same time as the storage path. It is far harder to add afterwards, and "we will handle retention later" reliably means never.

What this looks like shipped

We built a service along these lines for a marketing platform that was reviewing identity by hand: an API the main application calls, a decision split into ten independently scored steps, and two explanations written for every step — one for the operator working the queue, one for the person about to be told the result.

That second field is the one that changes the numbers. A rejection that says your date of birth is not readable produces a retry. A rejection that says verification failed produces a support ticket, and then a churned customer.

The full breakdown is in the case study.

What we do not claim

Osynova builds verification workflows. We are not an accredited identity provider and hold no regulatory certification for identity services. Where a certified data source or licensed check is required, we integrate the provider you choose and build the workflow, review tooling and audit trail around it.