Entity Bind vs Splink
Free, open source, and it weighs the evidence properly: Fellegi–Sunter, done right. Our scoring stage is the same family.
Keep Splink for the matching you already do inside your own estate. Entity Bind takes the rows your columns cannot settle: we go to the register for the deciding fact, refuse below a published floor, and write a receipt somebody can read months later.
Your company master has to survive somebody else’s audit, and every merge in it needs a reason a person outside your team can read. This page compares on that axis: what each side is for, where the alternative is stronger, and what we would do in your place.
Splink: Free, open source, Fellegi–Sunter done properly, and it runs where your data already is. Entity Bind: The same family of method, plus register evidence, a published refusal floor and a receipt. If your file is clean, use Splink.
5 of the 12 rows in the table below go to Splink and 6 go to Entity Bind. The rows on their side are the reason to keep what you already run; the rows on ours are what we would add beside it.
The short answer
Splink is an open-source probabilistic record linkage library built at the UK Ministry of Justice, and it is genuinely excellent. It weighs each agreeing field by how much that agreement is worth as evidence — Fellegi–Sunter, implemented properly rather than approximately — estimates those weights from your data by expectation maximisation instead of asking you to guess them, runs inside DuckDB, Spark or Athena so nothing moves, costs nothing at any volume, and has a public track record in government statistical work. Our own probabilistic stage is the same family of method and we make no claim to a secret algorithm. What a linkage library structurally cannot do is look outside the records it was given: it links the rows in front of it, and when the discriminating tokens are absent from all of them, no amount of modelling recovers what was never there. Entity Bind brings the register to the comparison, cites the page it read, refuses below a published floor and writes a receipt. Where a file is clean and internal and somebody on the team can fit a model, Splink handles it and costs nothing.
The answer for your own rows needs your own rows: a few hundred of them, with the matches you already have beside them.
Start freeOn this page
What Entity Bind adds beside Splink
Run both, and this is the half we do. Each of these is a job the other side of this page is not built for.
- The evidence that would settle your hard rows is not in your file at all, and has to be fetched and cited.
- You need a confidence measured against recorded outcomes rather than a probability under the model's own parameters.
- You need the system to decline, and to name the column that would have decided it, instead of returning a score you have to threshold.
- You need a receipt per decision because somebody will ask about a merge months later.
- You have no labelled sample, no data scientist, and a deadline.
A stewardship queue and a supplier file before a payment run want different halves of that list. Create your Free workspace to inspect your own rows, or contact us for a guided review of the checks your workflow needs.
Start freeThe case for Splink
Read these before the table. On some evaluations one of them settles the question on its own, and if it settles yours, keep what you have and put us beside it.
- It is free, openly licensed and open source. There is no procurement, no vendor risk, no contract and no supplier who can be down in the middle of a run.
- You can read the code. Every weight, every blocking rule and every term in the model is inspectable, which is more than we offer: our thresholds and our method are published, our implementation is not.
- It weighs each agreeing field by how rarely that agreement happens by chance — Fellegi–Sunter, done properly — with match weights estimated from your own data by expectation maximisation, and diagnostic charts that show what the model learned.
- It runs where your data already is — DuckDB on a laptop, Spark or Athena at scale — so nothing leaves your estate and the marginal cost of a record is compute.
- It works on any entity. Most of its best-known use is linking people, which is a domain we are out of scope for by design.
- Active maintenance, real documentation, a large user community, and public methodology from an organisation that publishes its statistical work.
Requirements that point to Splink
- Your data cannot leave your environment and a self-hosted deployment here is not on the table.
- You are linking two internal files to each other rather than linking your file to the outside world.
- You have somebody who can design blocking rules and read a match-weight chart, and time for them to do it.
- Your entities are people, addresses or anything that is not a company.
- Volume is enormous and the value of a single row is low.
If one of those is your requirement, say so when you write to us. We will tell you where the answer is Splink, and what running Entity Bind beside it would add: an independent verdict on each match, with the register page that supports it. Cheaper for both of us than finding out in month three.
Entity Bind and Splink, dimension by dimension
Every row carries a verdict. 5 go to Splink, 6 to Entity Bind and 1 is even. Both columns are filled in on every row, so a verdict can be read against what each side actually does about it.
| Dimension | Splink | Entity Bind | Edge |
|---|---|---|---|
| Cost | Zero, at any volume, forever. | One credit for a shallow decision, five for a deep one, zero for an abstention or a replay. Cheaper than a build, never cheaper than free. | Splink |
| Where the data goes | Nowhere. It runs in your warehouse. | The no-egress depth setting reaches neither a model provider nor a registry, but at that depth a hard row abstains rather than resolving. Beyond it, the record's fields leave your estate. | Splink |
| Entity scope | Anything you can featurise. People, addresses, households, products. | Companies and organisations only. A different ontology needs different data and a different evaluation, and none of the figures on this site transfer to one. | Splink |
| Inspectability | Open source. You can read the model, the code and the tests. | The method, the thresholds, the floor and the failures are published; the implementation is not. You can audit our decisions rather than our source. | Splink |
| Fit to your own data | Parameters trained on your file, so the model learns your error patterns and your naming conventions. | Weights fitted on our fixtures, with the out-of-fold figure — how that fit did on records it was not fitted on — published beside the in-sample one. It is not tuned to your file, and where your domain is unusual that is a real disadvantage. | Splink |
| Evidence outside the file | None. A linkage model compares the records it was given. | The register is consulted: legal names, previous names, status, town, legal form and incorporation date, plus registry and web research for the tail, each cited. | Entity Bind |
| What the score means | A match probability under the model's own estimated parameters — well founded, and still a statement about the model. | A lower bound on measured accuracy for the population the decision belongs to, recomputed from recorded counts in the test suite, keyed by model and prompt version so a prompt change fails closed rather than silently recalibrating. Confidence bounds depend on the recorded evidence population; there is no universal score for every match. Read match_confidence_basis and the evidence. A 0.99 filter can return some v8 adjudicated matches while excluding valid identifier matches, so validate its coverage cost on your own inputs. | Entity Bind |
| Behaviour on genuine ambiguity | A score in the middle. You set two thresholds and live with both error types. | A match below 0.90 confidence is unrepresentable. The record comes back as an abstention with a ranked shortlist instead. Escalation happens first, and the abstention names the cheapest column that would have decided it. | Entity Bind |
| Candidate retrieval | Blocking rules you design. Blocking, not matching, is where most linkage projects quietly lose recall. | Candidates are retrieved on the rarest tokens in a name rather than the commonest — rarity-weighted blocking — and on the representative fixture of 2026-08-29 the right company sat inside the top ten every time: recall at ten of 1.0000, zero misses. Every later stage depends on that property, so it is measured. | Entity Bind |
| Identifier semantics | A registration number is a column like any other unless you write the rules yourself. | Numbers are interpreted through their issuing register. A shape that could belong to two registers refuses to decide, and two numbers differing by one visually confusable glyph refuse as well. | Entity Bind |
| Order independence | Clustering by connected components is order-independent by construction, and this is one of the things the library gets right. | Order-independent within a batch, verified: the same sixty records in four orders produce an identical partition. Across differently chunked batches the answer does change, and we publish both directions. | Even |
| Audit trail | The model, the weights and the output table. Reproducible, and not a record of a decision. | A receipt per decision including every refusal, queryable as a population by pipeline version, threshold and date. | Entity Bind |
Three limits sit behind every comparison in this section — what we hold, where we stand and how ready we are — and the comparison hub states all three at full size. The figures in our own column were measured on internal fixtures; the accuracy page carries the method and the population behind each one.
- No SOC 2. It has not been started.
- No independent external validation of the accuracy figures. Every fixture is one we built.
- No production customer holdout. The evidence is internal.
A table cannot weigh those rows against your file, and neither can a fixture of ours — your own records are the only ones that settle it.
Start freeBuilt for, and wrong for
Neither of these depends on which alternative you are weighing. They are the two answers that decide whether the comparison above is worth your time at all.
Teams with a company master they have to defend — an MDM or stewardship queue, a CRM after a migration or a merger, a supplier file before a payment run, or counterparty onboarding that has to survive an audit.
Buying breadth as the product: we hold a fraction of an incumbent’s records and are not building a global company graph. Entity Bind resolves companies and organisations only. It does not resolve people, vessels, bank-account ownership, sanctions exposure, emissions or geolocation, and its results may not be used for eligibility decisions about individuals, including employment, credit and tenancy.
Where the figures on this page come from
Only the numbers that are not ours are listed here. Each one is the vendor’s own published claim. We have not audited anybody’s coverage figure, and as far as we know neither has anybody outside the company that published it.
- Splink, UK Ministry of Justice
The project's own published documentation and description. The characterisation of its strengths here is our reading of it, not a statement on the project's behalf. Recorded on 2026-09-02.
The method behind our half of this comparison
3 articles that set out how the decision is made and measured, rather than how it compares.
- GuideFellegi-Sunter explained, with worked arithmeticThe probabilistic record linkage model behind most matching engines: m and u probabilities, match weights, the three decision regions, and a worked example you can check with a calculator.
- GuideBlocking and candidate generationYou cannot compare every pair. How blocking keys work, why rarity weighting matters, how to measure retrieval with recall@k, and the silent failure mode that mints duplicates.
- GuideCalibration and confidence scoresWhat a calibrated confidence actually means, how expected calibration error is computed, why a similarity score is not a probability, and why an LLM's self-reported confidence is neither.
Prefer to put it to a person? Talk to us instead →
The other options you are weighing
The other 11 comparisons, on the shelves the hub uses. Four are not vendor contests: two are the options that beat most vendors most of the time — the fuzzy match you already run, and building it yourself — and two are categories we refuse rather than compete in.
Data providers and registers
Entity Bind vs OpenCorporates
2/9 rows to themAn excellent register mirror. A register mirror is not a decision.
Entity Bind vs Companies House
3/12 rows to themFree, authoritative, and the right answer for a lot of UK teams. It is one of our sources too.
Entity Bind vs PermID
4/11 rows to themFree permanent identifiers, and largely unrivalled in capital markets. We do not issue them.
Resolution engines and platforms
Entity Bind vs Senzing
5/12 rows to themA mature engine you run yourself, at no cost per decision. It resolves what you give it.
Entity Bind vs AWS Entity Resolution
5/12 rows to themCheap, inside your own account, and it needs no new vendor. It also matches only what you loaded.
Entity Bind vs Tamr
5/12 rows to themMachine-learning mastering at enterprise scale. It learns your labels — including the wrong ones.
Entity Bind vs MDM platforms
5/12 rows to themThey are the system of record. We are a decision layer beside one, and we write nothing.
What you would otherwise do
Not what we are
Questions about Entity Bind and Splink
You use the same method. What exactly are we paying for?
Not the mathematics, which is public. The probabilistic stage here scores a pair and then accepts it, rejects it or sends it up for adjudication — a Fellegi–Sunter three-region policy with fitted weights, the same family Splink implements. What you are paying for is everything around it — register adapters with their timeouts, retries, circuit breakers and terms; identifier semantics per register rather than per country; a licence tier enforced before persistence; per-field provenance and freshness; an evaluation harness with fixtures and a gate that fails the build; an abstention policy; and a receipt per decision. If the matcher is all you need, Splink is the good part and it is free.
Could we run Splink and Entity Bind together?
Yes, and for a large file it is the cheapest sensible design. Run Splink over the whole file in your warehouse, keep the pairs it decides confidently at either end, and send only the borderline band here — where the per-decision cost lands on a small fraction of rows and outside evidence is worth paying for. The stateless pairwise endpoint takes two records and returns a decision without storing anything; use a resolve where you need the receipt.
Splink needs a data scientist. Does yours not?
No: there is no model to fit, no blocking rule to design and no labelled sample to assemble, because the calibration is ours and is regression-tested on every commit. The counterweight is that you cannot tune it either. The admission floor is published and not configurable, the weights are fitted on our fixtures rather than your file, and if your domain has naming conventions nobody else has, a model you fit yourself will beat a general one.
We already run Splink and it works. Should we switch?
Probably not. Two free checks will tell you more than we can: pull a sample of the pairs your model scored between its accept and reject thresholds and count how many a person would actually merge. Then pull a sample it merged automatically and check them against the register. If both come back clean, keep what you have. Where this becomes worth a conversation is the second pile: automatic merges nobody audits, on rows where being wrong costs a payment, a contract or an audit finding.
Settle it against Splink on your own rows.
Create your workspace, verify your email and run your first company file. The Free plan needs no card. Create API keys in your workspace when you need an integration.
300 credits. No card.
For a guided review of your file, explore the Merge Safety Sprint →