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 and it tells you which ones are the same person or company, in under a second, on live streams, at volumes most of us will never see. Their pricing page says the slider stops at 1B records and the product doesn't: "Proven in production at ~100B records." Jeff Jonas took the patents out of IBM in 2016 and has been sharpening that engine ever since. No training, no tuning, no data science team. We are not going to argue with any of it.

We are a different shape. DataShield's Ontology does entity resolution too, with methods you can name and check, but the match is the start of our job rather than the end of it. Survivorship rules pick the winning value. A stewardship queue catches the cases the engine sends to review. Golden records reach agents behind masked views. Datasets are tokenized at ingest; agents query tokenized data over MCP; detokenization is a privileged, audited operation. Every governed tool call is checked against the agent's authority right then, and the decision is sealed into a chain you can verify without trusting us. Here is the honest split, Senzing's wins included.

Get free Demo Center access Get an instant quote

The short version

Pick DataShield when

You need a mastering workflow, not just a matcher. Survivorship strategies, a review queue, hierarchies, and drift monitoring on the match config, all shipped rather than built by you.
Agents are going to read those golden records, and someone has to decide which agent may ask for what. Authority is re-checked on every governed tool call and the call fails closed. How Auth does it.
An examiner will one day ask you to prove the access log was not edited. Our chain answers with math. Run the verifier.
The same system also has to classify PII and PHI, tokenize it, mask it, and crypto-shred a subject on request. One stack, self-hosted, keys you hold.

Pick Senzing when

You need resolution in real time on a live stream, and latency is the requirement. That is what their engine is built for, and ours is not.
Your record counts run into the billions. They cite production at roughly 100B records. We do not make that claim.
You are embedding resolution inside your own application and want a library, not a platform. Their SDK covers Python, Java, C#, Rust and Node, and 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, and they support air-gapped and classified networks. We cannot match that.

Bottom line: Senzing answers "are these the same entity?" faster and at larger scale than we do. DataShield answers "so what is the golden record, who may read it, and can you prove what they read?" Plenty of teams should run both, with Senzing resolving and DataShield mastering and governing. If you are three months into a Senzing build and writing your own stewardship UI, that is the conversation to have with us.

Feature by feature

Competitor cells describe what Senzing's public site and press releases say as of the date above. If we have mischaracterised something, email support@myorg.ai and we will correct it, credited.

What matters	DataShield	Senzing	Edge
Entity resolution method	Fellegi-Sunter probabilistic record linkage with Jaro-Winkler, normalized Levenshtein, Soundex and Double Metaphone comparators, LSH blocking, and EM-trained m/u parameters. Match configs are drafted, trialled, explained, trained and promoted, with an absolute-identifier tier that routes identifier conflicts to review instead of merging blind.	Entity Centric Learning, their own method, which treats a resolved entity as one profile and keeps learning as records arrive. Their pitch is no training and no tuning, which is a real advantage 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, and we will not pretend otherwise.	"Sub-second resolution on live data streams", "from tens to billions of records on a single node", and an engine that "boots in under one second". Spark support runs billions of records in a single job.	◇
Stewardship and golden records	Five declarative survivorship strategies, a review queue with decide, batch, reopen, assign, escalate and undo, validation rules gating publication, parent-scoped hierarchies, and Population Stability Index drift monitoring on every promoted match config.	The engine resolves and publishes an entity graph. We found no stewardship queue, survivorship policy authoring, or golden-record publication workflow in their public material. That work lands on your team.	◆
Tokenization and data handling	Datasets are tokenized at ingest; agents query tokenized data over MCP; detokenization is a privileged, audited operation. Golden reads mask PII, and derived phonetic and n-gram fields inherit the base field's verdict. A tokenized-at-rest matching field makes a run refuse, typed, rather than mega-merge.	The engine needs real values to match on, and it runs inside your infrastructure so those values stay with you. Tokenization and masking are not part of the product.	◆
Agent authorization	Every governed tool call passes a scope ceiling, a consented-tool allowlist, an authority tier and a revocation re-check before dispatch. Metering is attributed 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 authorization decision point for who may read a resolved entity.	◆
Audit evidence	SHA-256 hash chain with Ed25519-signed checkpoints that are themselves chained. Verification returns clean, attested damage, or tampered, and names the break. Try the verifier.	Match decisions are explainable: you can drill in and ask why two records matched. That is 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, and it cannot be quietly deleted from the log.	Not described in their public material.	◆
GDPR erasure	Crypto-shred of per-subject key material plus ISO 27560 consent receipts, and a consent-validity substrate that records a lawful basis per subject and purpose. The audit chain still verifies after the 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, with MCP tool tokens carrying scope ceilings on Auth's surface. The MDM tool alone dispatches 99 commands.	A real MCP server, shipped with the Spark launch in March 2026 and packaged for the Kiro agentic IDE in May 2026. It drives profiling, mapping, ingestion and graph queries, and 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 operate. Docker images for Auth, Ontology, Corpus and Lighthouse, with a signed deploy manifest Guardian verifies. No federal authorization path today.	Runs entirely inside customer infrastructure. AWS and Azure marketplaces, AWS Quickstart, a serverless pattern, and since July 2026 the JWCC catalog, with on-premises, hybrid, air-gapped and classified network support.	◇
Pricing	Published model, scoped instant quote, no sales wall.	Published too, which is rare here: 10M data source records at $58,560 a year, a slider to 1B, support included. Free record allowances for evaluation and one-day proofs of concept up to 10M records.	◈
Maturity signals	Auth, Guardian and Lighthouse are live in production (Guardian and Lighthouse since April 2026). SOC 2 not yet certified, and we say so.	Founded 2016 out of IBM, Mithril backing, a Forrester Total Economic Impact study in October 2025 citing 226% ROI, the Placekey acquisition in December 2025, and a long partner list.	◇

