Document Upload vs Live Capture: What 29 Million Verifications Show

A growing number of verification vendors have stopped allowing it. They want a live capture taken inside the flow, and they describe the restriction as a security measure.

On the security part they have a case, and we will make it more bluntly than most vendors would in public. What almost nobody does is work out the other side of the ledger, which is that a ban turns away around 3.6 genuine customers for every fraudulent one it stops. That ratio holds whether you verify forty thousand people a year or forty million.

The right answer depends on your device mix, your risk appetite and the sector you operate in, and it is not the same answer for a consumer wallet and a private bank. These are the numbers the decision turns on, measured rather than asserted.

Uploads carry four times the fraud, and twice the rejections

In a sample of 29 million document checks from the first half of 2026, forensic checks caught fraud on 17.37% of uploaded documents and 4.03% of live captures. Those two figures are made of three things, and it is worth seeing them separately.

Every rate is a share of that channel's own attempts, so each block adds up to the bold row beneath it. The three fraud categories overlap very slightly, which is why they come to 17.39 against a measured 17.37.

Read the two bold rows together and the shape of the problem changes. We reject uploads 2.4 times as often as live captures, but we catch fraud on them 4.3 times as often, and the difference between those multiples is photo quality.
Of the 22 points separating the two rejection rates, 13.34 are fraud and 8.72 are blur, glare, expired cards and photographs of the wrong page. So anyone quoting the full 22 points as a security gap overstates it by about two thirds.

That second block also punctures the idea that uploads are the frictionless option. One upload in five fails for reasons that have nothing to do with fraud, so a flow that takes files without checking them at the point of submission has swapped one kind of drop-off for another.

The reason sits in the mechanics rather than in anything about the people involved. Editing a document requires a file to edit, and a live capture never produces one. The image travels from the physical document to the camera to a decision without ever resting somewhere it could be opened, which is why file-based manipulation appears on the upload path and almost nowhere else.

Most upload fraud is copies and screenshots, not forgery

Ask most risk teams to picture upload fraud and they will describe a doctored passport, cloned hologram, altered date of birth. Look again at where that 17.37% comes from.

Of every 100 documents uploaded, around 9 are not original, 7 are photographs of a screen, and 1 has been altered or edited. Put another way, forgery is 7.2% of the fraud caught on the upload path. Copies and screen photographs are the rest.

Most policies are written against the opposite distribution. More than 90% of what we catch was never a live document at all, meaning a copy, a screenshot, or an image that has circulated long enough for someone to have seen it before.

These are the failures detection handles well. A photograph of a laptop screen carries moiré patterns and reflections that survive any amount of care on the fraudster's part, and a document already in circulation can be matched against documents already in circulation. The seventeen-fold figure on altered documents makes the better headline, but it describes just over 1 upload in 100, and building policy around it means solving for the wrong attack.

A ban stops the fraud you were already stopping

There is a quieter problem with the ban, and it holds even if you accept every risk figure above.

We caught the fraudulent uploads inside that 17.37%. A ban prevents nothing detection had not already prevented, so whatever it is worth sits entirely in the fraud that slips past today, and nobody in this industry publishes that number.

Your device mix decides what a ban costs you

In this sample, 9.8% of genuine completions arrived as uploads, and you should be careful with that number, because these clients skew heavily to mobile and yours may not. The per-device rates travel better.

Desktop is the only row that inverts, and the reason is physical. A webcam pointed at an ID held at arm's length produces exactly the blurred, glared image your own quality checks throw out, so most laptop users send a file instead.

Run those against your own traffic mix and the answer moves a long way. A consumer app onboarding almost entirely on phones lands around 10%, while a lender where a third of applicants apply on a laptop lands closer to 26%, on identical fraud controls.

For a business whose customers apply from work, that makes an upload ban close to a desktop ban.

