Structure & Price Coverages

The coverage designer allows you to build and test parametric insurance products by configuring specific triggers, variables, and payout structures. This guide walks through the process of creating comprehensive coverage configurations.

1. Coverage Details

This section defines the basic parameters of your insurance product. A descriptive name (e.g., "Excess Rainfall 2024-25") helps identify the coverage. The section requires key actuarial inputs:

1. Expected Loss Ratio: The percentage of premiums the insurer expects to pay out as claims.
2. Minimum Risk Rate: The lowest risk rate at which an insurer is willing to cover the risk.

3. Sum Insured: The maximum total payout allowed under the coverage.

4. If set to 0 (default): The system auto-calculates the Sum Insured by adding the maximum payouts of all payout definitions.

5. If set to any other value: This value becomes a cap, and the total combined payout cannot exceed the entered Sum Insured.

Summary:

0 = Auto mode → Sum of all maximum payouts

Sum Insured > 0 = User cap → Total payout limited to the entered Sum Insured

The user also have the ability to edit the coverage(1)

2. Index Details

In the index details, users have the option to configure the coverage settings. This includes selecting:

• Input Variable - The measurable parameter used to define the insured event. In parametric insurance, this could be rainfall levels for drought insurance, wind speed for hurricane coverage, or ground shaking intensity for earthquake protection.
• Data provider - The organization supplying real-time or historical data for parametric insurance triggers. This could be meteorological agencies (e.g., NOAA, IMD), seismic monitoring institutions, or third-party data aggregators.
• Dataset - The specific collection of data used to determine insurance payouts. For example, satellite rainfall data, wind speed records, or earthquake magnitude readings.
• Output variable - The index value that determines the payout trigger. If the input variable (e.g., wind speed) exceeds a predefined threshold, the policyholder receives compensation based on the parametric model.
• Index Period - The timeframe over which the index is calculated and monitored. For instance, a hurricane insurance policy may use a 24-hour maximum wind speed index, while a drought policy could rely on cumulative rainfall over a season.

For a complete list of supported variables and datasets, please refer to the Data Sources section.

To define any index, first, we segregate them into individual variables. Broadly, variables can be classified into:

Input Variable

The raw meteorological variables, such as daily minimum temperature, daily precipitation, etc.

Output Variable

Defines how the input variable would be transformed to build the components of the index definition.

The output variables can be categorized into two distinct types:

• Numeric Variables: These retain the same units as their input counterparts. Examples include the upward deviation of temperature (measured in degrees) or the 3-day cumulative rainfall (measured in millimeters).
• Binary Variables: These simplify complex data into clear yes/no responses, measured as "days with condition." For instance, they can indicate the "number of days with temperature above 35°C" or "days with rainfall below 2mm."

Input variables can be sourced from multiple data providers, such as IMD, ECMWF, and others.

The user also have the feature to edit (1), duplicate (2) and delete the index(3).

3. Payout Details

The user can configure the payout structure based on the predefined index for the coverage. This includes:

Payout Name	Define a unique identifier for the payout structure.
Select Indexes	Choose the relevant index(s) that determine the payout.
Operator	Define the computation applied to raw data (e.g., average, max, sum).
Aggregator	Combine multiple data outputs or operators using logic (e.g., longest spell, count).
Comparator	Establish the condition for payout activation (e.g., greater than, less than).
Payout Type	Determines the payout mechanism (e.g., linear, lumpsum, linear+lumpsum).
Stack	A group of multiple payouts configured with stacking rules.

For each stack defined the user needs to input the following attributes:

Strike value	Set the threshold at which the payout is triggered.
Exit Value	Define the limit beyond which the payout calculation ceases.
Lumpsum Payout	Configure a fixed payout amount upon meeting the conditions.
Linear Payout	Configure a payout that increases proportionally based on how much the input exceeds the strike value.
Sum Insured	The maximum permissible payout amount.

The calculate button automatically calculated the maximum payout based on the provided inputs.

Payout Type

The platform supports three types of payout structures, each designed to accommodate different risk coverage and disbursement preferences:

• Lumpsum: This structure triggers a fixed, one-time payout once the defined strike value is met or exceeded. It requires the following inputs: Strike Value, Lumpsum Payout, and Sum Insured. There are no incremental payouts beyond the trigger point.

• Linear: This structure enables payouts that scale proportionally with the value exceeding the strike, up to a specified exit point. It does not include a one-time payout at the strike threshold. Required inputs include: Strike Value, Exit Value, Linear Payout Rate, and Sum Insured.

