Data Design & a Coherent Enterprise Data Platform — why “market models” are a living program
Data Design & a Coherent Enterprise Data Platform — why “market models” are a living program
A modern Enterprise Data Platform (EDP / SI Data) isn’t a tool or a one-off project. It’s a product-platform you operate over time. Its core, Data Design, sits on a canonical enterprise model (shared entities across the company) extended with sector plug-ins (banking, insurance, healthcare, finance) aligned to market standards. That’s how you get interoperability, measurable quality, traceability, and cost control—while staying evolutive with changing use cases, regulations, and tech.
1) Working definition
Data Design = semantic architecture + data contracts + policy-as-code to make quality, security, and compliance executable.
Coherent SI Data = an enterprise canon (Customer, Account/Policy/Contract, Product, Event/Movement, Party/Third-party, Reference) with sector profiles mapped to standards (e.g., ISO 20022 for payments, ACORD for insurance, FHIR/OMOP for health).
Why it’s never “done”: rolling releases of standards (ISO 20022, FHIR), new reporting taxonomies (XBRL, EBA), new journeys, and cyber threats mean you must version and operate the model like a product.
2) Market standards that shape Data Design
These frameworks don’t mandate a single tech stack; they provide a common language, schemas/messages/APIs, and often reporting taxonomies.
| Sector | Standard / Framework | Scope | Formats / Artifacts | Typical uses |
|---|---|---|---|---|
| Insurance | ACORD | Data standards & messages (Life, P&C, Health, Reinsurance/GRLC), reference architecture | XML/JSON, APIs, impl. guides | Underwriting, policies, claims, reinsurance, ecosystem interop |
| Payments & Banking | ISO 20022 | Modeling method + dictionary + message sets (pain/pacs/camt) | Semantic model, MDR/MUG, XML/JSON | Payments, cash mgmt, richer data (CBPR+, instant rails) |
| Capital Markets | FIX | Real-time pre-trade/trade/post-trade messaging | Message specs | Orders, executions, allocations, multi-asset STP |
| OTC Derivatives | FpML | Vocabulary & messages for OTC products | XML + message framework | Confirmations, post-trade reporting, lifecycle |
| Financial Reporting | XBRL / IFRS Taxonomy | Digital tagging of IFRS statements | Taxonomies XBRL/iXBRL | Publication, machine-readable comparability |
| Banking Regulatory (EU) | EBA DPM → XBRL (FINREP/COREP) | Data Point Model → taxonomies | DPM, XBRL | Prudential reporting, validations, regulator submissions |
| Healthcare (clinical exchange) | HL7 FHIR | Modular resources (Patient, Encounter, Observation…) & REST API | FHIR specs (R4/R5), IGs | EHR interop, mobile apps, payer/provider exchange |
| Healthcare (observational research) | OMOP CDM (OHDSI) | Common data model + standardized vocabularies | Schema + vocabs | Harmonize EHR/claims for multi-site analytics |
| Clinical Terminologies | SNOMED CT / LOINC | Clinical ontology / lab & observation codes | Code systems, value sets | Problem/act coding (SNOMED), lab results (LOINC) |
Key takeaway: adopting market standards reduces integration friction and hardens exchange/reporting—without locking you into one technology.
3) Building a coherent SI Data around these standards
3.1. Canonical model + “sector plug-ins”
Canon: Customer/Person, Account/Policy/Contract, Product/Coverage, Operation/Event, Reference, Party/Partner.
Plug-ins:
- Banking: ISO 20022 (pain/pacs/camt), FIX (markets), FpML (OTC).
- Insurance: ACORD (incl. GRLC for reinsurance).
- Healthcare: FHIR (resources & IGs) + OMOP for analytics; SNOMED/LOINC as terminologies.
- Financial reporting: IFRS Taxonomy / EBA DPM→XBRL.
3.2. Data Contracts & Policy-as-Code
- Executable schemas: validate messages (e.g., pacs.008) or resources (e.g., FHIR Observation) in CI/CD.
- Terminology conformance at ingestion (value-set checks for LOINC/SNOMED).
- Privacy & access as code (RBAC/ABAC, masking, retention) enforced in pipelines.
3.3. Platform layers
- Data Highway (batch/stream/CDC) with contracts and column-level lineage.
- Executable governance (catalog, glossary, policy engine).
- Poly-store tiers (hot/warm/cold) + polyglot engines (lakehouse/warehouse/graph/OLAP).
- Semantic / Feature layer (logical model, metrics, feature store).
- Activation (standards-based APIs & events, BI/analytics, ML copilots & agents).
3.4. Observability, Quality, FinOps
- SLO/SLA for data (freshness, completeness, accuracy), cost per query/use case, MTTR for data incidents.
- Regulatory KPIs (XBRL/DPM conformity rate; FHIR IG coverage).
4) Anti-patterns to avoid
- Monotechnology/monocloud → dependency & high exit costs.
- “Dashboard factory” without canon or contracts → brittle decisions.
- POC-therapy without industrialization → value that never scales.
- “Paper governance” → non-executable, non-auditable rules.
5) Example mapping (high level)
| Canonical Entity | Banking (ISO 20022) | Insurance (ACORD) | Healthcare (FHIR/OMOP) |
|---|---|---|---|
| Customer / Party | Party/Agent (business component) | Party, Insured/PolicyHolder | Patient (FHIR), PERSON (OMOP) |
| Account / Policy / Contract | Account, CashAccount | Policy/Contract | Coverage; Encounter (context for coverage) |
| Event / Movement | Payment (pacs.), Statement (camt.) | Claim, Endorsement, Premium | Observation, Procedure, Claim |
| Product | Product (fees/charges structures) | Product/Coverage | Plan/Benefit (payer); DRUG/PROCEDURE (OMOP) |
| Reference Data | Currency, Scheme, BIC/IBAN | ACORD codes, product lines | SNOMED/LOINC terminologies |
(Exact mapping depends on profiles/message sets; the point is the controlled crosswalk.)
6) Pragmatic 12–24 month roadmap
0–90 days — Secure the Highway
- Inventory domains + pick the enterprise canon.
- Select target standards per domain (ISO 20022/FIX/FpML, ACORD, FHIR/OMOP, XBRL).
- Stand up data contracts (ingest + validate), catalog, and lineage.
3–6 months — Prove Value
- Ship 2–3 flagship data products (e.g., enriched ISO 20022 payments, ACORD claims, FHIR Patient/Observation API).
- Track time-to-first-dataset, contract coverage, FHIR/XBRL conformance.
6–12 months — Scale & Govern
- Generalize policy-as-code (quality, privacy), feature store, semantic layer.
- Integrate terminologies (SNOMED/LOINC) & OMOP vocabs for health analytics.
12–24 months — Optimize & Open
- Cross-domain orchestration, resilience, FinOps.
- Open up to partners (bank/insurance/health) via standards-based APIs and exchange profiles.
7) What leadership gains
- Interoperability with partners & regulators (lower integration costs).
- Provable quality (contracts, validations, lineage) and auditability (XBRL/FHIR conformance).
- Faster time-to-value (reuse of models & IGs) and lower risk (battle-tested standards).