AI system design and integration

Identity resolution false matches: why they happen and what to do about them

False matches happen because deterministic matching (exact identifiers like an ID number or email) is near 100% accurate but only covers people who've logged in or verified somewhere, while probabilistic matching (fuzzy signals like name plus date of birth) extends coverage but introduces false positives and false negatives that no threshold can fully eliminate. Stop treating a "match found" result as a fact. Build a human checkpoint between the match result and any action that affects someone's life, access, or record.

We've built profile enrichment and candidate verification systems for South African clients, and the real failure mode was never the matching algorithm. It was teams treating a "match found" result as a fact instead of a prompt to check. The systems that worked were the ones where matching ran as a suggestion layer, not a decision layer.

Why identity resolution produces false matches

Deterministic matching: high accuracy, limited reach

Deterministic matching links records when an exact identifier agrees: a South African ID number, a verified email, a phone number tied to a confirmed WhatsApp Business API session. When the identifier matches, the confidence is extremely high, often quoted at 95-100% accuracy. The catch is coverage. Deterministic matching only works when both records actually contain that identifier. If someone has never logged into a system with their ID number, or used a different email for a different service, deterministic matching has nothing to link on. It's accurate but narrow.

Probabilistic matching: more coverage, more errors

Probabilistic matching fills the gap by scoring similarity across multiple weaker signals: name, date of birth, address, device fingerprint, browsing pattern. No single signal has to match exactly; the system calculates a probability that two records belong to the same person. This is how you link "J. Nkosi" at one address to "Jabulani Nkosi" who moved three years ago. It extends reach dramatically, but every fuzzy signal is also a source of error. Common names, shared addresses, data entry typos, and outdated records all push probabilistic scores in the wrong direction.

Why no vendor can promise zero false matches and zero missed people

These two failure modes pull against each other. Tighten the matching threshold and you cut false positives but create more false negatives (missed matches). Loosen it and you catch more real matches but also more wrong ones. Any vendor who tells you their system has zero false matches and zero missed people either hasn't measured it properly or is selling. The honest framing is a trade-off curve, not a single accuracy number, and choosing where to sit on that curve is a design decision, not a solved problem.

False positives vs false negatives: the real difference

A false positive merges two different people

A false positive is when the system decides two different people are the same person and merges their records. In a background check, this means someone else's criminal record, credit history, or employment history gets attached to the wrong name. In KYC screening, it means an innocent customer gets flagged because their name resembles someone on a sanctions list.

A false negative splits one person into two records

A false negative is the opposite failure: the system fails to recognise that two records belong to the same person, so it treats them as separate individuals. In fraud detection this means the same bad actor operates under what looks like two clean identities. In a CRM or enrichment platform, it means duplicate profiles, wasted outreach, and an incomplete picture of a real customer.

Why the acceptable error rate depends on the use case, not the vendor

A dating app tolerating a few duplicate profiles is a minor annoyance. A background check system merging two people's criminal records is a legal and human disaster. A KYC system missing a real sanctions match is a regulatory failure. The acceptable balance between false positives and false negatives is a business and legal decision specific to your use case, not something a vendor's default settings should decide for you.

Why vendor accuracy claims don't agree with each other

The 70-80% deterministic number vs the 95-100% probabilistic number

Here's where buyers get confused. One vendor quotes 70-80% match rates, another quotes 95-100%, and they sound like they're describing the same thing. They're usually not. The lower number often reflects deterministic coverage, the percentage of records that have a matchable exact identifier at all. The higher number usually reflects accuracy on the records the system did choose to match, which says nothing about the people it missed entirely or merged wrongly.

Doing the math: what a "70% match rate" actually delivers

If a vendor says their deterministic match rate is 70%, that means 30% of your population has no reliable match and falls back to probabilistic linking, weaker signals, more manual review. If their probabilistic accuracy is "95%" on top of that, you're still looking at a meaningful number of wrong merges once you multiply across a database of tens of thousands of records. A 5% error rate on 50,000 matches is 2,500 wrong decisions.

