Six seconds or nine minutes: what verification speed claims measure

Sumsub's case study for the marketplace CS.Money, checked on 20 August 2026, contains both halves of the problem in a single sentence. Under "The Results", the page reports: "On average, users spend 9 minutes completing verification, during which it takes only 8 seconds for Sumsub to verify all the documents."

Nine minutes and eight seconds, describing the same verifications, published by the same vendor on the same page. Neither figure is wrong. They are answers to different questions, and only one of them is the question a merchant actually cares about, because only one of them is time the customer is aware of spending.

Every published speed claim in this market picks one of those two clocks. Almost none of them says which.

The three clocks

Decision latency starts when a document image arrives at the vendor and stops when a verdict comes back. This is the number vendors publish, because it is the part they control completely and the part that improves when their models get better.

Session time starts when the user is handed to the flow and stops when they see a result. It includes reading the instructions, finding a document, granting camera permission, holding the phone still, failing, and trying again. Vendors influence it through capture quality and guidance, but they do not control it.

Wall-clock time to a final answer stops when the case is closed, which for a manual-review case can be hours later. This is the number that determines whether a customer waits for a parcel or gives up, and no vendor publishes it.

The three can differ by orders of magnitude on the same traffic. The CS.Money figures put two of them 67 times apart.

What the vendors actually publish

Every figure below was read from the vendor's own public page on 20 August 2026. Rate cards and marketing claims change without notice.

Two things stand out in that table before any comparison is attempted.

The first is that Sumsub's marketing page and Sumsub's developer documentation give different answers — 20 seconds on one, "around 50 seconds" on the other, with the documentation adding that it "can vary depending on the verification steps and countries selected by the customer." That is not a contradiction so much as evidence that the phrase "verification time" is doing unmarked work in both places.

The second is that not one of these is a median. They are averages, or they are adjectives. An average completion time is the metric most flattered by throwing out the tail, and the tail is where abandoned customers live.

The distribution is bimodal, which is why an average misleads

An average is a reasonable summary of a single population. Verification traffic is not one population, and the vendors say so themselves.

Veriff's product page reports a "98% check automation rate powered by AI" and that 95% of genuine users are "verified successfully on their first try". AgeChecker.net's explainer states that "Over 90% of customers are verified instantly using just name, address, and date of birth", with the remainder asked for a photo ID.

Both descriptions imply the same shape: a large group that finishes almost immediately, and a small group routed into a slower path — a document upload, a retry, a human reviewer. There is very little traffic in between.

Averaging across that shape produces a number that describes almost nobody. It sits in the empty space between the two modes, and it moves whenever the ratio between them moves — which happens with device mix, document mix and fraud pressure, none of which is a change in speed. A median at least lands inside the mode where most users actually are, and tells you which mode that is.

The tail is not a rounding error, either. At a 98% automation rate, one session in fifty takes a different path; at AgeChecker.net's stated split, one in ten does. For a merchant, those are the orders that generate support tickets.

Why a median, and why the whole session

ProofAge publishes two numbers on its home page: a median of 60 seconds for document verification and 17 seconds for age estimation. Both are session times — the user's clock, from the start of the flow to a result on screen.

Placed next to the table above, that looks like the worst number on the page. It is measuring the most.

The choice of a median rather than an average is the smaller of the two decisions, but it is the one that resists gaming. A median says half of real sessions finished faster than this. An average can be dragged down by a large population of trivial cases, and it hides how bad the slow half gets.

The choice of session time over decision latency is the larger one, and the argument for it is that decision latency is not a quantity a merchant can act on. If verification takes a user four minutes and the vendor's model accounts for six seconds of that, improving the model to three seconds changes nothing anyone will notice. The remaining time is capture, retries and instructions — which is to say, product design rather than inference speed.

The comparison this article cannot make

It is worth being explicit about what these numbers do not establish, because the temptation to line them up is the reason the article exists.

Sixty is not "worse than" six. The two figures do not measure the same interval, and no arithmetic converts one into the other. Nothing here shows that ProofAge is faster or slower than Veriff, Sumsub, Yoti or anyone else, and the published material does not contain what would be needed to show it.

The vendors are also not selling the same thing. Yoti's one second is a facial age estimation inference with no document involved, which is a different and much lighter operation than authenticating a passport. AgeChecker.net's 10 to 30 seconds covers a path where a live team reviews the image, which is a stronger claim than an automated-only average of the same length. Comparing across those without saying so produces a table that looks rigorous and means very little.

What to ask instead

• Ask when the clock starts. If it starts at image receipt, the number excludes everything the user experienced up to that point.
• Ask whether it is a median or a mean, and what happened to the failures. A mean over successful sessions only is the most favourable number any vendor can quote.
• Ask for the manual-review rate and the time those cases take. A 98% automation rate means one order in fifty follows a completely different clock.
• Ask what share of users finish at all. Speed on completed sessions says nothing about the ones that ended in an abandoned cart.
• Run the same traffic through two vendors before believing either. Device mix and document mix move these numbers more than model quality does.
• Date every figure you record. Every number in this article carries 20 August 2026 for that reason.

The honest version of a speed claim names its clock. Until that is standard, the largest published number in a comparison is as likely to be the most complete one as it is to be the slowest.