Unified Digital: Identity, Product Linking & Access — the Evergreen deck
| Source | client-resources/Evergreen_IdentityandProductLinking_UnifiedDigital.pdf |
| Type | PDF, 68 pages: program slides, key slides, architecture background, Appendix A (MDM unification review), working scenarios |
| Origin | Canada Segment and GWAM partnership, Unified Identity workstream (workstream 1). Appendix A is the MDM team's review |
| Dated | June 2026 on the cover; a living deck, with data snapshots to August 2026 · received 2026-10-27 |
| Classification | Confidential |
What it is
The program and strategy deck for workstream 1, Unified Identity & Product Linking. The auto-linking solution and scenarios are the solution design for the same work. The deck carries the MVP scope, the approach decision, a delivery plan, the customer population and MDM coverage data, a North Star architecture, the release architecture for the home page, and the MDM team's account of how MDM is built and controlled. Several slides are templates with placeholder values (p8, p11, p20, p21); the data slides are not.
What it establishes
Manulife chose reconciliation first, and governance approved it. Two approaches are compared (p17). Identity by reconciliation: business units keep creating customers, MDM matches after the fact and issues the ECID, and products are associated once confidence is established, batch-oriented and not real-time at point of sale. Identity at origination: the ECID is created first and every product inherits it. The recommendation is reconciliation now, with origination as the long-term target, and the deck records architecture governance approval of the MDM linking strategy (p15). The MVP scope puts a net-new enterprise key at origination, upstream origination modernization and upstream duplicate prevention out of scope, marked for further validation (p6).
Delivery is two tracks (p33). Track A, experience first: the unified home page on existing identity and business-unit integrations, which is the November 2026 dashboard. Track B, data foundation: MDM, identity resolution and data quality, with Retirement and Group Benefits as the first tenants. Track B is MVP release 2.
The workstream planned a launch around March 2027 (p26). Mastering runs July 2026 to about February 2027, the digital experience to about February 2027, and readiness and launch to about March 2027. Legal, privacy and contractual review runs to February 2027. Stewardship and data remediation are not started and undated. Manulife has since put release 2 at June/July 2027, about four months later.
MDM is a hub and spokes, stored and served in Manulife's Azure (p43–47, p54). One Informatica spoke per business unit maintains the business-unit unified customer, and a hub maintains the Canada unified customer. In the deck's words, "the main data store resides in Manulife Azure layer (ADLS, Databricks & Mongo DB) and Informatica SaaS is used to perform match and merge". Consumption is through APIs and Databricks, and the API serving layer is moving from Azure AI Search to MongoDB after search glitches left customers "not found". Data reaches Salesforce through MuleSoft. Source systems feed MDM in daily batches or streams; creating the customer in MDM first is used only in the US. No slide describes MDM publishing events.
The data (p18–25, p36–39):
| Measure | Value |
|---|---|
| Active owner, member and authorized-individual source records | 9.31M |
| In MDM | 8.49M (91.2%), unified into 5.54M people |
| Outside MDM | 815K, about 81% of it Affinity Travel, Mortgage Creditor and IMAC |
| Group Benefits | 2.5M records flow through MDM, but match and merge is not enabled; a sandbox was never operationalized |
| Suspect matches (70–95% confidence) | 32K, and suspect-match review has mostly not run for years |
| Operational data stewards | 0 or 1 per business unit; the MDM team asks for at least 1 FTE per unit |
| People with one active CIAM login | 2.64M (47.6%), of whom 88.8% already have every product linked |
| People with no active CIAM login | 2.59M (46.7%), which the deck calls the largest activation opportunity |
| A login linked to another person's MDM record | 62,883 |
| One MDM record with several logins | 50,401 |
| Excluded populations | 1.46M iFast nominees, 164K organizations, 83K records with critical name-field issues |
MDM already unmerges (p39, p52). A change to SIN, name or birth date on an existing customer is automatically unmerged and triaged by a steward, usually within 12 hours. Two records with different SINs joined through a third with a null SIN are also unmerged automatically.
Reads come from Azure, not from Informatica
The storage line corrects a premise. A lookup of a customer's ECID, policies or accounts is served by the Azure serving API, not by a call to Informatica SaaS. The deck shows the pattern in production: the Insurance Customer Secure Site has pulled a customer's policies from MDM's unified view after login since 2023 (p51). That view is a business-unit spoke, not the hub. Wherever the read path was argued as a cross-cloud call to a SaaS product, the argument does not hold.
The target's case for D3 does not rest on that premise. Direct MDM reads were rejected because mastering availability and stewardship work should not bound channel availability, and two client sources take the same line: the MDM inventory requires reads to survive an MDM outage, and the target architecture draft makes no MDM call at login. The Azure serving layer has one owning team, a recent history of "customer not found" incidents, and an unknown regional footprint. Matching still runs in Informatica SaaS, so release 2's real-time registration match and the bulk reconciliation keep the cross-cloud proof at milestone 0, unless the "real-time MDM search" in the auto-linking design is a MongoDB search rather than an Informatica match. D3 also projects business-unit facts, such as balances and claim status, that MDM does not hold.
What changes is the source. The Azure layer is already a read-optimized copy of the golden record: the identity and relationship half of D3. D3's relationship facets can be fed from a change feed on that layer, which is a more plausible publisher of ordered events than Informatica SaaS. A direct read of the serving layer at sign-in becomes an option to test in milestone 0 against the service objectives, rather than one ruled out by location. The cited login rate is 12 to 15 a second, so capacity is not the constraint; regions, ownership and freshness are.
Impact on the target architecture
The ERR boundary is the client's Enterprise Relationship Layer. The North Star (p16) places the ECID golden record, a product registry, consent management and profile management in one Enterprise Relationship Layer, above a policy and enforcement layer. The target-state illustration (p59) separates enterprise data (golden record, entity resolution, survivorship, batch stitching) from operational data (unified profile, customer identifiers, real-time business-unit sync, consent storage and sync). That is the target's split between MDM as authority and D3 as operational copy. Drawn properly, the ERR holds the hub, the spokes, Informatica SaaS, the Azure serving layer, stewardship and data quality controls, the consent domain and the product relationships.
The link table is CIAM ID Mapping, and the ECR has no role. The home page architecture (p34) puts a CIAM ID Mapping component inside CIAM, which the shell calls to "Get BU Mappings". The working slides add that the portal keeps reading the CIAM/BU mapping and "some form of job" enriches it from MDM (p61). The BU Mapping Service and the CIAM-MDM link table are therefore one CIAM-owned store, and no client slide has an ECR. The customer identifiers sit in the operational layer. The target can drop the ECR, keep CIAM ID Mapping as an event-fed copy of MDM's links on the CIAM side, outside the ERR, and close O19 by making the MDM job its only writer: today registration writes it directly as well.
The gap in O20 is propagation, not unmerge. MDM unmerges; the auto-linking design does not carry an unmerge through to the login mapping, and the 12-hour steward triage leaves a window in which a login can still see records that were wrongly joined.
One person, one login does not hold. The working slides list reasons a customer keeps separate logins: personal and employer-sponsored products, power of attorney or in-trust accounts, spousal separation (p64). They also flag a shared login where auto-linking would show a spouse a private life policy (p66–67). Visibility therefore cannot be decided by rel_id alone: the customer needs to suppress products, which is a PingAuthorize input, and attorney or trustee access belongs in the authorized-representative model rather than a shared login. The auto-linking design's standard of 1 person = 1 ECID = 1 CIAM, and journey J29, need revisiting.
The claims token is close to Token A. The North Star mints an ephemeral payload of identity, ECID, active product rights and valid consent grant from a central PDP per request (p16). If it is minted per call, it is Token A with authorization_details. The target's difference is that product rights and consent are not carried in a token that outlives the call, and consent is read live before an action.
Search before create argues against an approved decision. The target's position that search before create comes first needs reframing: reconciliation for the existing population, as approved, and search before create only at the registration and enrolment points release 2 already changes, with origination left as Manulife's long-term target.
Impact on the roadmap
Much of the MDM work is Manulife's. Mastering, enabling Group Benefits matching, linking and stewardship belong to workstream 1, which has a product owner, an identity lead and a team of MDM, CIAM, Group Benefits and Retirement engineers (p10). The roadmap's "MDM integration" and "Identity linking: release 2" bars on v4 slides 73 and 74 describe that work. They should become Manulife dependencies, with the target's own epics reduced to the event contract, the D3 projection and the CIAM sync, which changes the cost basis.
Group Benefits first carries the largest data risk. Milestone 2 (Group Benefits live, October 2027) and release 2's Group Benefits scope both wait on mastering 2.5M records that have never been matched, with no steward. Retirement is mastered and would de-risk both, but no application consumes its MDM data today, so quality issues may be undetected (p33). The order is Manulife's decision.
New dependencies: a data steward per business unit, which is an operating-model decision; the employer contract and privacy review to February 2027, which gates Group Benefits and Retirement linking; activation communications for 2.59M people without a login; and a treatment for nominees, organizations and white-label Group Benefits plans.
Release 2's value is first registration. Most customers either already have every product linked or have no login, so registration that finds products automatically (J28) matters more than reconciling existing logins.
Corrections to our published material
- O4: Group Benefits is not mastered at all, not "not fully participating".
- O17: the platform is now known in outline: Informatica SaaS for matching, hub and spokes, an Azure data layer and a MongoDB serving API.
- O19: the store is CIAM ID Mapping, with two writers.
- O20, the section 8 merge paragraph, the section 18 risk and slide 13: "no unmerge" becomes "no unmerge propagated to the login mapping".
- Section 3, MVP architecture: the readiness review recorded the Unified Identity workstream as cancelled; this deck shows it staffed and planned.
- Section 17: search before create, as above.
- Slides 73 and 74: the MDM bars, as above.
Inconsistencies in the deck
- Survivorship is out of scope with a double question mark (p6) and an MVP focus area (p59).
- The MVP promises real-time updates (p4); the chosen approach is batch-oriented (p17).
- The population view assumes Group Benefits is in MDM (p24); the coverage slide says it is not mastered (p18).
Questions for the authors and the MDM team
- In which region or regions does the MDM serving API run, with what service objective, current load and on-call ownership?
- How far does the hub lag the source systems across the raw, curation, spoke and hub hops?
- Does the Azure layer offer a change feed that could publish ordered mastered outcomes?
- Is the CIAM identifier mastered in the hub, given the shell reads business-unit mappings from CIAM ID Mapping?
- Does release 2's registration search call Informatica synchronously, or search the serving layer?
- When will Group Benefits match and merge be enabled, and who stewards it?
- Will multiple logins per person be allowed, and how is product visibility suppressed for a shared or delegated login?