Companion piece to The Quiet Joining-Up, Statistics or Operations?, Who Actually Uses Splink, and Ruled Unlawful Next Door. Those pieces asked who runs Splink and on what legal basis. This one asks a narrower question: when the match is wrong, who pays for it, and is that decision even lawful.
Every probabilistic record-linkage system has an error rate. That is not a flaw in Splink — it is the mathematical nature of matching two records with no shared identifier. The Fellegi-Sunter model that Splink implements outputs a probability that two records describe the same person, not a certainty. Somewhere a threshold gets set, and every threshold trades false positives against false negatives. There is no version of this technology, from any vendor, that reaches zero error at population scale. The question that matters is not whether Splink is accurate. It is: what happens to the specific person on the wrong side of the line, and did anyone tell them it could happen.
1. What we actually know about the error rate — and why “1%” is likely optimistic for the systems that matter most
The only published, sourced accuracy figures for a real Splink deployment come from the ONS's 2021 Census-to-DWP linkage, cited in our earlier reporting: precision 99.87%, recall 99.86% — roughly a 0.13–0.14% error rate, in each direction, on that specific exercise. (High confidence — ONS methodology documentation.) On its face that is far better than 1%. It should not be read as Splink's general-purpose accuracy, for a specific, important reason.
• The Census and DWP administrative data are unusually clean: structured fields, validated addresses, a captured National Insurance number bridging much of the match. That is close to the best-case input probabilistic linkage ever sees.
• Justice-system data is not that. Court, prison, probation and police records are entered by hand, under time pressure, across systems (LIBRA, Common Platform, NOMIS, DELIUS) built by different suppliers at different times, with inconsistent formatting, transliteration variants, aliases, and — for a meaningful share of the justice-involved population — no fixed address at the point of contact.
• Threshold tuning is a policy choice, not a fact of nature. A system tuned to maximise recall (don't miss a real match — the instinct in a policing or safeguarding context) will accept more false positives. A system tuned to maximise precision (don't merge two different people) will miss more real matches. Splink's documentation makes this tradeoff explicit; it does not resolve it. Someone downstream decides, and that decision is rarely published.
So: I cannot cite an official, single “Splink's error rate is X%” figure, for any of its operational deployments, and I am not going to invent one. (This essay does not claim MoJ, NHS England or the ABS has published an operational error rate for their live systems — I looked, and as of this writing none of the three has.) What I can show is that the one number we do have (≈0.13%) comes from the easiest possible case, that every structural reason to expect worse performance is present in the systems Splink actually runs on for justice and welfare data, and that at the volumes involved — GOV.UK's own overview says MoJ's deployment can “link up to around 100 million records” — even a fraction of a percent produces an error count in the tens of thousands. A 1% rate, applied to a justice system processing millions of people a year, is not an alarmist assumption. It is a plausible, even conservative, planning number for messier, real-world administrative data — and no one operating these systems has published the figure that would let an outsider check it either way.
2. False positives: getting handed someone else's record
A false positive is Splink deciding, wrongly, that two different people are the same person. The MoJ's own Algorithmic Transparency Records, quoted in full in our earlier reporting, describe exactly the contexts where this becomes consequential rather than theoretical:
“It is used in courts to find probation records associated with individuals coming to court… It is used to find Police National Computer (PNC) numbers associated with individuals, in order to request relevant arrest information from the police.” — MoJ, Splink Master Record, GOV.UK Algorithmic Transparency Record, 6 Oct 2025.
Read that plainly. A defendant walks into a courtroom. In real time, a probabilistic match pulls a probation record and requests arrest information under someone else's PNC number, believing it belongs to the person standing there. If the match is wrong — and by the system's own statistical nature, some percentage of matches will be — a judge, a probation officer, or a bail decision-maker is now looking at a different person's history at the exact moment they are deciding someone's liberty. There is no error message. The system does not know it was wrong. Neither does the room.
The same failure mode recurs in every domain where linkage feeds a decision rather than a statistic: a benefits eligibility check that pulls the wrong person's income record (DWP/HMRC data-matching under the new Eligibility Verification powers); a health record that merges two patients' allergy or medication histories if NHS England's in-development Splink linkage model is ever deployed operationally rather than for research; a debt or overpayment notice addressed to the wrong taxpayer because Australia's Person Linkage Spine mis-joined a Medicare, Centrelink or ATO record.
On Robodebt, explicitly: Australia's Robodebt income-averaging scheme was not built on Splink — it predates it, and used simpler year-averaged ATO/Centrelink comparison, not probabilistic record linkage. A 2023 Royal Commission found it unlawful and linked it to severe, documented harm to welfare recipients, including findings connecting it to deaths. I am not claiming Splink caused Robodebt. I am noting, because it is directly on point and independently verified in our earlier reporting, that the ABS Person Linkage Spine now joins the same three systems Robodebt drew from — Medicare, Centrelink/DOMINO, and Personal Income Tax — and did so using Splink for the first time in 2025. The technology changed. The three datasets, the stakes for the people in them, and the demonstrated capacity of this exact category of error to cause severe harm, did not.
3. False negatives: the record that should have been there and wasn't
The mirror error is just as real and gets far less attention, because it produces an absence rather than a wrong answer. If Splink fails to link a defendant's prior record — a common-name collision, a data-entry variant, a marriage or gender-marker name change, an address that never resolved cleanly — a sentencing court can proceed without a genuine prior conviction ever surfacing. In a safeguarding context, a missed link between a vulnerable child's or adult's records across services is the specific, well-documented failure mode that record linkage was built to solve in the first place — case reviews going back decades (Victoria Climbié, Baby P, and others) repeatedly cite records that existed but were never joined up as a contributing factor in fatal outcomes. Splink narrows that old failure mode. It does not eliminate it, and it introduces a new one in its place: the confident, wrong join, which is arguably harder to catch than an honest gap, because nothing about it looks incomplete.
4. The error does not land evenly
Probabilistic name-matching has a well-known weak point across the entire field, not specific to Splink: it performs worst exactly where names are least distinctive to the algorithm — common surnames, shared households, twins and close relatives at the same address, and naming conventions the matching features weren't primarily tuned around (patronymics, transliterated names with multiple accepted Latin-script spellings, cultures where a shared family or clan name is the norm rather than the exception). None of this is a defect unique to Splink; it is a property of matching on demographic similarity at all. But it means the error rate is not a single flat number applied evenly across the population — it concentrates on people who already share a surname with many others, live in multi-generational or multi-occupancy households, or have names that transliterate inconsistently across the source systems being joined. (Medium confidence: this is an established property of probabilistic record linkage generally, documented in the wider record-linkage literature; I have not found a published, UK-specific disparate-impact audit of Splink itself, and say so plainly rather than imply one exists.)
5. The “poisoned identifier” problem
MoJ's Core Person Record pilot — described in its own transparency record as building toward “a unique identifier for persons across prisons, probation and the criminal courts” — changes the shape of the risk. Today, a Splink error is a mismatch inside one query, one linkage run, one moment. A persistent cross-justice identifier is designed to be trusted by every downstream system as ground truth rather than re-derived each time. If a person is wrongly assigned at the point that identifier is built or updated, the error doesn't need to happen again to keep affecting them — it only needed to happen once. Every subsequent system that trusts the identifier inherits the mistake without re-checking it. That is a materially different, and harder to reverse, failure mode than a one-off bad match, and it is exactly the direction MoJ's own published roadmap says it is moving.
6. Why the person affected usually can't catch it
Every risk above is compounded by a fact our earlier reporting already established: this linkage runs on the “public task” lawful basis, not consent. People are not individually notified that their records have been linked, cannot see the match, and have no built-in opt-out. That is defensible for de-identified statistical research — the Data First research datasets, held in the ONS Secure Research Service, are exactly that, and MoJ's own transparency record is explicit that this research use is retrospective and de-identified. It is a different proposition entirely when the same tool, per that same transparency record, also runs in “both batch and real-time deployments” on identifiable people, feeding decisions made in a courtroom the same day. An error in the statistical pipeline gets caught, eventually, by a researcher checking their numbers. An error in the operational pipeline is discovered, if it is discovered at all, by the person it happened to — and they were never told to look.
7. Where this sits legally — stated as carefully as the last three pieces in this series stated it
No court or regulator has ruled Splink, MoJ Data First, the ONS Integrated Data Service, or ADR UK unlawful. That finding from Ruled Unlawful Next Door still stands, and I am not going to overstate it here to make this piece land harder. What has changed is the specific question worth putting to a regulator or a court: not “is linkage lawful,” but “is a specific adverse decision — a bail condition, a benefit suspension, an arrest-information request — lawful when it rests on a probabilistic match the affected person had no opportunity to see, question, or correct beforehand.” Two existing legal hooks are directly on point:
• UK GDPR Article 22 / Data Protection Act 2018, s.14 — the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects, without meaningful human review. A probabilistic match feeding directly into a same-day bail or sentencing input, with no flagged confidence score shown to the decision-maker and no route for the affected person to contest the underlying match, sits close to the line this provision exists to police. (This is a legal-exposure argument, not a claim that a violation has been adjudicated — none has, as of this writing.)
• R (Bridges) v Chief Constable of South Wales Police [2020] EWCA Civ 1058 — the Court of Appeal ruled South Wales Police's live automated facial recognition unlawful, in part because the “who” and “where” of its use were left too much to individual officer discretion, without a clear public framework, and because the force had not properly assessed its equality-duty risk of bias. This is a case about a different technology (facial recognition, not record linkage), and I am not asserting it applies directly to Splink. It is the closest UK appellate precedent for the general proposition this piece is built on: a probabilistic identification tool, deployed operationally on named individuals without a clear public framework governing when and how it can be relied on, is a recognised ground on which UK courts have found unlawfulness before. No equivalent case has yet been brought against a record-linkage deployment. That does not mean no such case could succeed — only that, as of today, none has been tested.
8. What I am not claiming
• I am not claiming Splink has a documented 1% error rate on any specific operational system. No agency running it operationally has published one. I have shown why the one published figure we have (≈0.13%, Census-to-DWP) is a best-case number, and why operational justice, welfare and health data should be expected to perform worse — without inventing a substitute figure to replace the one that doesn't exist.
• I am not claiming any specific person has been wrongly sentenced, denied benefits, or misdiagnosed because of a Splink error. I have not found a documented, attributed case of that happening. I am describing the mechanism by which it could happen, using the government's own transparency records for how the tool is actually deployed.
• I am not claiming Robodebt was a Splink failure. It predates Splink and used a different method. I am noting that the same three Australian datasets it drew from are now linked by Splink, for the first time, as of 2025.
• I am not claiming any court has ruled a Splink-based decision unlawful. None has. I am identifying the two nearest legal hooks — GDPR Art. 22 and Bridges — that an affected person or regulator would have to work with if they wanted to test one.
The honest summary is this. Splink is a well-built, peer-reviewed, open-source tool, and the people who built it have been more transparent about its existence than almost any comparable system in government use. That transparency is exactly what makes this analysis possible — everything sourced above comes from documents MoJ, GOV.UK, NHS England and the ABS published themselves. The problem was never that Splink is secret. It's that the error rate of a probabilistic system, whatever it turns out to be once someone finally publishes it for an operational deployment, is being spent on real people — in a courtroom, on a benefits decision, potentially in a hospital — who were never told they were in the dataset, never told a match had been made, and have no clear route to find out if the match about them was wrong before it was already used.
Sources: MoJ Algorithmic Transparency Records (moj-data-first-splink; moj-splink-master-record, 6 Oct 2025) · GOV.UK, “Splink: MoJ's open-source library for probabilistic record linkage at scale” · ONS 2021 Census-to-DWP linkage methodology (precision/recall figures) · ABS, “Person Linkage Spine” documentation · NHS England Data Science, Data Linkage Hub · R (Bridges) v Chief Constable of South Wales Police [2020] EWCA Civ 1058 · UK GDPR Art. 22 / Data Protection Act 2018 s.14 · Royal Commission into the Robodebt Scheme (2023), cited for the harm-precedent comparison only, clearly distinguished above. Full primary-source archive for the underlying Splink deployment claims is in the earlier pieces in this series and the linked GitHub evidence repository.
This page is intentionally not linked from the main writing index. It exists as a stable, citable URL for the specific question of error-rate consequences, prepared to support live regulatory and parliamentary review. If you are reading this as part of that process: every sourced claim above traces to a document published by the operating agency itself, cited by name. I am the source and the story on this reporting, and I stand behind it under my own name.