Head-to-head · updated 13 September 2026
DataShield vs TIBCO EBX: who governs the golden record once an agent is the one reading it?
EBX has mastered data longer than most data teams have existed. It trades as ON EBX now. Offices sit in Fort Lauderdale and Paris. The site claims 26 years of work. The pitch is model-driven MDM. You define the model. The platform hands you the screens, the workflows, the trees. Plus the reference data. Plus the golden records. PostNL, Panera Bread, and Rabobank are named customers. That's a real product with real scars. We won't pretend otherwise.
We build the same golden records. But we let an agent build the model with you. Ask for a client master. Our agent talks with a business user. It derives a spec. Then it walks a choice gate. You confirm or override each proposal, in order. One step builds the whole draft model. Everything lands as a draft first. Nothing goes live until a frozen test check passes. It runs on the real scoring path. Underneath: Fellegi-Sunter linkage, with trained parameters. We tokenize datasets at ingest. Agents query tokenized data over MCP. Detokenization is a privileged, audited step. Here's the honest split, EBX wins included.
The short version
Pick DataShield when
- You want the model stood up in weeks. Not booked as a services deal. An agent talks with a user. It derives the spec. It builds the draft model in one step. 15 guided-onboarding commands. No consultants. See Ontology.
- Agents, not just stewards, are about to read your golden records. A record has to earn that read here: a quality score above the bar, each axis above its floor, and a consent check that fails closed. How Auth does it.
- Someone will ask you to prove the match trail was not edited later. An examiner, an auditor, or Article 12 of the EU AI Act. Our chain answers with math. Run the verifier.
- You want the matching method written down, not called configurable. We name ours. Fellegi-Sunter linkage. EM-trained m and u values. A drift check on each promoted config. The price is published too.
Pick TIBCO EBX when
- You need packaged multi-domain modelling. Customer, product, location, and assets in one model. Cross-domain links and trees that don't duplicate. EBX was built for that shape of problem and we were not.
- Reference data management is the actual job. Codes, classifications, standards, controlled updates and approval chains across dozens of systems. This is EBX home turf, and Rabobank is their proof of it.
- Business users must own the data in a screen, day to day. EBX builds the editing forms and the review workflows. Plus the steward roles, from the model. Our dashboard is plainer, and our first-class surface is MCP.
- A system from 2009 still runs the business. It speaks SOAP or JMS. EBX lists both, plus a Java extension point. We do REST and MCP, and that is the whole list.
Bottom line: EBX models master data for people, and it does that well. We let an agent build the model with you. Then we gate who may read the result, and prove what happened. If your programme is a multi-year, multi-domain rollout, with a steering committee: buy EBX. If agents will be querying client data this quarter, start where the proof problem bites.
Feature by feature
Competitor cells describe what ON EBX's public site says. As of the date above. If we mischaracterised it, email support@myorg.ai. We will correct it, credited.
| What matters | DataShield | TIBCO EBX | Edge |
|---|---|---|---|
| Standing up the model | An agent does it with you. The guided-onboarding tool talks with a user. It derives a spec from the answers, plus the live platform state. Then it serves a choice gate, in dependency order. Each proposal carries a what, a why, an impact. Plus the options. You confirm or override. An override propagates. Each dependent choice reopens for re-derivation. There is deliberately no accept-all button. One single step then builds the whole model. Each object is labelled with an honest gate posture. The generator never promotes a config. It never runs matching. It never skips the check. 15 commands. No consultants needed. | A model-driven studio plus a project. You or a partner define the model. EBX builds the editing screens, the checks, the approval workflow. And what a record goes through after. That's the classic MDM shape. It works. It's a programme, not a conversation. | ◆ |
| Multi-domain modelling | An open entity-type list. You model your domain, not a template. There are three wired matching modes per type. A People/Places/Things taxonomy is a table row. Not an enum. Trees are parent-scoped. A child resolves inside its parent first. It crosses parents only at a stricter threshold. Links carry validity dates. Check rules gate golden publication. There is no drag-and-drop studio. The path for a user is a guided interview instead. What we don't have is a packaged Customer 360. | The core of the product, and the reason people buy it. Model-driven data structures. Cross-domain links and trees. No prepackaged schemas. | ◇ |
| Getting data in, and keeping it current | Six on-ramps into mastering. Inline, URL, and batch ingest. Storage watch sources that poll S3, Azure, GCS, SFTP, and FTP. A resumable file repository. And a catalog bind of a live PostgreSQL object. No rows leave it. Bind once. Mastering stays current on a declared cadence. Pick an auto, agent-review, or steward-review remaster policy. Differential loads mark deleted source records stale. They flag updated records for re-evaluation. A weekly full pass reconciles deletes. Live binding is PostgreSQL today, not your whole estate. We are not an ETL product. We won't sell you one. | REST, SOAP/WSDL, JMS messaging, CSV, XML. Excel import and export, plus Java extension points. Wider legacy reach than ours. We found no mastering-specific refresh cadence or human-review policy named. | ◈ |
| Reference data management | Curated ISO reference sets for countries, currencies, and languages. Versions are write-once and pinned. Each value gets a generated normalization mapping. Staleness and drift roll up across each consumer. We build a business glossary from entity types. Loading your own reference tables as governed sets doesn't work yet. We won't imply it does. | A named feature, with its own use case. Standardized datasets. Controlled updates and approvals. Cross-system consistency, definitions, and classifications. | ◇ |
| Matching and survivorship | Fellegi-Sunter record linkage. Each comparison level carries an m and a u probability. The match weight is log2(m/u). The weights add. Comparators are exact, Jaro-Winkler, normalized Levenshtein, Soundex, Double Metaphone, n-gram. Plus date, numeric, and date-of-birth proximity. LSH blocking uses a bucket-size cap. Common names can't blow up the run. We train parameters with EM, against a frozen holdout. A trained polarity inversion gets refused outright. There are five survivorship strategies. Most-trusted reads measured overturn rates. Not a hand-ranked source list. No config goes live until it's trained. Its polarity must be right too. It must also pass a frozen paired-gate check. That runs the real scoring path. PSI drift monitoring then watches each promoted config. It proposes retraining. It never acts. An absolute-identifier tier routes identifier conflicts to human review. Never a blind merge. Batch and on-demand. Not a sub-second stream engine. | "Smart match and merge": configurable match, merge and survivorship rules with clear match results for stewards. No linkage model, comparator set, training method, or drift check is named publicly. | ◆ |
| Stewardship and the trust ladder | Stewards work patterns, not rows. One human choice disposes a whole pattern. The evidence and a counterevidence scan come attached. The proposal argues against itself. Trust climbs a three-rung ladder. 50 approvals at a 98% rate, no dissent. That promotes a pattern. One dissent demotes it. At the top rung, a sampler diverts 10% of auto-disposed items. Back to a human. You can prove why any item was sampled. A standing disposition rule is born staged. It needs a second explicit release. It auto-suspends on an audit overturn. Blast-radius dry runs use the writer's own gate code. A preview can't say yes and then refuse. Merge, unmerge, separate, link, defer. Record locks, field pins. All first-class and reversible. | A steward workbench, built from the model. Review workflows, approval chains, roles, and clear match results. A business user can own it without an engineer. The screens are better than ours. We found no trust ladder or audit-sampling method named. | ◈ |
| What an agent is allowed to read | A golden record has to earn the right to be read. By an agent. The admission gate wants three things. A combined quality score of at least 0.70. Each of six quality axes above its own floor. A consent check that fails closed. Consent covers all six GDPR Article 6(1) lawful bases, across nine purposes. No recorded basis means no. Not granted by default. One predicate enforces the gate. It covers the SQL path. And the application path. Reads then come from views. The view and the reader role do the masking. Not a setting. Each read tells you what it excluded, and why. | Rights, roles and access control, plus check rules and lifecycle states. Quality gates the record for a steward. We found nothing that gates a read on consent. Nothing on a quality score. Nothing written for a non-human reader, either. | ◆ |
| Audit evidence | SHA-256 hash chain with Ed25519-signed checkpoints that are themselves chained. Checking returns clean, attested damage, or tampered. It names the break. Golden version log is append-only. It survives a delete. A tombstone keeps the rationale and the successor ids. Try the verifier. | Audit trails and lifecycle tracking, plus lineage and traceability. We found no cryptographic tamper-evidence claim in their material. | ◆ |
| Agent authorization | Each checked tool call passes a scope ceiling. Plus a consented-tool allowlist, and an access tier. It gets a revoke check before dispatch. The call fails closed. Delegation uses RFC 8693 token exchange, with an enforced scope ceiling. | Rights, roles and access control, for users and services. Agents are not mentioned anywhere on their site. | ◆ |
| Break-glass | Scoped, time-boxed emergency access for agents. It's admin and step-up gated. It auto-revokes. It can't be quietly removed from the log. Mastering has its own stop too: scope-keyed pause and kill flags. A global kill halts auto matching across the fleet. A kill never silently clears. | Not named in their public material. | ◆ |
| GDPR erasure | Crypto-shred: deleting the subject key destroys each ciphertext for that subject at once. An ISO 27560 consent receipt fires at grant and withdrawal. The audit chain still checks out afterwards. The golden change stream carries no attribute values. And no record keys. So there is no purge cascade to chase through it. | Lifecycle control, versioning and retirement of records. The erasure method is administrative delete, as far as their docs say. | ◆ |
| Tokenization and masking | Deterministic, join-preserving, vault-reversible tokens, applied at ingest. Plus quasi-identifier generalization. Dates to year, decade, or age band. ZIPs to 3 or 4 digits. Partial phones, SSNs, emails. Each column gets a measured cardinality-reduction score. Matching runs on real source values. A match field tokenized at rest makes the run refuse. It throws a typed error, not a mega-merge. Derived phonetic and n-gram fields inherit the base field's verdict too. A name can't be rebuilt from its Soundex. | Not a term they use. Data protection is expressed as rights and checks. | ◆ |
| MCP and agents | More than 200 MCP tools. Across Ontology, Auth, Corpus, and Lighthouse. Tool tokens carry scope ceilings. Per-call metering ties back to the agent. Master data alone is 143 of the 447 commands on Ontology. 99 for mastering. 29 for stewardship. 15 for onboarding. That's about a third of the whole agent surface. All pointed at one job. | REST, SOAP/WSDL, JMS, file import and export, and Java extensibility. No MCP server, and no agent surface we could find. | ◆ |
| AI features | No copilot. We don't proxy your LLM traffic. We do gate each value that leaves a checked dataset. That's for a prompt. A PHI dataset refuses an endpoint without a BAA. Agent-ready goldens also get projected into grounding documents, for retrieval. Those render from the already-masked view. A record that leaves the gate has its chunks deleted. | An embedded AI Assistant, for record-level steward tasks. Plus AI-assisted enrichment, with human oversight. Their AI story is about feeding models better data. That's a fair, different bet. | ◈ |
| Deployment | Self-hosted, in your own cloud or data center. Or a dedicated single-tenant server we operate. Docker images ship for Auth, Ontology, Corpus, and Lighthouse. Guardian checks a signed deploy manifest. Ed25519 audit-signing keys stay on your instance. You control the key directory. Rotation is kid-keyed. It fails closed on an unknown key. KMS or HSM custody is a built seam in Auth. Not a shipped integration. HMAC tokenization keys sit in your environment today, not in a KMS. | On-premises, hybrid, and cloud-supported. The 2022 TIBCO Cloud EBX SaaS branding: it hasn't carried over. Not to the new site. | ◈ |
| Maturity signals | Auth, Guardian, and Lighthouse run live now. Guardian and Lighthouse, since April 2026. SOC 2 not yet certified. We say so. Mastering is 114 modules and 67 tables. It's validated against about 370,000 real public records. Across three City of Chicago datasets. We publish no record-count ceiling and will not invent one. | Their site claims 26 years of MDM behind them. It names customers in logistics, food service, banking. PostNL's case study is theirs. The cost saving in it is their figure, not ours. Long enterprise track record. Two offices. A support organisation. | ◇ |
| Pricing | Published model, scoped instant quote, no sales wall. | Quote only. No price, no trial, no free tier. The demo request on each page is a Google Form. | ◆ |
◆ DataShield leads◇ TIBCO EBX leads◈ comparable
ON EBX claims are drawn from onebx.com and docs.onebx.com. 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 MDM suite
A model an agent builds with you
Most MDM projects open with a services deal. Ours opens with a conversation. The agent asks what you master. Which systems are the source of truth. Who stewards the result. Then it drafts the model. It asks you to sign off, choice by choice. In dependency order. Override one, and each choice below it reopens. The objects it makes land as drafts. Nothing runs live until a frozen test check passes. See how Ontology does MDM.
Proof that survives an audit
A merge log that can be silently edited proves nothing. Ours is a hash chain with signed checkpoints. It tells you what broke, not just that it did. That's the property EU AI Act Article 12 and HIPAA §164.312(b) reviewers care about. Try it in your browser, no signup.
A record that has to earn its read
A supplier analyst leaves on a Friday. Their agent is 20 minutes into a 40-minute run. It's across your golden supplier records. The next checked tool call gets re-checked against current access. It fails closed. Those records were only visible to begin with. Each one had to clear a quality score. Six axis floors. A consent check that fails closed. A workflow engine notices on Monday. How Auth does it.
Where TIBCO EBX is genuinely stronger
We would rather you heard this from us. EBX is model-driven in a way we are not. That matters more than it sounds. You describe client, product, location, and asset in one model. Links and trees live between them. The platform builds the editing screens, the checks, the approval workflow. Plus what happens after. A data steward in the finance office can then run it. No engineer needed. Reference data is a first-class product there. Not a side effect. That's why a bank like Rabobank uses them for exactly that. Their site claims 26 years of implementations. It publishes three client stories. They also carry a legacy integration surface we can't match. SOAP, JMS, Excel import, Java extension points. If your estate still talks in those verbs, that's not nostalgia. It's a rule.
Here's the push-back. It has two halves. Their AI story points upstream. Better structured data. Richer context. An assistant that helps a steward finish a record. All good. But none of it answers what a 2026 risk committee asks. Say an agent read the golden client record at 03:12. Under whose access grant? Had that record cleared a consent basis? For that purpose? Can you prove the line wasn't edited later? The second half costs more money. Standing up the model there is still a project. You staff it. You schedule it. Here, it's an interview an agent runs with you. You work through a choice gate. One step writes the draft model. ON EBX publishes audit trails and lineage. We couldn't find tamper-evidence. Or per-call authorization. Or mid-session revoke checks. Nor a crypto-erase that leaves the audit log standing. Both routes are defensible.
Only one of them has a verifier you can run yourself.
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. Checkpoints are Ed25519-signed and chained. It tells deletion apart from truncation. And from tampering. Golden version log is append-only. It survives a delete. The tombstone still carries the rationale. Run it against a sample chain at /verify. ON EBX: their platform page lists "audit trails and lifecycle tracking" and lineage. We found no tamper-evidence method named. Ask them to show one.
What happens to a revoked agent mid-session?
DataShield re-checks access on each checked tool call. Revocation lands on the next call. Not the next token refresh. Mastering has a second brake too. A global stop flag refuses auto matching runs across the fleet. A kill never quietly clears. ON EBX names roles, rights, and access control for its data services. Agents are not in their word list at all. So there's nothing to compare. Ask how long a compromised account keeps reading golden records. Even after you pull its access.
How does GDPR erasure interact with the audit trail?
DataShield crypto-shreds the subject key. That destroys each ciphertext for that subject at once. It also issues an ISO 27560 consent receipt. Actor identities in the chain are HMAC-committed. So the proof still checks out once the subject is gone. The golden change stream carries no values and no record keys. Nothing has to be chased through it. ON EBX offers versioning, lifecycle control and retirement. That reads as administrative deletion. Ask for the method, not the workflow. Ask what the audit log looks like afterwards.
We're evaluating a TIBCO EBX alternative for mid-market MDM. What do we lose?
The modelling studio, mainly. Gone are the generated business-user screens. You lose a multi-domain model a non-engineer can evolve in a UI. You also lose a deep reference data product. And a very long reference list. Here's what you gain instead. A named matching method. An agent that drafts the model with you. It asks you to approve it, choice by choice. Golden records must clear a quality and consent gate. That's before an agent reads them. A published price. And a verifier. If your programme is client or supplier records, in one quarter, self-hosted: worth it. If it's a five-domain rollout with a steering committee, it's not.
ON EBX has an AI Assistant. Isn't that the same thing?
No, and they don't claim it is. Their card names generative AI help for a human finishing record-level tasks. Check workflows sit around it. That's a copilot for a steward. It's a good thing to own. We use AI at two other points. One: an agent stands the mastering model up with you. Each object it writes lands as a draft you approve. Two: an autonomous agent asks for 4,000 golden records over MCP. Something has to decide what it may see. And write down what happened. A copilot doesn't answer that second one.
Does DataShield have SOC 2?
Not yet, and we will not imply otherwise. Auth is live with a public threat model. A verifier anyone can run backs it. Guardian and Lighthouse have run live since April 2026. Design-partner terms include source escrow. So a small vendor isn't a single point of failure. Details on the security page.
- ON EBX's current positioning: "Turn enterprise data into trusted context for AI and business", a "model-driven, multi-domain platform" for master, reference and metadata. - onebx.com, 13 Sep 2026
- Match story, verbatim: "Smart match and merge: identify duplicates and maintain golden records using configurable match, merge, and survivorship rules, with transparent match results for data stewardship." - onebx.com/platform, 13 Sep 2026
- Integration surface is REST, SOAP/WSDL, JMS messaging, CSV/XML/Excel files and Java extensibility. No MCP server or agent tooling is listed. - onebx.com/platform, 13 Sep 2026
- AI feature, verbatim: "AI Assistant capability: Generative AI assistance embedded in EBX to help users complete record-level tasks." Deployment is on-premises, hybrid and cloud-supported. - onebx.com/platform, 13 Sep 2026
- ON EBX's own claim of "26+ years of master data management expertise", with governance framed as validation rules, permissions, audit trails and lifecycle tracking. - onebx.com/why-on-ebx, 13 Sep 2026
- Customers named by ON EBX: PostNL (their case study claims a 30-40% reduction in MDM technology costs), Panera Bread, and Rabobank for centralized reference data. - onebx.com/resources, 13 Sep 2026
Other head-to-heads
See both methods run in your browser. Break a live audit chain. Revoke an agent mid-session. Then decide what your MDM platform still owes you. 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 →