Most identity checks don't go to one single data source. They go to a whole sequence of them. The platform asks the first source, and if that comes back empty or unsure, it asks the next, and maybe the one after that - like a waterfall. Dan Cummins, our CTO, wrote about what that line does to your customer's wait in Slow Identity Checks Lose Customers. This piece is about the other half of the same question: who goes first, and why.
My area at IdentityPulse is data mapping and indexing, which mostly means getting records from 43 countries to line up well enough to match. From that side of the table, the order of sources looks less like a technical setting and more like a business decision. It decides what you pay, how long your customers wait, and how many real people get through.
Each source you could put in the line has three things going for it or against it.
Cost. Under per-query pricing, every source you ask bills you for asking, whether it found the person or not. A source that comes back empty still shows up on the invoice. Jason Edwards set out why that matters in Only Pay When It Works.
Speed. Every extra source is another round trip. One slow source is an annoyance. Several in a row is the spinner your customer gives up on.
Coverage and match quality. Does the source actually know this person, and can it recognise them when their details are written a little differently from the record? A source that can't is one more hop before anyone gets an answer.
No source wins on all three everywhere. Cheap and fast with thin coverage in the market you're growing into isn't a bargain, and broad coverage doesn't help much if it's slow. The order is where you decide which trade you're making.
The first source in the line gets asked on every single check. Everything after it only sees what the first one missed.
That makes the first slot the most important decision in the stack. Whatever sits there sets the baseline for your costs and your wait times, because it touches all of your traffic. Get it right and fewer checks ever reach the sources further down, where the waits stack up and the extra charges add up. Get it wrong and every check pays for the mistake.
There's a quieter factor that matters a lot from the matching side: how clearly a source tells you what it found.
If a source only says yes or no, the platform has very little to work with. A source that tells you how sure it is lets you set a simple rule: stop here on a strong match (as defined by your own metric), ask the next source on a weak one.
Every IdentityPulse check comes back with a match signal and one of three confidence tiers: Confirmed, Likely or Possible. The matching behind it runs on fixed rules, tuned country by country. It isn't an AI model making a judgement call, so the same details give the same answer every time. That consistency matters when you're writing routing rules, because a rule is only as good as the answer it's reacting to.
A lot of what separates one source from another isn't how many records it holds. It's whether it can find correct matches for the ones it has.
The same person can be "Nguyen-Thi Lan" in one system and "Lan Nguyen" in another. One record has a double-barrelled surname with a hyphen and the other has it without. One address is stored as "Flat 3, 22 King Road" and the other as "3/22 King Rd". When a source hasn't done the work of mapping those differences, country by country, a real person comes back as "no match" and the platform moves on to the next source. That's an extra hop, and often an extra charge, for someone who was in the data all along.
That mapping work is where I spend my days. It's also why our API is built as per-country endpoints with a consistent request and response schema. Each country's data is matched on its own naming and address conventions, but it reaches your platform in the same shape, so adding a country to your line follows the same pattern as the last one.
It's easy to set the order once, when you integrate, and leave it there. The trouble is that the things the order depends on keep changing. Sources refresh their data, or don't. Your customer mix shifts: more young applicants, more new arrivals, more growth in a region you weren't selling into a couple of years ago. An order that made sense at launch can quietly turn into one that costs more and passes fewer people.
The fix doesn't need anything fancy. Re-score your sources regularly, by country and by customer type, using your own traffic rather than a vendor's averages. The most useful sample is your recent failed checks: run them through the sources you're considering for the top of the line and count how many real people now pass. It's the same test we describe in Why Good Customers Fail Identity Checks.
IdentityPulse is built to sit near the front, upstream of the more expensive checks rather than instead of them. When you query us, you're querying our own data directly: over 4 billion records across 43 countries, regularly refreshed through primary data partnerships. Our particular depth is in Australia and Asia-Pacific, including countries that are difficult to source well from outside the region. Our median response is under 200 milliseconds - meaning you can push us to the front of the waterfall and the ripple will barely affect your existing queue's timings. And our pricing is match-based, so your significant cost is on confirmed matches, not query volume. That substantially changes the maths of putting a source first.
We're already in production with two of the world's largest identity platforms, so this isn't a theory about how the line works. It's the position we occupy.
If you run a verification flow and want to know where we'd earn a place in your order, test it on your hardest cases. We'll stand up 10,000 free checks so you can run your recent failed checks through us and see how many real people pass.
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 →We typically reply within one business day.