Head-to-head · updated 13 September 2026
DataShield vs Senzing: after the match is made, who cleans up?
Senzing is very good at one hard thing. Feed it messy records. It tells you which ones are the same person or company. Under a second, on live streams. At volumes most of us will never see. Their pricing page says the slider stops at 1B records. The product doesn't. Their own line for the ceiling above that: "proven in production at ~100B records". That's their number, not an audited one. But the engine behind it is real. Jeff Jonas took the patents out of IBM in 2016. He's been sharpening it ever since. No training, no tuning, no data science team. We won't argue with any of that.
We are a different shape. DataShield's Ontology is a master data platform. Resolution is one part of it. Here's the part we'd point at first: how the model gets built. An agent can do it with you. It talks with a steward. It builds a spec, and walks a decision gate you confirm or override. Then one batch makes the entity types, hierarchies, draft match configs, reference bindings, and rules. Nothing it makes goes live on its own. A draft config still has to train. It clears a frozen test battery, then gets cleared for use. After that, stewards review patterns, not rows. A golden record has to earn the right to be read by an agent. We tokenize datasets at ingest. Agents query tokenized data over MCP. Turning a token back is a privileged, audited step.
We check each tool call against the agent's access, right then. We seal the check into a chain. You can verify it without trusting us. Here is the honest split. Senzing's wins included.
The short version
Pick DataShield when
- You want the model built with you, not billed to you. An agent runs the interview, builds a spec, and works a gate. Then it makes entity types, hierarchies, draft match configs, and rules, in one batch. 15 commands. No setup services. See what Ontology does.
- You need a mastering workflow, not just a matcher. Five survivorship modes with measured source trust. Steward work at pattern grain. A three-rung trust ladder. Hierarchies. Drift checks on every cleared config.
- Agents are going to read those golden records. A golden has to clear a score gate with a fail-closed consent veto before any agent can read it. Access gets re-checked on each tool call. How Auth does it.
- An examiner will one day ask you to prove the access log wasn't edited. Our chain answers with math. A crypto-shred still leaves it verifying. Run the verifier.
Pick Senzing when
- You need resolution in real time on a live stream. Latency is the requirement. That's what their engine is built for. Ours is not.
- Your record counts run into the billions. Their site claims production at roughly 100B records. We do not make that claim. We publish no ceiling of our own.
- You are embedding resolution inside your own app. You want a library, not a platform. Their SDK covers Python, Java, C#, Rust and Node. Their MCP server lets an agent wire it up for you.
- You are federal or defense. Since July 2026 they sell through the AWS Marketplace JWCC catalog. They support air-gapped and classified networks. We cannot match that.
Bottom line: Senzing answers "are these the same entity?" faster, and at bigger scale, than we do. DataShield answers a different question. Who built this model? What is the golden record? Which agent may read it? Can you prove what it read? Plenty of teams should run both. Senzing resolves. DataShield masters and governs. Three months into a Senzing build, writing your own steward UI? That's the talk to have with us.
Feature by feature
Competitor cells describe what Senzing's public site and press releases say. As of the date above. Did we get something wrong? Email support@myorg.ai. We will fix it, and credit you.
| What matters | DataShield | Senzing | Edge |
|---|---|---|---|
| Standing up the model | An agent does it with you. It talks with a steward. It builds a spec from the answers and the live platform state. It shows a decision gate, in order. Each idea carries what it is, why, its impact, and the choices. You confirm or override. An override spreads to every dependent choice. Then one batch makes the entity types, hierarchies, draft match configs, reference bindings, and rules. Each object lands with an honest gate posture. The generator never clears a config. It never runs resolution or skips the battery. | Their pitch: there is no model to stand up. Point the engine at your sources, map the fields, and it learns as records arrive. For a matcher, that's a real advantage. There is no entity-type vocabulary, hierarchy, or survivorship policy to author. Because the product does not master. | ◆ |
| Entity resolution method | Fellegi-Sunter probabilistic linkage. Jaro-Winkler, normalized Levenshtein, Soundex, and Double Metaphone comparators. Plus LSH blocking with a bucket cap. EM-trained parameters run against a frozen holdout. A trained flip in polarity is a hard refusal. An identifier tier routes conflicts to review, tagged by conflict class. Not merged blind. No config reaches production without a green test run through the real scoring path. | Entity Centric Learning, their own method. It treats a resolved entity as one profile, and keeps learning as records arrive. Their pitch is no training and no tuning. That's a real edge on day one. | ◈ |
| Real-time resolution and scale | Batch and on-demand resolution inside Ontology. Good enough for master data. Not a sub-second stream engine. We won't pretend otherwise. Our tests run against roughly 370,000 real public records, across three City of Chicago datasets. We publish no record-count ceiling. | "Sub-second resolution on live data streams". "From tens to billions of records on a single node". An engine that "boots in under one second". Spark support runs billions of records in a single job. | ◇ |
| Multidomain modelling | An open entity-type vocabulary, with three matching modes per type. You model your domain. We do not ship a Customer 360 template you then have to bend. A People, Places, and Things taxonomy is a table row. Not an enum. Hierarchies are parent-scoped. A child config resolves inside its parent's scope at a base level. Across parents, it needs a stricter one. Relationships carry bitemporal validity. Rules gate publication. | There is a source-record model and a resolved entity graph. Domains, hierarchies, and typed relationships between mastered entities are not part of the product. Need a customer domain with a legal-entity parent and rollups? You model that above them. | ◆ |
| Ingestion and binding | Six on-ramps. Inline content, a single URL, batch URLs, presigned uploads, a file repo, and watch sources. Then a catalog bind, built for mastering. Bind a live PostgreSQL object to an entity type once. Mastering then stays current on a set schedule. Pick an auto, agent-review, or steward-review policy. A weekly full pass catches missed deletes. Differential loads mark deleted rows stale. They flag updated ones for a re-check. That is PostgreSQL today, not your whole estate. We are not an ETL product. | Mappers and ingestion pipelines. Their MCP server does the profiling and mapping for you. Spark handles distributed batch loads on EMR, Databricks, Snowflake, and standalone Spark. It is aimed at volume. Not at a mastering cadence with a review policy. | ◈ |
| Survivorship and golden records | Five declarative survivorship modes, written as pure folds. The same spec compiles to SQL. "Most trusted" reads real source trust: measured overturn rates from steward work, not a hand-ranked list. Golden version history is append-only. It survives deletion. A tombstone records the reason and the successor. Confidence stays honest. A probabilistic match carries a number. A deterministic or steward match carries null, not a fake zero. | The engine resolves and publishes an entity graph. We found no survivorship policy authoring or golden-record publication workflow in their public docs. That work lands on your team. | ◆ |
| Stewardship and the trust ladder | Stewards review patterns with evidence. One human decision disposes a pattern, not a row. A counterevidence scan keeps the idea honest. A three-rung trust ladder counts human approvals, not disposed items. 50 approvals at a 98% rate clears a pattern. Zero dissents required. One dissent demotes it. At the top rung, a sampler diverts 10% of auto-disposed items to a human audit. You can show why any item got picked. Standing rules start staged. They need a second release choice. They auto-suspend on an audit overturn. | No steward queue, review workflow, or disposal policy in their public docs. Explainability lets a human ask why two records matched. That helps an investigator. But it is not a queue anyone works. | ◆ |
| Agent-admission gate on goldens | A golden record has to earn the right to be read by an agent. Six score axes carry set weights and floors. It needs a combined score of at least 0.70. Every graded axis must clear its own floor too. A consent axis is a hard veto. No recorded lawful basis means no permission. One rule enforces this on both the SQL path and the app path. The two cannot drift. Accuracy and fit only score where you have written rules for it, and we say so. | Not part of the product. A resolved entity is readable by whatever holds the connection. Score gating on use is your problem to solve above the engine. | ◆ |
| Tokenization and data handling | We tokenize datasets at ingest. Agents query tokenized data over MCP. Turning a token back is a privileged, audited step. The golden view and the SQL views mask in the view, not a setting. The reader role has no grant on the base table. Derived phonetic and n-gram fields inherit the base field's verdict. A name cannot be rebuilt from its Soundex. A matching field tokenized at rest makes a run refuse, typed. Not merge blindly. | The engine needs real values to match on. It runs inside your infrastructure, so those values stay with you. Tokenization and masking are not part of the product. | ◆ |
| Agent authorization | Every checked tool call passes a scope ceiling and a consented-tool allowlist. Plus an access tier and a revoke re-check before dispatch. Metering ties back to the agent. The call fails closed. | Their MCP server helps an agent deploy the engine, map sources, and query the identity graph. It is a build tool. We found no per-call check for who may read a resolved entity. | ◆ |
| Audit evidence | A SHA-256 hash chain with Ed25519-signed checkpoints. Those checkpoints chain too. Verification returns clean, attested damage, or tampered. It names the break. Inside MDM, every change writes a before and after row, in the same transaction. Try the verifier. | Match decisions are explainable. You can drill in and ask why two records matched. That's decision transparency, which is useful. It is not tamper evidence over an access log. | ◆ |
| Break-glass | Scoped, time-boxed emergency access for agents. Admin and step-up gated, auto-revoking. It cannot be quietly deleted from the log. On the mastering side, there's a matching safety spine. Guarded runs clear a canary before ramping. Scope-keyed pause and kill flags stop the fleet. A microbatch rolls back to a pre-image marker. | Not described in their public docs. | ◆ |
| GDPR erasure | Crypto-shred of per-subject key material, plus ISO 27560 consent receipts. A consent record covers all six GDPR Art. 6(1) lawful bases, across nine purposes. One live fact per subject and purpose. Only the derived consent score crosses the masking boundary. The audit chain still verifies after erasure. | Not addressed publicly. Worth asking, because a resolved entity graph is exactly where a deleted subject tends to survive as a link. | ◆ |
| MCP and agents | More than 200 MCP tools across Ontology, Auth, Corpus, and Lighthouse. MCP tool tokens carry scope ceilings on Auth's surface. Master data alone is 143 commands. That's 32% of the whole agent surface: 99 on the MDM tool, 29 on stewardship, 15 on guided onboarding. Goldens reach agents through masked views, a value-free CloudEvents outbox with 21 event types, RAG grounding documents, and a DuckDB dimension. There is no REST API for goldens, by design. | A real MCP server, shipped with the Spark launch in March 2026. It was packaged for the Kiro agentic IDE in May 2026. It drives profiling, mapping, ingestion, and graph queries. It says plainly it does this "without touching transactional data". | ◆ |
| Deployment and public sector | Self-hosted, in your own cloud or data center. Or a dedicated single-tenant server we run. Docker images cover Auth, Ontology, Corpus, and Lighthouse. Guardian verifies a signed deploy manifest. No federal authorization path today. | Runs entirely inside buyer infrastructure. AWS and Azure marketplaces, AWS Quickstart, a serverless pattern, and since July 2026 the JWCC catalog. On-premises, hybrid, air-gapped, and classified network support. | ◇ |
| Pricing | Published model. A scoped instant quote. No sales wall. | Published too, which is rare here. Their site lists 10M data source records at $58,560 a year. A slider to 1B, support included. Free record allowances exist for tests. One-day proofs of concept up to 10M records. | ◈ |
| Maturity signals | Auth, Guardian, and Lighthouse are live in production. Guardian and Lighthouse have run since April 2026. SOC 2 not yet certified, and we say so. | Founded 2016 out of IBM, with Mithril backing. The Placekey buy landed in December 2025. They have a long partner list. A Forrester study they paid for in October 2025 reports 226% ROI, from interviews with four customers. Treat the ROI figure as their claim. Treat the company's track record as the real signal. | ◇ |
◆ DataShield leads◇ Senzing leads◈ comparable
Senzing claims come from senzing.com and Senzing's own press releases. Last checked 13 September 2026. We link them below rather than work from memory.
Three things you get here that you won't get from an entity resolution SDK
An agent that builds the model with you
Most MDM money goes on a services deal before a single record gets mastered. Here an agent talks with a steward and builds a spec. It walks a gate where every idea explains itself. An override spreads to what depends on it. One batch then makes the entity types, hierarchies, draft match configs, reference bindings, and rules. Everything lands as a draft. A match config still has to train, pass a frozen battery, and get cleared. See what Ontology does.
Golden records that earn their readers
An engine tells you two records are one entity. It does not decide if that entity is fit for an agent to read. Ours has to clear six score axes, with set weights and floors. Plus a consent veto that fails closed when no lawful basis is on record. The same rule runs in SQL and in the app. The two cannot quietly disagree. How we keep that boundary.
Authority that can change mid-flight
An analyst leaves on a Friday. Their agent is 20 minutes into a 40-minute job over your customer master. With DataShield, we re-check the next tool call against current access. It fails closed. Not at the next token refresh. The next call. Then the check gets sealed into a chain anyone can verify. How Auth does it, and run the verifier.
Where Senzing is genuinely stronger
Start with speed, because it is not close. Senzing resolves in under a second on live streams, and boots in under a second too. They cite production use near 100 billion records. That last figure is their number, not an audited one. But nothing we run comes near it. Our resolution is batch and on-demand, built for master data. Not for a fraud call that has to land before a transaction clears. Entity Centric Learning is also a good answer to a real problem. Our match configs need training, a frozen battery, and a clearance gate. Theirs needs none of it. On day one, that gap is worth weeks. Their pricing is public, which almost nobody in this market does. They ship fast too: Placekey in December 2025, Spark in March 2026, a Kiro package in May 2026, the JWCC listing in July 2026.
Is your job to embed resolution in an app? Buy their library and get on with it.
Now the push-back. Read their own words on the Kiro release. The agent queries the identity graph "without touching transactional data". That's a fair line for an engine vendor to draw. It's also the exact seam where your own duties live. A matcher hands you clusters. It does not hand you a domain model or a survivorship rule. It does not hand you a steward who can undo a merge. It does not hand you a gate that keeps a half-consented record away from an agent. Or proof an examiner can check. Those are not add-ons you bolt on in a sprint. We watched a team spend seven months building that layer by hand. They still didn't have the erasure story. The regulated buyers we talk to are not losing sleep over match accuracy.
They are losing sleep over an agent with a stale token, reading a customer master at 2am. Nobody can prove afterward what it saw. That layer is ours. It sits on top of a resolver like theirs, without complaint.
Questions worth asking both of us
These are the questions we would want answered if we were the ones buying. Ask them on each call, ours included.
Can you cryptographically prove an audit log entry wasn't deleted?
DataShield: yes. Each record commits to the one before it. We sign and chain each checkpoint. Verification tells deletion apart from truncation and from tampering. Inside MDM there is a second trail. Every change writes its before and after, in the same transaction. Try the chain at /verify. Senzing: their explainability lets you ask why two records matched. A different, useful thing. We found no tamper-evidence check over an access log in their public docs. Ask them to show one.
What happens to a revoked agent mid-session?
DataShield re-checks access on each tool call. Revoke lands on the next call, not the next token refresh. There is a second brake on the mastering side too. A guarded run clears a canary before it ramps. A scope-keyed kill flag stops the fleet. Senzing's MCP server drives the engine and queries the graph. We could not find session revoke or per-call checks in their docs. Ask how long a compromised agent keeps reading resolved entities after you pull its access.
How does GDPR erasure interact with the audit trail?
DataShield crypto-shreds per-subject key material. It issues an ISO 27560 consent receipt too. Actor identities in the chain carry HMAC commitments, not names. The proof still checks out once the subject is gone. Consent itself is a record, not a checkbox. All six GDPR Art. 6(1) lawful bases, across nine purposes, one live fact per subject and purpose. No recorded basis means no permission. Senzing does not address erasure publicly. This matters more for a resolver than for most tools. A deleted person leaves behind the links that joined their records. Ask what happens to those.
We already run Senzing. Do we rip it out?
No. Keep it as the resolver, if it's doing the job. Especially if you need stream speed. Run DataShield above it, for the parts they don't sell. That's the domain model, survivorship, and golden publication. Steward work at pattern grain. PII and PHI classification. Masked reads behind a score and consent gate. Agent authorization, and the audit chain. Most teams who call us already own a matching engine of some kind. The build they are tired of is everything around it.
Can an agent really set up master data management on its own?
It can take you most of the way. It is deliberately not allowed to finish. Fifteen commands cover the interview, the spec, the gate, and the build step. What comes out is drafts. Entity types, hierarchies, draft match configs, reference bindings, and rules at warning level, each labelled with its gate posture. A human confirms or overrides every choice. There is no accept-all button, on purpose. A draft match config only goes active after training, a green test battery, and an explicit clearance. Senzing's agent story is the mirror image. Their MCP server lets an agent deploy and drive their engine. Useful, but not the same job.
Isn't DataShield's entity resolution just a weaker Senzing?
On raw speed and volume, yes. We'd rather say so than bluff. On method, it is not a toy. Fellegi-Sunter probabilistic linkage, with Jaro-Winkler, Levenshtein, Soundex, and Double Metaphone comparators. LSH blocking, EM-trained parameters against a frozen holdout. An identifier tier sends contradictions to review. A drift monitor proposes retraining, and never acts on its own. We test against roughly 370,000 real public records, across three City of Chicago datasets, not only synthetic ones. We publish no accuracy headline. One leg of our own benchmark is weak. Hiding that would be worse than admitting it. If you can name the algorithm you're buying, you can argue with it.
Does DataShield have SOC 2?
Not yet, and we will not imply otherwise. Auth is live with a public threat model. Anyone can run the verifier. Guardian and Lighthouse have been in production since April 2026. Design-partner terms include source escrow. So a small vendor is not a single point of failure. Details on the security page.
- Senzing's positioning: "Know who's who before it matters". Also "sub-second resolution on live data streams" and scale "from tens to billions of records on a single node". - senzing.com, 13 Sep 2026
- Senzing's published pricing: 10M data source records at $58,560 per year, a slider to 1B. Their own claim: "The slider stops at 1B. Senzing doesn't. Proven in production at ~100B records." - senzing.com pricing, 13 Sep 2026
- Agentic Entity Resolution for Apache Spark, beta v1.0, on EMR, Databricks, Snowflake and standalone Spark, driven by the Senzing MCP server. - Senzing press release, 24 Mar 2026
- Kiro Power bundles the Senzing MCP server. Agents deploy the engine, write mappers and query identity graphs "without touching transactional data". - Senzing press release, 1 May 2026
- Senzing-commissioned Forrester Consulting Total Economic Impact study, based on interviews with four customers. 226% ROI, $19.7M net present value over three years, payback under six months. - Senzing press release, 23 Oct 2025
- First composable entity resolution offering in the AWS Marketplace JWCC catalog. Supports on-premises, hybrid, air-gapped and classified networks. - Senzing press release, 9 Jul 2026
Other head-to-heads
DataShield vs Zingg
Open-source matching on Spark, versus a mastering workflow with evidence.
MDMDataShield vs Reltio
A SaaS MDM cloud, and the agent controls it doesn't ship.
MDMDataShield vs Informatica MDM
Multidomain breadth, versus depth where the agent reads.
AllEvery comparison
One honest scorecard per vendor.
See the parts an engine leaves you to build. An agent talks with a steward and builds a draft model. A survivorship rule picks a winning value. A steward disposes a whole pattern in one decision. A golden gets blocked from an agent because consent lapsed. Then a chain still verifies. Demo Center access is free with a work email.
Get free Demo Center accessYou've seen the proof
Ready for a number? Scope your deployment and we'll price it against your own economics.
Get your quote →