• Linear + Lumpsum: This hybrid model combines both a fixed and proportional payout. Upon exceeding the strike value, a one-time Lumpsum Payout is triggered. Beyond that, additional payouts are calculated linearly based on the defined payout rate, up to the exit value. Required inputs are: Strike Value, Exit Value, Lumpsum Payout, Linear Payout Rate, and Sum Insured.

Once created, a payout definition looks something like this:

Also the user have a feature to view the Payout Details in a Graph format(1)

Period Definitions

Each output variable operates within a defined time period. When combining multiple variables into a single payout structure, the system automatically determines the overall period by using the earliest start date across all included variables and the latest end date across all included variables.

A payout structure can consist of a series of triggers and amounts as well, where specific conditions lead to specific payments. Multiple payout definitions are required only in one scenario; in all other cases, indexes can be combined into a single payout definition:

1. Time Gaps in Payout Periods For instance:
   • First period: 01-Jan to 31-Jan
   • Gap in February
   • Second period: 01-Mar to 31-Mar

Aggregation Types

1. Daily Aggregation

The operator combines different output variables into a single daily index value. For example, it can combine upward and downward deviations from target values into one daily measurement.

The user can also setup "n-day cumulative" indexes by selecting this operator:

2. Yearly Aggregation

The aggregator determines how daily index values should be combined into annual results. The choice of aggregation method depends on the type of data and analysis goals.

Note - Sum over (n) days is also included in the Operator.

Sum Insured Calculation:

The tool calculates the Sum Insured based on the configured Linear Payout Rate, using one of two formulas depending on the payout direction:

Case 1: Index > Strike

Sum Insured = Lumpsum Payout + (Linear Payout Rate × (Exit –Strike))

Applicable when higher index values trigger higher payouts. Example: Total precipitation over the coverage period.

Case 2: Index < Strike

Sum Insured = Lumpsum Payout + (Linear Payout Rate × (Strike – Exit))

Applicable when lower index values trigger higher payouts. Example: Minimum temperature covers.

5. Monitoring Location

Any parametric coverage can be priced for multiple locations at once. There are multiple ways to do this:

• Csv Upload Upload a Csv file containing areas of interest(1). Ensure each geometry includes a "name", "latitude" and "longitude" property.
• Interactive Map Selection Select locations(2) using the provided map interface. Fine-tune coordinates manually in the configuration section.
• Download locations Select locations on the map can be downloaded(3) in a Csv format.

The user also have a option to select locations using the provided map interface. Fine-tune coordinates manually in the ADD LOCATION(3) section.

Note: each location must have a unique name.

6. Analytics Summary

Based on the steps completed earlier, the user now has the option to Go Back or Save their progress.

• Back discards any unsaved inputs and returns the user to the previous view.
• Save runs all required computations and saves the coverage on the platform.

As each component is successfully processed, status notifications appear (e.g., structure saved, index computations saved, risk reports saved). Once all steps complete, the user is automatically redirected to the Term Sheet view.

In addition, the interface provides Download and Upload buttons:

• Download exports the entire coverage configuration as a JSON file.
• Upload allows importing a JSON file to load a coverage configuration directly into the form.

The computation process is handled seamlessly in the background. Whenever the user adds or updates any input, the Compute button is temporarily disabled and replaced with a Computing… indicator. Indexes, payouts, and validations are recalculated in the backend until processing completes. When opening an existing coverage from the Term Sheets page, this automatic computing step also runs to refresh all analytics before the user interacts with the coverage.

Once all calculations finish and validations pass, the Compute option becomes available again, ensuring the user always works with accurate and up-to-date data.

After computing the coverage, the system displays key insights derived from the selected location, index, and payout configuration. Please continue on page Term-Sheet Analysis for analytics details and reports.

Best Practices for Coverage Design

1. Data Selection

   • Choose data sources with reliable historical records
   • Ensure the selected variable correlates with the risk being covered
   • Consider the granularity and frequency of data updates

2. Trigger Calibration

   • Set strike and exit points based on historical analysis
   • Balance between coverage effectiveness and premium affordability
   • Consider layering multiple triggers for complex risks

3. Testing and Validation

   • Run simulations against historical data
   • Test edge cases to ensure the design works as expected
   • Validate with subject matter experts before deployment

Next Steps

After designing your coverage:

• Analyze its performance using historical data
• Create a program based on your design
• Generate quotes for potential clients