BLK 05Domain · 🟢 everyone · ≈5 h · 7 lessons + exercise

Where chain meets cover

Six insurance use cases, one honest framework to judge them, and the discipline to kill the ones that don't clear the bar. Featuring the audit-ledger pattern that actually shipped — in the platform this course uses as its case study.

LO3 · state where a ledger adds value vs a databaseLO5 · design a parametric product

L1The value framework — three questions before any chain

Ask, in order: (1) Do multiple organisations need to write to shared state? (2) Is there a trust or reconciliation gap between them that a single operator can't (or shouldn't) fill? (3) Are the rules automatable — decidable from data the parties accept? Only "yes, yes, yes" earns a ledger.

high trust gap ↑ low trust gap ↓ one writer many writers → Reinsurance settlement · subrogationmany companies, chronic reconciliation — strongest fit Parametric retail · fraud registry · KYC poolstrong fit with governance work Audit ledger (Galileo pattern)one writer, but regulator/auditor trust gap — defensible Internal CRUD "on blockchain"one writer, no trust gap — use a database Data sharing among friendly affiliatesshared DB / API usually wins — chain optional
Fig 5.1 Placement quadrant. Bottom-left is where doomed projects are born; top-right is where the survivors live.

L2Use case 1 · Parametric insurance (the star)

Parametric cover pays a pre-agreed amount when a measurable index crosses a threshold — wind speed ≥ 200 km/h within 50 km, rainfall < 100 mm in a season, flight delayed ≥ 3 h — no loss adjustment at all.

1 · Buy coverpremium in, terms fixed:index · threshold · payout 2 · Eventtyphoon passes ·flight delayed 3 · Oracle reads indexofficial source(s), aggregated,signed on-chain 4 · Automatic payoutcontract pays in minutes —no claim form exists Why insurers love it: near-zero claims cost, zero claims fraud surface, instant customer experience, reaches the uninsurable (smallholder farmers — Lemonade's Kenya cover; Etherisc's 10k+ policies). The catch — BASIS RISK: the index can miss real loss (your roof gone, wind measured at 195 km/h ⇒ no payout) or pay without loss. Product design = minimising and disclosing this gap honestly. Regulatory note: several jurisdictions require insurable interest / loss linkage — pure index payouts can drift toward "derivative" classification. Involve compliance at design time.
Fig 5.2 The parametric sequence. The oracle (M02) replaces the entire claims department — and inherits its integrity requirements.

L3Use case 2 · Fraud & shared registries

Insurance fraud exceeds $40 B/yr in the US alone (industry estimates, non-health P&C). A big slice is cross-insurer: the same car crash claimed at three carriers, the same policy double-financed. Individually invisible; jointly obvious.

L4Use case 3 · KYC & identity reuse

Every insurer re-verifies the same customer the bank verified last month. Consortium KYC lets institution A attest "verified to standard X on date D" — an attestation reusable by B with consent, cutting onboarding cost and friction. Add decentralised identifiers (DIDs) and verifiable credentials and the customer can carry the attestation. Galileo's ecosystem already routes KYC via Onfido; an attestation layer would sit exactly there. Hard part (always): liability when a reused KYC turns out wrong — a legal-ring question, not a technical one.

L5Use case 4 · Subrogation netting — the quiet success

State Farm ↔ USAA (production Dec 2020)

shipped

Auto insurers constantly owe each other subrogation recoveries: A pays its customer, then recovers from B (the at-fault side's insurer). Between two giants that's thousands of cheques and demand letters monthly — in both directions.

The build: a shared permissioned ledger records each demand and payment; instead of settling claim-by-claim, the net balance settles periodically in one payment. Forbes reported the 2019 pilot showing a "stark increase in efficiency"; full automation was reached in December 2020.

The lesson: tightly-scoped, two-party, high-volume, low-drama reconciliation — no token, no press-cycle economics — is exactly the profile that survives contact with production.

L6Use case 5 · Reinsurance placement & settlement

The strongest structural fit (M04 L5) — treaty terms, cessions, and cat-event settlements shared by insurer, broker, and a tower of reinsurers. B3i shipped a live Cat XoL placement product on Corda… and still died in 2022 when funding collapsed. Both facts matter: the workflow fit is real (RiskStream continues the work), and the consortium economics are the actual boss fight. Full autopsy in M08.

L7Use case 6 · The audit ledger — Galileo, the shipped case study

◐ Case file · a production audit-ledger core

Pattern: every write command (create policy, update party, record payment) goes to a private blockchain first; Kafka streams accepted ledger entries to workers that update MongoDB read models; current vs archive collections preserve every version. The chain is the book-keeper; the database is a disposable projection.

What it buys: regulator-grade tamper evidence, total ordering of business events, rebuildable state, and decades-long record retention by construction (M04 L6). What it costs: infrastructure (3 chain nodes + 12 workers), eventual consistency between write and read, and scarce expertise — costs that contributed to the replatforming decision.

Honest framing: with one operator, a signed append-only log (or QLDB-style ledger database) could deliver much of this. The blockchain form pays off if third parties — auditors, regulators, partners — ever get verification access. That upgrade path is the capstone's opening question.

L8Anti-patterns — how to kill a use case in one meeting

Anti-patternSmellThe question that kills it
Blockchain-as-databaseOne writer, internal data, no external verifier"Who, outside us, ever checks this ledger?"
Tech-first consortiumPlatform chosen before the business case; members join for optics"Who pays the run costs in year 4?" (see B3i, we.trade)
Oracle hand-wavingParametric deck with no data-governance slide"Who runs the nodes, and what happens when sources disagree mid-typhoon?"
PII on-chainCustomer records "immutably stored""Show me the erasure-request procedure."
Token where none is neededA utility token bolted onto a B2B workflow"Does removing the token break anything except the pitch?"

Exercise 5.1 · Score six, kill three

framework practice

Run each candidate through the three framework questions and Fig 5.1. Defend your kills in one sentence each — then compare with our verdicts (flip below).

  1. Typhoon parametric for GCash users
  2. Internal policy-document archive "on blockchain"
  3. Five-insurer motor fraud registry
  4. Blockchain loyalty points for agents
  5. Insurer↔reinsurer treaty cession ledger
  6. "NFT policies" for a single carrier's retail app
Our verdicts

Keep: 1 (multi-party trust via oracle + instant payout is the product), 3 (competitors, shared writes, privacy via hashes), 5 (chronic multi-party reconciliation). Kill: 2 (one writer, no external verifier — use WORM storage/signed logs), 4 (a database with marketing), 6 (single carrier ⇒ the NFT adds transfer complexity nobody asked for — unless cover portability between platforms is truly the product).

Sources: State Farm newsroom & Forbes (2019–20); Etherisc/Lemonade figures as cited in M08; US fraud estimate per industry bodies (as of 2025); Galileo dossier for the case file.