Parametric triggers
A parametric product defines payment by an agreed measurable event or index. That design can simplify parts of loss assessment, but pricing still needs a view of trigger probability, payout exposure, dependencies, expenses and capital. Historical claims are not the sole possible input; runtime records alone are not sufficient to establish a price. STABLE
Product-design questions
Section titled “Product-design questions”| Define | Why it matters |
|---|---|
| Event and eligible population | What is measured and what is excluded? |
| Threshold, period and payment | Exactly when and how much does the contract pay? |
| Measurement / verification | Who observes, signs, witnesses and checks the signal? |
| Outage, missingness and dispute rules | What happens when evidence fails or parties disagree? |
| Manipulation resistance | Can the operator manufacture or suppress the event? |
| Basis risk | Can payment occur without the intended loss, or loss without payment? |
| Authority and approval | Who owns wording, underwriting, pricing and claims? |
This is a design checklist, not an existing Glacis policy. STABLE
The draft Inference Re application proposed drift/scope-exceedance triggers over an attested window. Its threshold and period are historical proposal details, not settled contractual language. GROUNDED · Brochure
Drift, block rate and missing receipts can support investigation before they are validated for a payment condition. A blocked attack is not necessarily an insured loss, and changing detector sensitivity can alter the signal. STABLE
→ Claims-verified indemnity · Product design exercise
Drill this page →19 bank questions stand behind what you just read. Check it while it’s warm.