Skip to main content

CryspIQ® vs master data management

These two answer different questions.

  • MDM asks: "Which of these records is the real customer?"
  • CryspIQ® asks: "Can I trust the answer?"

MDM decides which record is the master. CryspIQ® encourages every other system to align to it.

A master data management programme reconciles duplicate records through matching rules, survivorship logic and steward review, and produces a golden record. That settles who the customer is, in one place. It doesn't make the billing system, the CRM or the field service app agree with it.

CryspIQ® does. It encourages alignment to the identified master data source, whether that's an MDM platform or a system you've chosen as the master. Records that connect to the master load, with their transactions held against the same party. Records that don't are held back and shown to the data steward, who fixes them in the source system. Over time, the other systems come into line.

Is CryspIQ® an MDM tool?​

Not in the usual sense. CryspIQ® is not a matching engine: it doesn't guess that two differently spelled records are the same customer. It encourages every other source to align to the identified master data source, and it holds the transactions against that master in the same model. See How CryspIQ® encourages alignment to the master.

How CryspIQ® encourages alignment to the master​

1. The business key is agreed with your data steward. Every organisation's landscape is different, so there's no fixed recipe. During onboarding, we work with your data steward to agree which fields make up the business key for each kind of party: fields held in the master data source that your other systems should also hold. For a person, for example, that might be surname, first name and date of birth; your landscape may call for something else. The key is independent of any one system: it isn't the record ID from the MDM platform or from any other application, so no system has to be replaced or re-keyed for it to work. Agreeing it once is what drives consistency across the rest of your landscape.

2. Each party is loaded from the master data source. Customers, products, assets or locations come in from the identified master, and CryspIQ® forms each one's business key from those fields.

3. Every other source is matched on the same fields. When a non-master source sends a record, such as an invoice, a service job or a CRM contact, CryspIQ® forms the business key from the same fields in that record. Where they match, the record connects to the right party, and its transactions are held against it. The billing system doesn't need to know the MDM platform's ID. It needs the agreed key fields, in this example surname, first name and date of birth, to be there, and right.

4. Data quality checks look for those fields as each record arrives. Rules on the map check that each field in the business key is present and valid in every source system's records, along with the other fields that matter. A record from a system that doesn't capture date of birth, or has it blank or malformed, is caught on the way in rather than found later in a report.

5. Records that don't line up go to the Parking Lot. A record that's missing a key field, or whose key doesn't match a party in the master, isn't rejected and isn't loaded half-complete. It's held in the Parking Lot, with the source system and what's missing shown.

6. The data steward cleans up the source, and the record heals itself. CryspIQ® doesn't patch data in flight. The data steward is prompted to work with the source system owner and correct the record where it lives: fill in the missing date of birth, fix a misspelt surname, or get the person set up in the master. When the corrected record or the missing context arrives, the parked record is released and loads automatically, with no reprocessing.

Supporting your data quality initiative​

The same checks show the gaps in your master data, not just in the other systems. A party that transactions keep referring to but that was never set up in the master, or master records with a key field missing, such as a blank date of birth, all surface in the Parking Lot and on the steward dashboard.

That gives your data quality initiative a starting list and a way to measure progress. The data steward sees which gaps are in the master and which are in each source system, works through them with the system owners, and watches the data quality score improve as records are fixed and released. CryspIQ® doesn't replace that initiative; it gives it the evidence and keeps score.

The result is a list, by source system, of exactly which records disagree with the master and why. That's the work an MDM programme usually can't see once the golden record is published, and it's how the non-master systems get cleaned up over time rather than reconciled again on every report.

What MDM is​

A discipline and a product category for managing the entities a business talks about — customers, products, suppliers, locations. An MDM platform ingests records from every system that holds them, matches records that appear to be the same real-world thing, decides which attribute wins when they disagree, and publishes a reconciled version back out.

Informatica MDM, SAP Master Data Governance, Reltio, Semarchy and Stibo Systems are the products most often shortlisted for this, and Microsoft's Common Data Model and Dataverse solve a related problem from inside the Microsoft estate.

The category exists because the problem is real and hard, and the tooling in it is genuinely sophisticated.

Where the two actually differ​

Master data alone, versus master data and transactions together. This is the difference that matters most in practice. MDM resolves who your customers are; it does not usually hold what they bought. The transactions stay in the warehouse, so somebody still joins reconciled master data to unreconciled transactional data, and the join is where consistency is regained or lost. CryspIQ® models both in one structure: a monetary fact, of a defined type, about a party, at a place, at a time.

Deciding the master, versus bringing every system into line with it. MDM's golden record is an output: it depends on matching rules being right, survivorship being agreed and stewards keeping up, and it lives in the MDM platform. Every other system can keep disagreeing with it. CryspIQ® encourages alignment to the master on every source it loads, one business key at a time, without depending on any system's own IDs, and shows the data steward each record that doesn't line up, so the disagreement gets fixed at source rather than reconciled again downstream.

Where the definition argument happens. Both approaches require the organisation to agree what a customer is, and that argument — not the technology — is where most master data programmes actually stall. MDM gives you an excellent place to fight it. CryspIQ® narrows it, because the structure already says a party is a party and a monetary fact is a monetary fact; the discussion becomes mapping each source onto a definition that exists rather than negotiating one from nothing.

Scope of the answer. MDM is typically bought per domain — customer MDM first, product MDM later — and each domain is its own implementation. CryspIQ®'s dimensions cover entity, product, asset and location from the outset, so a second domain is mapping rather than another programme.

Where MDM is stronger​

Matching and survivorship, by a distance. If you have millions of customer records across forty systems with no reliable common key, spelling variants, merged businesses and decades of manual entry, MDM's matching engines exist precisely for that and are very good at it. CryspIQ® is not a matching engine and should not be sold as one.

Merge and review workflow. Mature MDM platforms have deep tooling for deciding the master itself: match review queues, escalation, and an audit of who merged what and why. Regulated environments often need exactly that. CryspIQ®'s stewardship tools, the Parking Lot and the steward dashboard, are aimed at the other side: getting the non-master sources to agree with it.

It leaves your architecture alone. MDM slots beside what you have. Adopting CryspIQ® means mapping sources into a model, which is more change.

The honest read: if your problem is deciding which of many unkeyed duplicate records is the customer, MDM is aimed at it and CryspIQ® is not. If your problem is conflicting definitions — the same customer counted differently by finance and sales, both working from clean data — MDM is aimed slightly past it, because it reconciles records rather than meanings.

Using both​

This is the natural arrangement. The MDM platform decides the master and publishes the golden records. CryspIQ® loads them as the master data source, then encourages every other source to align to them: forming each business key from fields in the golden record that every source should hold, checking those fields as records load, and parking the records that don't connect so the data steward can fix them at source.

MDM keeps doing what it's best at, and CryspIQ® makes its decisions stick across the rest of the estate, with the transactions held against the same parties. What stops being necessary is the downstream modelling built to join master data to everything else. See co-existence.

Product details last reviewed October 2026.