Somewhere today, a nineteen-year-old with her first full-time job will try to open a bank account. She has a passport, a payslip and nothing to hide. The bank's system will think about it for half a second - and say no.
Not because she's suspicious. Because the data used to check her doesn't know she exists yet.
She won't complain. She won't call the support line. She'll close the tab, open a competitor's app, and be their customer by dinner time. The bank will never know what it lost, because the loss is recorded - if it's recorded at all - as one more "failed verification."
This plays out every day, around the world, with exactly the customers every business says it wants: young people, new arrivals, people building their first financial life. And in many cases it has nothing to do with fraud.
When an identity check comes back "no match," it's easy to read it as a warning about the person. Often, it's telling you something about the data instead.
Most applicants are legitimate customers. Yet some of them will still fail an identity match - not because they're suspicious, but because the available data can't confidently recognise them. The check didn't catch a criminal. It turned away a customer.
And every one of those wrong "no's" costs money three ways: the fee paid for the check itself, the customer who gives up and signs up somewhere else, and the manual review queue for the ones who persist - a human doing slowly and expensively what the data should have done instantly.
The industry pays close attention to the fraud it catches. The quieter number - legitimate customers turned away - gets far less attention. So it's worth asking a simple question: how does a real person, with real documents and a real address, fail an identity check?
When the problem sits in the identity data, it generally comes down to three causes. We call them the three leak points.
The first leak is the simplest - the person isn't in the data at all.
A lot of traditional identity data leans heavily on credit and financial records: loans, cards, utility contracts, repayment histories. That works well for people who've been borrowing for twenty years. It works poorly for people who haven't started yet.
A nineteen-year-old hasn't had time to leave a paper trail. A skilled migrant might have a decade of financial history - in another country's records. In Australia alone, 8.8 million residents were born overseas - 32% of the population (ABS, April 2026). None of these people have done anything wrong. All of them are hard to see for a data source built on local credit history, and a person the data can't see is a person the check can't pass.
These "thin file" customers are a growing and increasingly important group for banks and fintechs - and the customers hardest to verify with old-style data are often the ones businesses are competing hardest to win.
The fix for this leak isn't more of the same data. It's different data - identity records sourced from beyond the credit system, in the countries where these customers actually live and work. The signals exist. Most verification data just doesn't include them.
The second leak is sneakier. The person is in the data - but the record has quietly stopped being true.
They moved house last year. They changed their phone number. They got married and changed their name. They enter today's correct details, the system compares them against a record from three years ago, and the two don't line up. No match.
Nobody made an error. The data was right when it was collected. It just aged - and identity details age constantly, because people move, switch providers and change numbers all the time.
Think of it like a phone book. A huge phone book sounds impressive - but if it was printed three years ago, a slice of those numbers now belong to someone else. Size doesn't fix staleness. Only freshness fixes staleness.
This is one of the least appreciated facts in identity verification: a smaller, regularly refreshed data source can beat a much bigger, staler one - because the staler source fails exactly the records that matter most. The people whose lives are changing are often the same people who need a new account, a new loan, a new service right now.
The third leak is the strangest one. The person is in the data and the record is current - but the systems still can't connect the two.
The name is spelled two ways: Zhang Wei in one record, Wei Zhang in another. A hyphen appears in one database and not the other. One system stores "Unit 2, 14 Smith Street" and the other stores "2/14 Smith St." A name transliterated from Arabic or Korean has three equally valid English spellings, and the record uses the one the customer didn't type today.
All the information is there. The join fails on formatting.
This is a solvable engineering problem - it's about how records are mapped, indexed and compared, not whether they exist. But it takes real, unglamorous work, done separately for every country's naming and addressing conventions. Skip that work and perfectly good data produces a "no match" for a perfectly real person - and from the outside, it looks identical to leaks one and two.
That's the trap of the three leak points: they produce the same result on the screen, but they have three different causes and three different fixes. If a provider can't tell you which leak is costing you customers, they can't tell you how to stop it.
Most identity data takes a long trip before it reaches the system doing the check. It's collected somewhere, sold to an aggregator, packaged, resold, repackaged and resold again. Every extra step adds the chance of two problems: the data gets older, and the formatting gets changed. In other words - every extra step widens leak two and leak three.
We built IdentityPulse the other way around. When you query us, you're querying our data directly - over 4 billion records across 43 countries, held in our own encrypted infrastructure, sourced through primary data partnerships and regularly refreshed. That's one layer between you and the data, not three. Our particular depth is in Australia and Asia-Pacific, including countries that are difficult to source well from outside the region.
One more thing matters here, and it deserves its own article: the platform is designed to move and expose as little personal information as possible. Our standard checks use privacy-preserving encryption - the match result comes back without the person's details. Where clients need verified fields for onboarding forms, we can return them under strict contractual terms - but the default is that nothing goes back except a match signal and a confidence tier. Fresh data and strong privacy are not a trade-off.
Here's the mistake almost everyone makes when evaluating identity data: they ask the provider for their match rate.
A single overall match rate is an average, and averages hide everything that matters. A provider can post an excellent global number while failing every nineteen-year-old, every new migrant and every hyphenated surname you send them - because those groups are small enough not to dent the average, and valuable enough to hurt when they're lost.
So don't ask for the average. Run the test that reflects your actual pain:
Take a sample of your recent failed checks - the applications your current data turned away. Run them through the source you're evaluating. Count how many of those real people now pass. That recovery rate - alongside cost, accuracy and risk performance - should be one of the most important numbers in the evaluation.
That's exactly the test we invite. We'll stand up 10,000 free checks so you can benchmark us against your hardest cases - your thin files, your recent movers, your difficult name formats. No strings attached, nothing to install beyond a standard API, and every check uses privacy-preserving encryption.
If we recover customers your current data is losing, you'll see it in your own numbers, not our brochure. And if we don't - you'll have learned something about where your three leaks actually are, for free.
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.