◆ DataShield leads◇ Senzing leads◈ comparable

Senzing claims are drawn 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

The work that starts after the match

An engine tells you two records are one entity. It does not tell you which address to keep, who signs off on the merge that looked wrong, or what to do when the match config quietly drifts. We ship survivorship rules, a review queue, and a stability index on every promoted config. See what Ontology does.

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 the next governed tool call is re-checked against current authority and fails closed. Not at the next token refresh. The next call. How Auth does it.

An erasure you can defend

GDPR says delete. Your auditor says keep the log. A resolved entity graph makes this worse, because the subject lives on as links between records. Crypto-shred destroys the subject's key material, the data goes unreadable, and the chain still verifies. See the diagram.

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, and they cite production use near 100 billion records. Our resolution is batch and on-demand, built for master data rather than for a fraud decision that has to land before a transaction clears. Entity Centric Learning is also a good answer to a real problem: our match configs want training and a promotion gate, theirs wants neither, and on day one that difference is worth weeks. Their pricing is public, which almost nobody in this market does, and a Forrester study in October 2025 put customer ROI at 226% with payback under six months. They ship fast as well: Placekey in December 2025, Spark in March 2026, a Kiro package in May 2026, the JWCC listing in July 2026. If your job is to embed resolution in an application, 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 is a fair boundary for an engine vendor, and it is also the exact seam where your obligations live. Matching runs on real values, so the values move, and nothing in the product decides who may ask, masks what comes back, or leaves an artifact an examiner can check. 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 and nobody being able to prove afterwards what it saw. That layer is ours, and 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 every call, ours included.

Can you cryptographically prove an audit log entry wasn't deleted?

DataShield: yes. Each record commits to the one before it, checkpoints are signed and chained, and verification tells deletion apart from truncation and from tampering. Try it at /verify. Senzing: their explainability lets you ask why two records matched, which is a different and useful thing. We found no tamper-evidence mechanism over an access log in their public docs. Ask them to show one.

What happens to a revoked agent mid-session?

DataShield re-checks authority on every governed tool call, so revocation lands on the next call rather than the next token refresh. Senzing's MCP server drives the engine and queries the graph. We could not find session revocation or per-call authorization in their material. 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 and issues an ISO 27560 consent receipt. Actor identities in the chain are HMAC-committed, so the evidence still verifies once the subject is gone. Senzing does not address erasure publicly. This matters more for a resolver than for most tools, because 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 is doing the job, especially if you need stream latency. Run DataShield above it for the parts they do not sell: survivorship and golden-record publication, the stewardship queue, PII and PHI classification, tokenized and masked reads, 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.

Isn't DataShield's entity resolution just a weaker Senzing?

On raw speed and volume, yes, and we would 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, and a drift monitor on every promoted config. Tested against real Chicago open data, not only synthetic records. If you can name the algorithm you are 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 and a verifier anyone can run. 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", with "sub-second resolution on live data streams" and scale "from tens to billions of records on a single node". — senzing.com, 13 Sep 2026
Published pricing: 10M data source records at $58,560 per year, a slider to 1B, and "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 so agents deploy the engine, write mappers and query identity graphs "without touching transactional data". — Senzing press release, 1 May 2026
Forrester Consulting Total Economic Impact study: 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, supporting on-premises, hybrid, air-gapped and classified networks. — Senzing press release, 9 Jul 2026

Other head-to-heads

MDM

Get free Demo Center access

You've seen the proof

Ready for a number? Scope your deployment and we'll price it against your own economics.

Get your quote →