The Verification Files
TVF-003 · KYC · 30 min listen

Why a KYC Data Match Is Not Proof of a Real Person

A KYC match only shows two records agree. If the reference data is breached, synthetic or stale, the match proves little. How to verify identity properly.

Key findings

  • A KYC data match tells you that two records agree. It does not tell you that a real, present person is behind them.
  • If the reference data has been breached, recycled or polluted with synthetic identities, a match can confirm a fraudster.
  • Provero’s analysis found a 97% breach rate in a dataset that would have passed as a million clean records on spine data alone.
  • Treat a match as one signal. Layer it with checks on the phone, email, device and breach history, plus document and liveness checks where risk is high.

What does a KYC match actually tell you?

A match only tells you that two records agree. It doesn’t tell you whether the record you’re matching against should be trusted.

Electronic identity verification usually works by taking the details an applicant gives you (name, date of birth, address) and checking them against reference data such as credit files and electoral roll records. When they line up, the applicant “passes”.

That is useful, but it answers a narrow question: do these details exist together somewhere? It doesn’t answer the question you actually care about: is this a real person, and are they the person applying?

Why isn’t commercial KYC data enough on its own?

The weakness is in the reference data itself:

  • Breached data matches perfectly. A fraudster using a real person’s stolen details will match every field, because the details describe a real person.
  • Synthetic identities can build a record over time. Identities assembled from a mix of real and invented details can gradually create a credit footprint, and then they start matching too.
  • Records go stale. People move, die or change names, and reference data lags behind.
  • Everyone is matching against similar sources. If many organisations rely on the same underlying data, the same blind spots repeat everywhere.

Provero’s analysis of one dataset illustrates the scale. It found a 97% breach rate in records that would have passed as a million clean records on spine data alone. The data looked clean because it matched. It was not clean.

What does episode 003 cover?

In episode 003, “Why I Don’t Trust Commercial KYC Data”, Simon explains why a match is weaker evidence than most compliance processes assume. A match only shows that two records agree. It says nothing about whether the record being matched against deserves trust in the first place.

Listen to the episode for the full argument.

How should you verify identity instead?

Treat the match as one input, not the answer. A stronger approach layers independent signals that are hard to fake together:

  1. Check the contact points. Is the phone number live, and how long has it been in use? Is the email address real, and does it have history, or was it created yesterday? A long-standing phone and email that fit the identity are much harder to fabricate than a name and address.
  2. Check breach exposure. If an applicant’s details appear in known breaches, a perfect match becomes less reassuring, not more. That doesn’t mean rejection, but it should raise the bar.
  3. Check the device and connection. Does the IP location fit the stated address? Is the connection coming through a data centre, VPN or proxy? Has the same device been used for other applications?
  4. Look for consistency across signals. Real people leave a coherent trail. Synthetic and stolen identities often have one strong element (the matching record) and weak or contradictory everything else.
  5. Step up for higher risk. Where the stakes justify it, add document verification with a liveness check to confirm a real person is present and matches the document.

How do you decide how much checking is enough?

Match the depth of checking to the risk. A newsletter sign-up needs very little. A loan, an account that can move money, or a high-value lead needs far more. The mistake is assuming that a single data match covers all of these cases equally.

See how to solve the KYC match problem, including an example of the checks that catch a matched-but-stolen identity.

Frequently asked questions

What does a KYC match actually prove?

A KYC match shows that the details a person supplied, such as name, date of birth and address, agree with a record held in a reference database. It proves consistency between two datasets. It does not prove that the person supplying the details is the person in the record, or that the record itself is genuine.

What is spine data in KYC?

Spine data usually refers to the core identity records, such as name, address and date of birth, drawn from sources like credit files and electoral roll data, that electronic identity verification services match against.

Why can breached data pass KYC checks?

Breached data consists of real people’s details. When a fraudster submits those details, they match the reference records exactly, because the records describe a real person. The check confirms the details are real, not that the applicant owns them.

How do you make KYC checks more reliable?

Combine data matching with independent signals: whether the phone number and email are long-established and belong to the applicant, whether the details appear in known breaches, whether the device and IP fit the application, and, for higher-risk cases, document verification with a liveness check.

Exhibits: sources and further reading

Related files