MDM — Informatica Master Data Management

Role	The source of truth for customer identity and the enterprise relationship registry. It is the core system of record for the mastered customer profile
Technology	Informatica MDM. Product, version and topology are unconfirmed (draft V-11, open question 51)
Decided by	ADR-0006, a Manulife ruling on 2026-10-12. The draft's D-10 covers dual-publish
Status in the draft	Validate V-03 (dual-publish) and V-11 (product and graph representation)
Register row	Components

Its role

MDM decides who a customer is and what they hold, and every other component works from its answer. It is the only system that matches records across business units, the only issuer of rel_id, and the only authority for accepted customer-to-product relationships. Business units tell it what happened. It masters that into one customer and publishes the result. Channels never ask it directly: they read the projection it feeds.

rel_id is the enterprise customer identifier. The ADS and the UCL deck call it ECID, and the two names refer to one identifier.

Why MDM, and not something else

It is the only component that sees every business unit's records. Each BU knows its own customers under its own identifier. Saying that a GB member and an Affinity policyholder are one person needs every BU's records side by side, with matching, survivorship and lineage. MDM already does that work. Any other place would have to rebuild it, or depend on MDM anyway.

Today the customer does the linking, by hand, and the MVP keeps it. In the client's MVP plan below, a customer connects each product to their CIAM ID on a Connect Product page. The result is a row in the BU Mapping DB, and that mapping is what reaches MDM. The enterprise learns what a customer holds only if the customer tells it. The segment assessment rates that table a blocker (B-02) because nothing verifies it. We disagree with this plan, and the target replaces the table with MDM as the authority and D3 as the fast-read copy.

Client diagram of the MVP plan, not the live current state. Steps 4–5 are the CIAM ID mapping and the Connect Product page. Step 10 sends the CIAM-ID-to-product mapping to the MDM hub, and step 11 adds Wealth's separate FCC mapping.

One authority is simpler than two. Konrad argued for a separate registry that would own the identifier and accepted links, with MDM only resolving ambiguous records (R5.5, now withdrawn). Manulife chose one system. That removes the reconciliation between two stores that hold the state of one identifier. It also matches the client's own target draft: "Only Informatica MDM decides whether those are the same person, and only MDM issues rel_id."

The direction comes from the business. A Teams message from James Jeffery says Rick wants the team to consider positioning MDM "as the core system of record for the customer profile", which "would require it to become much more operational and real time in nature." That second clause is the work. MDM's own architecture today is built around data lakes.

Client diagram of MDM's internal pipeline. BU data lands in data lakes, is cleansed into a unified Delta Lake schema, matched and merged into a single view of customer, and aggregated with policy and account domains into a Customer 360 view. Integration APIs publish it to Salesforce, and an operational cache serves inquiry APIs.

How business units inform and update it

Three routes feed MDM, and only the first is real time today.

1. Registration. A customer who signs up supplies a BU reference, date of birth and postal code. The BFF posts it through a MuleSoft Process API, and MDM matches it against mastered BU records. MDM then links an existing rel_id or issues a new one. An ambiguous match goes to the D5 stewardship queue. BU systems register customers through the same Process API (draft Fig 02).
2. Batch from BU sources. BU records arrive through the data-lake pipeline above. Product ownership reaches MDM this way until a BU emits events. The draft says it is "limited to batch" without them (§11, card 6).
3. Ownership events, which are the target. The BU that creates or ends a product emits the fact at that moment, and MDM accepts it against the customer, matching at origination as search before create (§11, card 1). This is the route R1.3 argues belongs in the foundation rather than a later phase. Without it, a product bought today appears on the dashboard after the next batch, whatever the freshness target says.

The BU stays the author of the fact in every route. MDM accepts and masters an assertion; it cannot originate the legal fact that a policy or account exists.

What it publishes, and who depends on it

MDM publishes every mastered outcome, including customer.mastered.v1, merge and unmerge, to a Service Bus namespace in each region. Three consumers act on it independently:

• ciam-sync writes rel_id and BU source IDs onto the CIAM user, which is how tokens carry rel_id and bu_subject without querying MDM;
• ecr-sync updates the ForgeRock IDM crosswalk replica;
• the projection workers build the D3 operational profile, which serves every channel read.

System of record does not mean serving system. The draft's rule is that login "never touches MDM": the dashboard reads D3, and MDM can be slow or down without taking channels with it. MDM's own pipeline above draws an operational cache and inquiry APIs serving the customer portal directly. That is a different read model, and the two have not been reconciled. ADR-0006 keeps D3 as the read boundary. Whether MDM can meet the write, event and recovery requirements behind it is open question 51.

What it is not responsible for

• Originating product facts. BU administration systems remain the legal record.
• Serving channels. D3 does that, behind the Profile API.
• Authorization. PingAuthorize decides visibility, and the BU decides actions. MDM supplies facts, not decisions.
• Authentication or tokens. That is ForgeRock CIAM's job.
• Consent. OneTrust is the record.

Planned epics

The MDM team's planned epics for match and merge, grouped by the part of the role each one builds.

Builds	Epics
Business units feeding MDM	Add Bank credit card to MDM · Add GB to MDM, with match and merge · Add Affinity GB to MDM · Create a modified BU Mapping table, joinable to MDM, and add the missing BU systems and portals
MDM serving the unified app	Design and build the unified app's integration flows with MDM · Build the unified app and its integration with MDM · Build the MDM Search API · Build MDM event publications
Correcting identity data	Resolve person records that point to more than one CIAM ID · Resolve records where one CIAM ID points to several persons
Operating model	Onboard BU stewards · Add capacity to the MDM DQM data stewards team · Set up the unified app data quality team · Set up operational and data quality p… (truncated in the list we received)

Several epics map directly onto the role:

• GB with match and merge closes the gap the UCL deck records: Group Benefits, the pilot, is the only BU with no match and merge today. Until it lands, GB members cannot clear MDM's matching gate.
• The BU Mapping table, made joinable to MDM, turns the MVP's customer-built table into an input MDM can master, rather than the control that decides disclosure.
• The two CIAM-ID resolution epics fix the cardinality the whole model assumes, one person to one rel_id. A CIAM ID shared by several people would leak one person's products to another.
• The Search API is the prerequisite for search before create.
• Event publications are the draft's D-10 dual-publish, which V-03 must prove.
• The stewardship epics staff the D5 queue that every ambiguous match lands in.

No epic covers BU ownership events at product creation, or relationship termination. The draft lists neither in its foundation either, and both are covered under Open items.

Open items

• 51: whether the installed Informatica product can carry the role at the target's freshness, ordering, replay, unmerge and dual-region requirements. There is no second registry to fall back on.
• 42: each BU's ownership signal and binding evidence, now as an intake contract into MDM.
• Relationship termination: the draft designs merge and unmerge, but not the end of a product relationship.
• 15: who inherited the cancelled WS 1 Unified Identity MVP, and so who delivers this.
• The read model: whether MDM's inquiry APIs serve channels, or only D3 does.
• Provenance of the two diagrams above. They were shared with the team without a source document. The epics list arrived the same way.