Introducing Match,
our company-matching model.

A high similarity score is not enough to act on. Match separates the score from the decision. It matches automatically only when the top candidate scores high, is clearly ahead of the runner-up, and the evidence is sufficient on its own: the same core name, the same legal form and a corroborating city or street.

A conflicting tax identifier always blocks a match. So does a name that a register shows belonged to a different company before, and a record whose own register no longer knows it by that name. Every request ends in one of four outcomes with reason codes: MATCH, REVIEW, NO_MATCH or NO_CANDIDATE.

To merge automatically, Match needs either the same recognised legal form plus an agreeing address, or a matching tax identifier. It recognises the common English-language forms (Ltd, plc, LLP, LLC, Inc, Pvt Ltd) and Norwegian, Estonian, French, German and Dutch forms. For other forms it still finds and ranks the right candidate, but sends it to review instead of merging. It fails safe, never into a wrong match.

In the sanity check, 840 of 1,506 went to review. 834 lacked a recognised legal form, 607 of them Japanese companies whose names carry the form in kanji, which the normaliser does not yet recognise. Others have no form at all (foundations, associations, trusts) or forms it does not know yet, such as Italian, Spanish, Swedish and Chinese ones. Adding legal forms is the next engine work, Japanese first, and each addition will be measured before we claim it.

The benchmark mostly contains UK, Norwegian and Estonian companies because those registers publish the cross-links we grade against. That is where Match was measured, not a limit on where it runs.

Our first registered attempt, version 0.6.3, did not pass: on the calibration split it made 15 wrong matches in 60,875, above the bound. We examined every one. Most were names that had moved to another company after a rename while one register still showed the old name.

Version 0.6.4 adds two checks that only ever send a match to review. It reads published name histories, now including Norway’s, and it does not act on a record whose own register shows its name is out of date. On the calibration data that removed 9 of the 15 errors for 0.45% fewer automatic matches. We then registered a second attempt, had it reviewed, and ran it once on the sealed split. Both attempts, the failure analysis and every count are in the method note.

Match normalises names (legal forms per jurisdiction, abbreviations, transliteration-safe folding), retrieves candidates with a character-trigram index, scores each pair with a small gradient-boosted model calibrated by isotonic regression, and applies the evidence policy. Records can carry a name, street, city, country and tax identifier. A matching tax identifier counts as identity evidence, decisive when verified at source on both records. The benchmark used name, street and city only.

None of the components is new. The model is trained only on synthetic data written by several independent generators, so no customer data is needed to start. On synthetic tests its ranking was not reliably better than a tuned name-similarity baseline once the data author changed. Its value is the decision policy and where it runs, and that is what we claim.

The benchmark is built from public company registers in which the same company appears in two registers, linked by official identifiers: GLEIF, Companies House, the Norwegian Brønnøysund register, the Estonian business register, SEC EDGAR, the French SIRENE register and the Japanese corporate-number database. Nobody judged similarity: an answer is correct only if it names the record with the same official identity. In 60,008 queries the true company is not in the list, so any match there is wrong.

Engine 0.6.4 was frozen at its shipped threshold and run once on the sealed test split, which no version of Match had seen. The pre-registration and test runner went through three rounds of AI-assisted review using OpenAI Codex: the first two requested changes, which were made, and the third approved. No external audit or certification was conducted. The registration was frozen with a signed git tag. A calibration check inside the same run had to reproduce the registered development counts exactly before the sealed split was touched; it did.

The 0.084% is a weighted 95% upper bound: a statistical ceiling on the error rate of automatic matches across the benchmark’s case types, with the hard cases weighted far above their share of the sample, as fixed before any run (a stratified selective-risk bound: hypergeometric per-cell bounds, Bonferroni). The observed fraction is 10 wrong in 75,334 (0.013%). Case types were sampled by design, so these figures describe this sample, not an error rate on any population of records. The bound is a property of this benchmark, not a guaranteed error rate on your records, and it is not a certification by an outside body. The sanity cell was outside the bound, as registered. The 9 wrong matches among queries without a counterpart include identical records that the official links do not connect, and they are counted as wrong.

Competitors: Splink 5.0, Dedupe (classifier refitted on the same labelled registry pairs) and RapidFuzz token-sort ratio on the normalised name, each deciding among the same top-10 candidates that Match retrieved. Each threshold was chosen on a separate calibration split by one rule, written down first: the most matches at a weighted bound of 0.1%, or, where no threshold reaches that, the lowest bound it can reach. None of the three reached 0.1% at any threshold on a grid of up to 400. This compares the decision step on identical candidates; it is not a claim about every way those tools can be configured or deployed end to end. Match was not trained on registry data.

Latency was measured on a Raspberry Pi 400 (Cortex-A72, one core) and a desktop CPU, single process, warm index. Register data is used under each publisher’s licence.