Entity Bind vs Build it yourself
The right answer if entity resolution is your product. Several teams have done it well.
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.
Build it yourself: The right answer if entity resolution is your product. Several teams have done it well. Entity Bind: Eighteen months of register adapters, licence handling and calibration you would rather not own.
3 of the 11 rows in the table below go to Build it yourself 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
Entity resolution is worth building when it is your product, and several teams have done it well: the open probabilistic linkage libraries are genuinely good, and nothing about the matching mathematics is proprietary. The reason most teams underestimate it is that the matcher is the part they cost, and the matcher is the cheap part. What takes the eighteen months is the register adapters and their fragility, the identifier semantics that stop a six-digit number colliding with a charity reference, the licence tier that has to be enforced before a write rather than reviewed after one, the evaluation harness that tells you whether last week's change made things worse, and the abstention policy nobody designs until the first wrong merge. Buying this is buying that, not the matching.
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 Build it yourself
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.
- You need answers this quarter and the build is a year of work you would rather spend elsewhere.
- You do not want to own register adapters, their outages, their terms changes and their schema drift.
- You need an evidence trail and a calibration story you could hand an auditor, and would rather not construct both from scratch.
- You want somebody else accountable for the abstention policy and the confidence semantics.
- You want to find out whether this problem is worth solving before committing a team to 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 Build it yourself
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.
- Total control. Every threshold, every feature, every escalation rule is yours to change on a Tuesday.
- No vendor dependency, no contract, no supplier to be down, and no third party in the path of a decision.
- It can be tuned to your domain in ways a general product will not be — your industry's naming conventions, your own historical labels, your specific error costs.
- At extreme volume the unit economics beat any per-decision pricing, because your marginal cost is compute.
- The core libraries are free, well maintained and well documented, and the mathematics is public.
- If the entities you care about are not companies, building is not just cheaper — it is the only option, since none of our accuracy language transfers to a different ontology.
Requirements that point to Build it yourself
- Entity resolution is the product you sell, or a load-bearing part of it.
- You already have people who have built one before and want to build another.
- Your entities are not companies, or are companies in a domain with its own register nobody else models.
- Volume is high enough and value per row low enough that per-decision pricing does not work.
- You need behaviour no vendor will build, and you would rather own it than negotiate for it.
If one of those is your requirement, say so when you write to us. We will tell you where the answer is Build it yourself, 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 Build it yourself, dimension by dimension
Every row carries a verdict. 3 go to Build it yourself, 6 to Entity Bind and 2 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 | Build it yourself | Entity Bind | Edge |
|---|---|---|---|
| The matching itself | Open libraries, free, well maintained, and good. | The same family of methods — a three-region probabilistic policy with fitted weights — with no claim to a secret algorithm. | Even |
| Control over behaviour | Complete. | You control depth, enrichment and your own review policy. The admission floor is ours and is published rather than configurable, which is the point of an independent policy and is also a real constraint. | Build it yourself |
| Fit to a non-company domain | Whatever you build it for. | Companies and organisations only. A different ontology needs different data and a different evaluation, and no accuracy language transfers. | Build it yourself |
| Unit cost at very high volume | Compute. | Per decision, with abstentions and replays free. Below the register-scale volumes, buying is usually cheaper; well above them, it is not. | Build it yourself |
| Register adapters | Yours to build and maintain, across sources classified by fragility for a reason: some are documented APIs with contractual stability and some are commercial gates that can close. | Built, wired, monitored, with per-source timeouts, capped jittered retries, circuit breakers, per-host egress budgets, and a contract that a dead source degrades the answer rather than failing it. | Entity Bind |
| Identifier semantics | Easy to get wrong in ways that produce silent false positives — there are 1,071 registers across 232 jurisdictions, German numbers are court-qualified and Poland runs three parallel number spaces. | Numbers 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 |
| Licence handling | A policy document and a review. | A refusal on the write path before any write, so a violation cannot even partially persist, with resale reported per field and an unreadable licence reading as not-resellable. | Entity Bind |
| Evaluation harness | The thing most builds skip, and the thing that decides whether the next change is an improvement. | Labelled gold sets, a precision and automation gate that fails the build, per-tier and per-region fixtures, out-of-fold analysis and a published set of numbers including 63.10% automation and 70.78% end-to-end resolution. | Entity Bind |
| Calibration | Usually a threshold somebody picked. | Values derived from recorded trials and errors, recomputed by the test suite so an edited constant fails, keyed by model and prompt version so a model change fails closed rather than silently recalibrating. | Entity Bind |
| Time to a first defensible answer | Months, before the evaluation is trustworthy. | A free preview we run over your file, which calls nothing and spends nothing, then a sample through the cascade. | Entity Bind |
| Who is accountable when it is wrong | You, with the advantage that you can fix it immediately. | Us, with the disadvantage that you cannot. | Even |
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
3 articles that set out how the decision is made and measured, rather than how it compares.
- 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.
- 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.
- GuideHow to measure entity resolution accuracyPrecision, recall, abstention, pairwise versus B-cubed cluster metrics, Wilson intervals and out-of-fold evaluation. Why a single accuracy number for entity resolution is always meaningless, with worked arithmetic.
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 Build it yourself
How long would this actually take to build?
The matcher, a few weeks with an open linkage library and a labelled sample. What follows it is the work: register adapters with their timeouts, retries, circuit breakers and terms; identifier semantics per register; a licence model enforced before persistence; per-field provenance and freshness; an evaluation harness with fixtures you trust; an abstention policy and a review queue; order-independent batch clustering; and receipts. Our own source inventory prices individual national register connectors at one to four engineer-days each, and that is the easy line item on the list.
What is the part teams most often get wrong?
Two, and both are silent. The first is identifier semantics: treating a registration number as a string, so a six-digit number matches a charity reference, or a number scoped only by country decides when its shape does not say which register issued it. The second is order dependence — a sequential loop over a file produces different clusters for different input orders, and almost nobody checks. We measured our own old implementation producing nine different partitions across the twenty-four orderings of four rows, which is why the current one clusters by connected components instead.
Could we use you to bootstrap and then build?
Yes, and it is a legitimate plan. Run your file, get the labelled outcomes and the receipts, and use them as the evaluation set for your own build — the export is NDJSON with per-field provenance, and reviewed labels are appendable and exportable as a reproducible slice filtered by model, prompt, pipeline and evidence tier. What you cannot take is our catalogue or anything whose licence forbids it, and the per-field resale flags tell you which is which.
You are early stage. Is buying you riskier than building?
In one respect, yes. There is no SOC 2, no independent validation, no callable production reference in a regulated firm, and a self-assessed readiness score of 74 out of 100. What reduces the risk is that nothing here is a black box you would be stranded by: the method is published, the evidence is published with its failures, the export is a documented column set, and the receipts are yours. If you build later, you will have a labelled dataset you did not have before.
Settle it against Build it yourself 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 →