Entity Bind vs Fuzzy matching
Free, already there, and perfectly good until a wrong merge costs money.
There is no vendor on the other side of this comparison. The alternative is your own time and your own error rate, and both are worth measuring before you commit further: send the rows where a wrong merge costs money, and see which of them we would refuse.
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.
Fuzzy matching: Free, in your warehouse today, and perfectly good at catching the obvious duplicates. Entity Bind: A similarity score is not calibrated. Ours is measured against labelled outcomes and refuses to bind below the floor.
3 of the 10 rows in the table below go to Fuzzy matching and 7 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
A Levenshtein distance, a Jaro-Winkler score or a well-tuned probabilistic record linkage model in your warehouse is free, runs on data that never leaves your estate, has no per-record cost, and catches the obvious duplicates perfectly well. For a great many jobs that is the correct answer. Two things it structurally cannot do: calibrate, because a similarity score is a statement about two strings rather than about how often decisions like this one turned out right; and abstain, because it has no evidence outside the two strings to establish that it should. Entity Bind brings register evidence to the comparison, refuses below a published floor, and writes a receipt. The trade is cost, latency and a dependency you did not previously have.
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 Fuzzy matching
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.
- A wrong merge costs money, a customer relationship or an audit finding.
- You need to explain a merge to someone months later, from evidence rather than from a threshold.
- The hard rows are the ones that matter, and your matcher's behaviour on them is unmeasured.
- You want the register consulted rather than only the two strings compared.
- You want the system to decline rather than to return its best guess, and to tell you which column would have settled it.
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 Fuzzy matching
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, and it is already running. No procurement, no vendor risk, no contract.
- Nothing leaves your estate. For data that genuinely cannot be sent anywhere, that is decisive and no argument beats it.
- No per-record cost, so it scales to volumes where per-decision pricing is absurd.
- It works on anything — people, addresses, products, parts — rather than on companies only.
- Latency and throughput are yours to control, with no rate limits and no external dependency to be down.
- Modern open probabilistic linkage libraries are genuinely good, actively maintained, and produce respectable results on clean data with a labelled sample.
Requirements that point to Fuzzy matching
- The consequence of a wrong merge is an untidy report rather than a payment, a contract or a regulatory filing.
- Your data cannot leave your environment under any circumstances and a self-hosted deployment is not on the table.
- Volume is enormous and value per row is low.
- You are matching something that is not a company, where none of our accuracy language transfers.
- You already have a tuned linkage model with labelled outcomes and a team that maintains it.
If one of those is your requirement, say so when you write to us. We will tell you where the answer is Fuzzy matching, 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 Fuzzy matching, dimension by dimension
Every row carries a verdict. 3 go to Fuzzy matching, 7 to Entity Bind and 0 are even. Both columns are filled in on every row, so a verdict can be read against what each side actually does about it.
| Dimension | Fuzzy matching | Entity Bind | Edge |
|---|---|---|---|
| Cost per record | Zero, at any volume. | One credit for a shallow decision, five for a deep one, zero for an abstention or a replay. | Fuzzy matching |
| Where the data goes | Nowhere. It stays in your warehouse. | The no-egress depth setting makes no external call of any kind — no model provider, no registry — but at the depths that resolve the hard tail, the record's fields and any free-text context reach the model provider. | Fuzzy matching |
| Evidence used | The two strings, and whatever else you engineered into features. | The register: legal names, previous names, trading names, status, town, legal form, incorporation date, plus web research where the tail needs it, each cited. | Entity Bind |
| What the score means | String similarity, or a probability from weights you fitted on your own labels. | How often decisions like this one turned out right, taken at the cautious end of the range and recomputed from counts in the test suite. The out-of-fold figure — how the fitted scorer did on records it was not fitted on — is published beside the in-sample one. | Entity Bind |
| Behaviour on a genuinely ambiguous pair | Returns a score. You set a threshold and live with both error types. | Escalates, then abstains — including when the two best candidates are within a hair of each other, or when more than one candidate carries the same decisive identifier. | Entity Bind |
| Contradicting evidence | Usually a feature with a weight, which averages against the others. | One disagreeing strong identifier blocks a merge outright; two or more disagreeing weak signals block it together, because one weak contradiction is noise and several agreeing are evidence. | Entity Bind |
| Order independence | Depends entirely on your implementation. A sequential loop is order-dependent and usually nobody has checked. | Order-independent within a batch by construction, 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. | Entity Bind |
| Audit trail | Whatever you built. Usually a score column. | A receipt per decision including refusals, with features, thresholds, evidence, model and prompt version and a re-scoring from stored features. | Entity Bind |
| Ongoing maintenance | Yours: feature engineering, thresholds, drift, and re-labelling when the data changes. | Ours, and the calibration is regression-tested on every commit rather than reviewed annually. | Entity Bind |
| Scope | Anything you can featurise. | Companies and organisations only. Not people, vessels, products or addresses in their own right. | Fuzzy matching |
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.
The method behind our half of this comparison
5 articles that set out how the decision is made and measured, rather than how it compares.
- GuideWhat is entity resolution?Entity resolution decides which records refer to the same real-world thing. What it is, why company identity is hard, deterministic versus probabilistic matching, and why fuzzy matching is not entity resolution.
- GuideChoose a company matching tool you can defendEvaluate company matching on your records. Download a scorecard for identifier conflicts, unresolved rows, evidence, coverage, controls and pricing.
- 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.
- 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.
- GuidePrecision, recall and abstentionEntity resolution is a three-way trade, not a two-way one. Why abstention is a design choice rather than a failure, what an abstention has to carry to be useful, and how to measure a system that declines.
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 Splink
5/12 rows to themFree, open source, and it weighs the evidence properly: Fellegi–Sunter, done right. Our scoring stage is the same family.
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 Fuzzy matching
How do identifier conflicts change a fuzzy company match?
Consider two fictional rows, Tutorial Willow Ltd and Tutorial Willow Holdings Ltd. Their group domain and name stem agree, but their supplied company numbers differ within the same issuing register. Keep the legal companies separate and verify the identifiers. A high name-similarity score cannot settle that conflict. A third row with a name and no distinguishing identifier may need review. The worked company example in the entity-resolution guide explains all three outcomes without assigning a fabricated confidence score.
Our matcher gets 95% of the duplicates. Why change?
You may not need to. The question worth asking is not what share it catches but what it does with the ones it is unsure about, because that is where the expensive errors live. Two checks are free: pull a sample of the pairs your matcher scored between its accept and reject thresholds and count how many a person would actually merge; and pull a sample it merged automatically and check them against the register. If both come back clean, keep what you have.
Can we keep our matcher and use you only for the hard rows?
That is the sensible shape, and it is what the depth control exists for. Run your own matcher over the file, keep the pairs it decides confidently, and send only the borderline band here — where the per-record cost lands on a small fraction of rows and the evidence is worth paying for. The stateless pairwise endpoint is built for exactly that: two records in, a decision out, nothing stored. Where you need the audit trail, use a resolve instead, because the stateless comparison mints no receipt.
Is a calibrated confidence really different from a good probability model?
Yes, in one specific way. A fitted linkage model produces a probability under its own weights, and unless you have measured it out of fold it is telling you about the data it was fitted on. Every confidence here counts how often that population of decisions turned out right in recorded trials and reports the cautious end of the interval — the 95% Wilson lower bound — with values that are pure functions of those counts and no tunable term, and the out-of-fold figure published alongside the in-sample one rather than instead of it. A threshold needs to be evaluated against the population and coverage of your own records. 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.
What about the records that must not leave our estate?
Two options and one non-option. The no-egress depth setting is enforced in code at both egress points, so those records reach neither a model provider nor a registry — but they get the deterministic and probabilistic stages only, which for a hard row means an abstention rather than an answer. A self-hosted deployment is the other conversation, and it is a conversation rather than a product page, because there is no managed offering and no hosting region today. The non-option is sending the data and hoping. Cap the depth instead.
Settle it against Fuzzy matching 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 →