What to ask a vendor before trusting their stated accuracy

Ask for the false positive rate and the false negative rate separately, measured on a labelled test set, not a marketing deck. Ask what percentage of their total match rate is deterministic versus probabilistic. Ask how they measured accuracy, against what ground truth, and on what population. If a vendor can't answer these with numbers, they haven't measured it rigorously enough for you to rely on it for consequential decisions.

What a false match actually costs someone

Background checks: the mixed file problem

A mixed file happens when a background check system attaches another person's record, often someone with a similar name or shared address, to the wrong file. The result is a candidate rejected for a criminal record that isn't theirs, or a tenant denied housing because of someone else's eviction history. This is one of the most common and most damaging failure modes in consumer reporting, and it's driven almost entirely by probabilistic matching run without a human checkpoint.

Why the human checkpoint matters

US consumer reporting agencies have paid multi-million dollar settlements over mixed files, cases where background checks confused people who shared a name and birth year but nothing else. The root cause was consistent: thin identifying data (name and rough date of birth only) run through automated matching with no step where a human confirmed the match before it affected a real decision. The technology wasn't broken. The process around it was.

South Africa specific risk: POPIA, ID numbers, and the checksum trap

Why there's no legal name-to-ID lookup in South Africa

There is no public, legal service in South Africa where you can enter someone's name and retrieve their ID number. The National Population Register sits with Home Affairs and access is restricted to accredited users under specific legal bases, mainly FICA-regulated institutions doing verification with consent or statutory authority. Any tool claiming to do open name-to-ID lookups is either scraping leaked data or operating outside the law.

A valid ID checksum is not proof of a real match

South African ID numbers use a Luhn-style checksum digit, which means you can generate a mathematically "valid" ID number that isn't assigned to any real person, or validate that a number's format is correct without confirming it belongs to the person you're checking. A passing checksum tells you the number is well formed. It tells you nothing about identity. Treating checksum validity as verification is a common and dangerous shortcut in home-built matching logic.

Legitimate verification paths: Lexis WinDeed, Experian, TransUnion, FICA-accredited NPR lookups

If you need real ID verification in South Africa, the legitimate routes run through accredited bureaus and data providers: Lexis WinDeed for property and deeds-linked checks, Experian and TransUnion for credit and identity verification, and Home Affairs' National Population Register through FICA-accredited channels for regulated institutions. These providers operate under contractual and regulatory obligations that an unaccredited scraping tool simply doesn't have.

Penalties for unauthorised ID number matching under POPIA

POPIA classifies ID numbers as personal information requiring a lawful basis to process. In many contexts they're treated with heightened care because they enable fraud and identity theft. Processing someone's ID number without consent, a contract, or another lawful basis under POPIA can expose a business to Information Regulator enforcement, administrative fines, and civil claims from the affected person. The short version: "we matched it automatically" is not a defence if the processing itself had no lawful basis.

How to reduce false matches in a production system

Normalise data before you match it

A huge share of false negatives comes from inconsistent formatting, not algorithm weakness. Standardise date formats (DD/MM/YYYY or ISO 8601 only), strip titles and honorifics from names, normalise address components to a consistent structure, and resolve common nickname variants before matching logic ever runs. This single step often fixes more missed matches than switching matching vendors. We've seen this cut false negatives by 30-40% in real deployments.

Measure false merges and missed matches, not a single accuracy number

Build a labelled test set of known-true and known-false pairs specific to your own data, and track false positive and false negative rates separately over time. A single blended "accuracy" number hides which failure mode is actually hurting you. Run this measurement before you go live and set a baseline, then re-measure quarterly. This is the same discipline that matters when handling POPIA correctly: you measure both error types before you trust the system with real decisions.

Put a human checkpoint between a match and an action

