SSBI LifeExecutive Cockpit

Ontology & Data Mesh

The logical layer that lets a half-migrated roll-up still answer one question consistently — model once, federate the data, generate insights anyway.

SBI Life Insurance Company Limited · FY26 (Mar'26, audited anchor)
India's #1 private life insurer by Individual NBP (25.5% private share) & IRP (22.9%)
29,344 employees · 1230+ own offices · 9 bancassurance partners
💎 Embedded value & shareholder returnsStep 1 of 7 · the data mesh behind the metricsCompany HierarchyAll journeys
🌐 Enterprise 360 modules· on Ontology & MeshBrowse all 31 views ▾
● LiveBuilt forCIO / Digital Officer / Data· integrate logically, not physicallyCFO / FP&A· one number across many systemsTransformation PMO· insight before full Policy Admin migration

SBI Life can't wait for every office and channel to migrate onto the new Policy Admin System before it gets answers. The fix isn't one warehouse — it's a shared ontology (so everyone means the same thing) over a data mesh (each product & channel owns its data as a product), with a semantic layer that federates them. Insights generate today; they just carry a confidence flag where a domain isn't on the new PAS yet.

Data backing: enterprise ontology · knowledge graph · semantic layer · product registry · office · org
Shared meaning (T-Box)

The enterprise ontology — what the words mean

Ten classes everything maps to. The Office cluster is the keystone: it's where segment, leader, product and zone reconcile.

Company
Company1
SBI Life Insurance Company Ltd (listed)
operates ▾ / owns ▾
The 'who' — accountability & ownership
Segment4
ULIP · Non-Par Savings & Annuity · Participating (Par) · Protection & Group
Product / line10
product families & distribution lines
Leader (Person)16
org / accountability
operates ▾ (segment → site)
The keystone
Office cluster16
the reconciliation point
located in / serves / sells ▾
The 'what & where' — distribution & demand
Zone4
West · North · South · East India
Channel6+
bancassurance, agency, direct, brokers, CSC
Proposal / Application
new-business proposals → issuance
Policy (in-force)780 lakh
in-force policies · renewal premium
Cost partner6
commission · reinsurance · IT · underwriting
Relationships (predicates)
SBI Life operates SegmentSBI Life distributes via ChannelProduct / line rolls up to SegmentSegment sells through Office clusterLeader accountable for Segment / lineOffice cluster located in ZoneOffice cluster serves ChannelChannel sources Proposal / PolicyPolicy generates Renewal premiumOffice cluster sells ULIP / Non-Par / Par / ProtectionCost partner supports Office / Policy
Federate, don't centralize

Each product & channel is a data product on the mesh

60% of premium is already office-grain actual; the rest is read in place from legacy channel systems and reconciled — no big-bang migration required.

Smart Wealth Plus (ULIP)
ULIP (Unit-Linked) · data product
Actuals
data quality / grain97%
Smart Platina (Non-Par)
Non-Par Savings & Annuity · data product
Allocated
data quality / grain92%
Smart Bonus (Par)
Participating (Par) · data product
Actuals
data quality / grain90%
Retire Smart (Annuity)
Non-Par Savings & Annuity · data product
Allocated
data quality / grain87%
eShield Next (Protection)
Protection & Group · data product
Allocated
data quality / grain80%
Group & Credit-Life
Protection & Group · data product
Actuals
data quality / grain78%
Bancassurance Distribution (SBI + 9 partners)
ULIP (Unit-Linked) · data product
Actuals
data quality / grain95%
Agency Distribution (2.82 lakh agents)
Protection & Group · data product
Allocated
data quality / grain75%
Smart Elite (ULIP)
ULIP (Unit-Linked) · data product
Allocated
data quality / grain75%
Digital / Direct & Bima Sugam
Non-Par Savings & Annuity · data product
Region-only
data quality / grain45%
10 product data products (above)
Federated semantic layer
entity resolution · canonical metrics · grain tags
Consumers
Story · Briefing · 360s · Simulator
Defined once, computed everywhere

Governed metrics — the logical layer

Every metric has one definition and a grain. The layer federates it across on-Policy-Admin and legacy domains, flagging where a value is allocated.

MetricDefinitionGrainHow it federates across segments
Gross Written PremiumΣ premium writtenoffice · policyactuals where on Policy Admin; allocated from zone where not
Value of New BusinessAPE × VNB marginsegment · productnew-business value normalized to one basis
Renewal premiumin-force renewal premiumpolicyfrom Policy Admin across all channels
Renewal mixrenewal ÷ GWPsegmentfederated — same formula, many sources
Collection daysreceivable ÷ premium × 365channel · officelegacy channels measured at zone grain, flagged
Persistencypremium retained at 13 / 61 monthscohort · policyper IRDAI 14-Jun-2024 method, across channels
Cross-sell propensityunmet need on the customer basechannel / customerresolved across duplicate channel records
The payoff

How insights generate before integration finishes

1 · Resolve

Entity resolution matches legacy office / channel / partner codes to one canonical node — so a channel's data lines up with everything else.

2 · Federate

Query reads each product & channel's data product in place; the semantic layer maps native Policy Admin / CRM fields to canonical metrics.

3 · Allocate + flag

Where a domain reports at zone level, allocation disaggregates to office on learned drivers and marks it an estimate with a confidence band.

4 · Reconcile

Allocated parts must tie back to the source total; anomalies and duplicate channel records & cost partners across systems are surfaced.

This is not theoretical — it's how this cockpit already works. The Story, Briefing and 360 views read the same governed metrics over on-Policy-Admin and legacy channels alike; 60% of the numbers are office-grain actuals and the balance is Policy-Admin-allocated and labelled. As each domain migrates onto the new PAS, its data product's grain rises and estimates flip to actuals — the mesh closes itself.