Mobile matters just as much. Roughly one in eleven genuine mobile users uploads a file despite holding a phone with a perfectly capable camera, which tells you something useful about who they are. They are not evading anything. Their passport is simply in a drawer somewhere else at the moment you asked for it.

Some of them will switch to the camera. Nobody has measured how many.

The obvious objection to all of this is that those customers are not lost, only redirected. Close the upload path and they will take the photo you asked for.

Some of them will. The honest answer is that nobody knows what share, ourselves included, because this data covers what people did when both routes were open, not what they would do if one were taken away.

What it does show is that these were choices rather than accidents. Upload sat alongside live capture in the same flows, and 9.8% of genuine customers took it anyway. On desktop, 59.2% did. People do not pick the slower route with a working camera in front of them unless the camera is not working for them.

Three things keep the switch rate below 100%. A document that is not in the room cannot be photographed, whatever the flow asks for. A laptop webcam pointed at an ID at arm's length produces exactly the blurred, glared image your own quality checks reject. And every extra step costs you people, because noticing the upload button has gone, hunting down the document, finding decent light and starting again is a retry, and retries do not all finish. Even the customers who do switch meet an 11.69% quality rejection rate on the live capture path.

Measured as a filter, a ban has perfect recall and low precision

Underneath the security language, an upload ban is a fraud filter with a single rule.

Its recall is perfect, since refusing every upload catches every fraudulent one. Its precision is low, because 3.6 of every 4.6 documents it blocks belong to real customers. Teams judge every other fraud control on those two numbers. Few write a ban down in the same terms, because it arrives as policy rather than as a model.

Detection reaches the same decision with evidence attached, and the distance between the two is precision. Every vendor blocks fraud. Far fewer can tell you how many genuine customers they turn away doing it, and that number is what decides whether the fallback is worth having.

The US Department of Homeland Security put seven document validation systems through its Remote Identity Validation Rally in 2025. False rejection of genuine documents ranged from 0.60% to 97.30% across those seven, and false acceptance of fraudulent ones from 0.88% to 76.68%. One system turned away almost every legitimate document it saw, while another let through three quarters of the fakes.

That spread is worth holding in mind when a vendor tells you uploads cannot be made safe, because the statement may describe their detection rather than the channel. Where a system cannot separate a genuine upload from a manipulated one, banning the channel is the only lever it has.

How to decide which user's can see a document upload option?

Keeping both routes open is not one decision. It is four, and together they separate a graded policy from an open door.

Which route you ask for first does the most work. Live capture carries roughly a quarter of the fraud rate, so flows that keep both usually open with it rather than putting the two side by side.

Timing decides how much volume moves. Put the fallback on screen at the start and it becomes a choice. Hold it back until someone has failed two or three capture attempts, or until the device reports no usable camera, and it reaches the people who need it without inviting everyone else along.

Risk tier decides who never sees it at all. Plenty of teams strip the fallback out entirely for high-value onboarding, a politically exposed match, or an account opened from a high-risk jurisdiction, reasoning that losing that customer costs less than getting them wrong. Where you draw that line is a matter of appetite, and it moves by sector.

The last lever is the one teams tend to inherit rather than choose. When an upload trips a forensic signal, failing it outright and escalating it to live capture or human review carry very different false-positive costs, and somebody picked one of those without necessarily deciding to.

Shufti’s approach to document capture

We classify every image that reaches us as a live capture, an upload or a screen grab before verification runs, which is what turns a graded policy from an idea into something you can configure. High-value onboarding can require live capture while lower tiers accept uploads, with the heavier forensic layers concentrated where the risk actually sits.

On precision, DHS tested our selfie-to-document matching at a threshold set for a false match rate of one in ten thousand, and we returned a false non-match rate under 0.68% with no extraction failures on either image. That is a different problem from document forensics and we are not going to pretend otherwise. It is, though, what a precision claim looks like once somebody independent has checked it, which makes it a fair standard to hold any vendor to.