This is the fix that actually worked across the systems we've shipped. Every probabilistic match, before it triggers a reject, a flag, a merge, or an outbound contact, routes through a human reviewer who sees the match confidence and the underlying evidence, not just a yes/no result. The reviewer's decision gets logged as part of the POPIA accountability trail, which matters both for compliance and for catching systemic matching errors early. If you're automating hiring decisions, KYC screening, or background checks, the checkpoint comes before the decision, not after. A reviewer seeing "Match score 87% based on: name (95%), DOB (100%), last known address (60%)" catches issues that a binary match result misses.

Match confidence should scale with consequence

A low-stakes action, like suggesting a possible duplicate in a CRM, can run on a lower confidence threshold with no human review. A high-stakes action, rejecting a candidate, flagging a transaction, merging a legal record, should require higher confidence plus mandatory human sign-off. This isn't hand-waving about "responsible AI". It's a specific operational control: set your confidence threshold based on the cost of failure, not based on what your vendor defaults to.

Common questions

What causes false matches in identity resolution or people search tools? False matches come from probabilistic matching relying on fuzzy signals: name, date of birth, address. These signals aren't unique enough to guarantee identity. Common names, shared addresses, outdated records, and inconsistent data formatting all increase the odds that two different people get linked together or one person gets wrongly split across records.

What's the difference between deterministic and probabilistic matching? Deterministic matching links records using exact identifiers like an ID number or verified email, giving near 100% accuracy but limited coverage. Probabilistic matching scores similarity across multiple weaker signals to extend coverage to people without a shared exact identifier, at the cost of introducing false positives and false negatives.

What's a false positive vs a false negative in identity matching? A false positive wrongly merges two different people into one record, attaching one person's history to another's identity. A false negative fails to link two records that actually belong to the same person, creating duplicate or fragmented profiles. Both cause real harm depending on the use case.

Can a people-search tool legally look up a South African ID number by name? No. There is no legal public service for name-to-ID lookups in South Africa. Access to the National Population Register is restricted to accredited institutions under FICA with a lawful basis. Any tool offering open name-to-ID lookup is either using leaked data or operating outside POPIA and Home Affairs regulations.

Does a valid SA ID number checksum prove the ID is real? No. The checksum digit only confirms the number is mathematically well formed, not that it belongs to a real, living person or the person you're checking. You can generate a checksum-valid number that was never issued. Real verification requires checking against an accredited source like Home Affairs or a licensed credit bureau.

What vendor accuracy claims should you distrust? Distrust any single blended "accuracy" percentage without separate false positive and false negative rates, and distrust claims not tested on a labelled ground-truth set. Also be wary of vendors who don't disclose what share of their matches are deterministic versus probabilistic, since that ratio changes what the headline number actually means.

What is a "mixed file" in a background check? A mixed file is when a background check system attaches someone else's record (criminal history, credit history, or employment record) to the wrong person's file, usually because of a shared name or similar identifying details. It's a leading cause of wrongful rejections in hiring, lending, and tenant screening.

How does POPIA treat ID numbers and identity data? POPIA treats ID numbers as personal information requiring a lawful basis to process, such as consent, contract necessity, or legal obligation. Because ID numbers enable fraud and identity theft, they generally warrant heightened care in how they're collected, stored, matched, and shared.

How do you reduce false positives in KYC/AML screening? Combine multiple identifying fields rather than name alone, normalise data before matching, calibrate thresholds against a labelled test set, and route every alert through human review before any account action. Screening systems are designed for high recall (catch everything, filter later), so the review layer is what actually controls the false positive cost.

What's the legal risk of verifying someone's ID without consent in South Africa? Processing or verifying someone's ID number without a lawful basis under POPIA can expose a business to Information Regulator complaints, administrative fines, and civil liability from the data subject. Even internal matching for "efficiency" purposes needs a documented lawful basis, not just a technical capability to do it.

If you're building matching or verification logic and want a second opinion on where the false match risk actually sits in your system, message us on WhatsApp and we'll talk it through.