BLK 04Domain · 🟢 everyone · ≈5 h · 7 lessons

Insurance domain core

Blockchain projects in insurance fail on domain grounds far more often than technical ones. This module gives engineers the working vocabulary — lifecycle, underwriting, claims, reinsurance, compliance — with a real core system's data model as the worked example.

LO3 · map the domain to ledger designs

L1How insurance actually makes money

Insurance sells a promise: many pay small certain amounts (premiums) so few can receive large uncertain amounts (claims). The law of large numbers makes the pool's losses predictable even though each life or typhoon isn't.

Premiumprice of risk transfer: expected loss + expenses + capital cost ± investment income

Combined ratio(claims + expenses) ÷ premiums. Under 100% = underwriting profit

Reservesmoney held today for claims already incurred but not yet paid — the actuary's core estimate

Floatpremiums held before claims fall due — invested meanwhile

Two structural facts explain most of insurance IT: the product is a data record plus a promise (nothing physical ships), and the promise can run for decades — so record-keeping, auditability, and long-horizon system continuity are existential, not clerical. Now you know why an audit ledger got a life insurer's attention.

L2The policy lifecycle

Fig 4.1 The lifecycle as a state machine. The red edge is the rule Galileo's workbook documents: 31 days without premium → inactive, and the lapse record survives reinstatement.

L3Underwriting & the actuarial 20 minutes

Underwriting is risk selection and pricing at the gate: assess the proposal (age, health, occupation, sum assured…), then accept at standard rates, load the premium, exclude, or decline. The eSubmission spec you'll meet in M07 carries exactly these fields (occupation codes, smoker flag, height/weight, PEP status).
Adverse selection: those who know they're high-risk buy more eagerly — why questions and evidence exist.
Moral hazard: being insured changes behaviour — why deductibles, waiting periods and exclusions exist. (Parametric design in M05 dodges some moral hazard by paying on an index, not on behaviour.)
Actuarial core: price ≈ (probability × severity) + expenses + cost of capital. Reserving estimates today's liability for claims incurred but not reported (IBNR). Both need long, trustworthy historical data — one more reason immutable event history is prized.

L4Claims — the moment of truth

Fig 4.2 Claims flow. Each hand-off is a candidate for shared-ledger coordination or AI triage; the orange loop is the proven subrogation case.

L5Reinsurance — insurance for insurers

Proportional

Quota share

Reinsurer takes an agreed % of every premium and every claim in a book. Smooths results, eases capital strain, simple to administer — but the cession data flow (the bordereau) is a reconciliation grind between systems.

Non-proportional

Excess of loss (XoL)

Reinsurer pays only above a retention: "₱50 M excess of ₱20 M per typhoon event". Layers stack into a tower across many reinsurers — multi-party settlement after a catastrophe is exactly the workflow B3i put on Corda.

Structural takeaway: reinsurance is inherently multi-party, contract-heavy, and reconciliation-rich — insurer, broker, several reinsurers, retrocessionaires — which is why it keeps attracting shared-ledger designs (M05 §6), and why treaty data standards (ACORD) matter to any implementation.

L6Regulation & compliance in one table

Obligation	What it demands	Ledger interaction
KYC / AML	Verify identities, screen sanctions/PEP, monitor transactions, report suspicion	Reusable-KYC consortia (M05); pseudonymous public chains complicate it
Solvency / capital	Hold capital against risk; report (RBC, Solvency II-style regimes)	Trustworthy loss history helps models; tokenized assets raise valuation questions
Conduct & product rules	Licensing, policy wording approval, claims-handling timelines	A smart contract's payout rule may itself need product approval
Data protection (PH DPA, GDPR…)	Consent, purpose limits, erasure rights	PII stays off-chain; the chain stores hashes/references only — design rule from M01
Records retention	Keep policy/claim records for statutory years — often decades in life	The strongest natural fit for append-only, tamper-evident storage

L7Worked example — a real core system's shape

◐ Galileo lens · the whole module in one system

Galileo models the domain as documents around a hub: Policy links a DistributionAgreement (which product, under whose licences), Participants → Party (who is insured/owner), Coverage → CoverageProduct → Product (what protection), Payments → PaymentSettlement (money), plus Documents, Beneficiary and Claim records tied by policy-id conventions.

Its lifecycle rules match Fig 4.1 exactly — including the 31-day lapse rule and lapse history surviving reinstatement. And every state change flows through a blockchain audit ledger before the database is updated, giving the record-retention and auditability rows of L6 for free. Full detail: the companion dossier, chapters 01–02.

Exercise 4.1 — take a Term-product purchase (a customer buys through GCash) and write the sequence of domain events it should generate, from quote to first premium. Then mark which events a regulator, a reinsurer, and a fraud team would each want to see. You've just designed an event schema — keep it for Lab M07.

Sources: standard insurance economics; Galileo dossier ch. 01–02 (data model, 31-day rule); US fraud figure (>$40 B/yr) per industry estimates cited in market research, as of 2025.