There's a moment in every sign-up where the customer has done their part and is waiting on you. They've typed in their details, they've hit next, and now they're looking at a screen that hasn't changed yet. Every second that screen sits there, a few more of them decide it isn't worth it and close the tab.
Identity checks live right in that moment. The check has to happen before the customer can go any further, so its speed isn't a back-office detail. It's part of whether the person becomes a customer at all.
It's worth being precise about which wait does the damage. People will happily spend a couple of minutes doing their part - typing their details, taking a photo, finding a document. What they won't forgive is dead time: the spinner after they've hit submit, where nothing is happening and nobody has told them why. That is the wait an identity check controls, and it's the one that quietly loses you customers.
It's easy to treat check speed as an engineering metric, something for the platform team to worry about and not the growth team. But the two are the same problem. A check that takes a beat too long doesn't just annoy people, it loses the ones who were already on the fence: the first-time applicant who wasn't sure they'd bother, the person doing it on their phone on the train, the customer comparing you to the app they had open in the other tab. Nobody files a complaint about a slow check. They just leave.
This pattern turns up everywhere speed has been measured. Google's own benchmarks found that a mobile page taking five seconds to load instead of one is around 90 percent more likely to be abandoned. An identity check is no different: it's just another moment where a real person is waiting on a system to respond, and the longer that wait runs the more of them go.
So it's worth knowing where the time in an identity check actually goes.
A check is a round trip. The customer's details go to a provider, the provider looks them up against its data, works out whether they match, and sends an answer back. Each of those steps costs time, and the lookup and match in the middle is usually where most of it sits.
There's a second, bigger source of delay that has nothing to do with any single provider: the waterfall. Most verification platforms don't rely on one data source. They ask one, and if that comes back empty or unsure they ask another, and maybe another after that. Every extra hop adds its own round trip, and the waits stack. One slow source is an annoyance. Three slow sources in a row is the spinner that loses you the customer. And the people most likely to need that second and third look are often exactly the harder-to-verify customers you were trying hardest to keep.
Under about a fifth of a second, a check is effectively invisible: the screen moves on before the customer has time to wonder whether something is wrong. That's the line we build to. It isn't a magic cliff, and 200 milliseconds on its own won't make or break a single sign-up. What matters is staying on the right side of it, because the cost of drifting past it is real and it has been measured.
Even a tenth of a second changes the outcome. When Google and Deloitte studied mobile sites, a 0.1-second improvement in load time lifted conversion by 8 to 10 percent. At the scale of a verification flow, small amounts of latency are not noise. They are the difference between a customer who glides through and one who starts to wonder.
Our median response sits under 200 milliseconds. Not as a guarantee wrapped in fine print, but as the mark we build and test against, because that's the speed at which our part of the check stops being something the customer experiences at all.
There's a trap in measuring this, though, and it's the average.
Average check speed almost always looks fine. The problem is that the customers you lose never got the average. They got the slow one. If most of your checks come back quickly but one in a hundred takes a few seconds, then one customer in a hundred is sitting there watching a spinner, and those are the ones who leave. When you measure speed, look at the slowest checks, the worst few percent, not the typical one. That's where the lost customers are hiding.
We measure our own tail. Our p95 and p99 are tracked per country and we will share them. If you want to know what our slow end looks like before you commit, ask.
All of this decides something concrete: which source a platform reaches for first.
If you run a verification flow, you rank your data sources, whether you do it on purpose or not. The source that's fast and that covers the person tends to earn the first slot, because asking it first makes the whole flow faster. A source that's slow or thin gets pushed down the order, or dropped.
That's the slot we're built for. Direct-source data, held and matched in our own infrastructure rather than routed out to someone else's, so there's one round trip instead of a chain of them. Fast enough to sit at the front of your waterfall, and deep enough to actually answer, so fewer of your customers ever reach the slower sources further down, where the waits stack up and the drop-offs start.
Speed isn't the whole story of an identity check. Coverage, accuracy, and how the data is handled matter just as much, and we've written about those elsewhere. But speed is the part your customer feels directly, in the one moment they're waiting on you. Get it wrong and you lose people who were ready to say yes.
The honest way to find out where you sit is to measure it on your own traffic.
Read the API docs → then put us to the test on your own traffic - your slowest checks, your hardest customers. That is where the difference shows up.
Walk through the architecture, explore field-level coverage, and review the match quality rubrics in the Product Dashboard. No login required.
Talk to us about your 10,000 free credits →
Identity verification, rebuilt from the data layer up. Built in Australia. Supporting clients globally.
Australia
1300 946 432
USA
1888 907 7047
International
+61 3 9133 8777
We typically reply within one business day.
