Please describe your proposed solution
SUMMARY
The goal of this project is to develop a working proof of concept (POC) for an automated parametric insurance solution integrated with the Cardano blockchain.
The POC will use real insurance policies from Howden Group. Charli3 Oracles will design and build a Parametric Insurance Data Verification System that leverages Charli3’s current oracle architecture.
Fida Finance will design and build a Risk Transfer Platform to a) automate the claims approval process, b) automate the payout process with payments made in ADA, c) enable mock customers to receive mock payouts for real policies.
The goal of this project is to showcase the technical capabilities of Cardano and present a working end-to-end solution for a real use-case (likely policies for Argentine Farmers in the wine region of Mendoza). Howden's blockchain division will present the POC to the broader Howden Group leadership team to convince them to move operations along with billions of dollars onto Cardano to launch the project output with live customers.
The output of this project will be a ready to go live with real customers POC optimized for a specific use-case and configured to support real policies.
Given the magnitude of this project, we’ve broken this solution section down into several parts to aid the reader in understanding the solution in relation to the context and problems it is meant to solve.
TABLE OF CONTENTS
S1 Context
- What is Parametric Insurance?
- Definition
- Traditional vs. Parametric
- Examples and use-cases
S2 The Problem
- What are the challenges with Parametric Insurance?
S3 The Solution
- Technical components:
- 1 Database of Policies
- 2 Parametric Insurance Data Collection System (PIDC) by Charli3 Oracles
- 3 Risk Transfer Platform by Fida Finance
S4 Project Output
- Final Project Output
- Demonstration of functionality using mock data
- System ready to go live with real use-case
- How does Cardano and enshrined Charli3 Oracle Networks solve those challenges of executing Parametric Insurance?
S5 Post-Project Paths
- Live Customers
- Coverage on-chain
- Fiat Ramps
- Definition of Success
S6 Closing Note
- The Benefits of smart contracts and Blockchain Oracles in Parametric Insurance
S1 CONTEXT
What is Parametric Insurance?
Parametric Insurance is an innovative new product offering in the insurance industry with the goal of eliminating multiple pain points of traditional insurance products. The execution of Parametric Insurance can be significantly improved by adopting smart contract functionality and the use of blockchain oracles for data verification. But, for those that are new to the insurance industry let’s take a moment to understand Parametric Insurance.
“Parametric Insurance is a non-traditional insurance product that involves specific trigger events that offer pre-specified payouts based upon a trigger event” (Read more about parametric insurance here: wikipedia).
Let’s discuss a few different use-cases to understand the difference between Parametric and traditional insurance using the above infographic. Parametric insurance is not specific to a particular area (e.g. natural disasters) it can apply to any specific event that can be determined by exact data.
For a travel example, if a flight is delayed with traditional insurance a policyholder would need to submit a claim and go through the lengthy process of getting it approved. With a parametric policy, the policyholder agrees to a specific trigger event (flight is delayed 2 hours or more) then they will receive $1,000. The idea is that when the departure time is known to be above 2 hours, a claim is automatically processed and payment is made directly to the policyholder.
For a climate risk example, an earthquake of magnitude 5.0 hits next to a policyholders house. Their house is demolished. In traditional insurance, the claim needs to be submitted, reviewed, damage to the house assessed, etc. The lengthy process causes significant delays in receiving payouts when the policyholder needs it most. A parametric insurance policy triggers a claim and payout when a magnitude 5 earthquake is recorded within the distance established in the policy. Moreover, the policyholder knows exactly how much payout they will get from the policy. There is no uncertainty and lengthy processes.
Parametric Insurance benefits both policy issuers and holders. By automating the process, it means policyholders do not have to submit claims and go back-and-forth with claims adjusters. On the other side, Insurance companies save money by reducing resources required in the claims process (such as customer support). Likewise, since the policies stipulated the exact payouts based on a trigger, both parties know exactly what to expect after a world event. This is much more transparent for both sides, whereas in traditional insurance products both parties have to wait for the claims process to truly know the outcome and payout. Parametric Insurance is a win-win product for both Insurance companies and policyholders.
Here are several other use-cases to learn more.
View Munich Re (Reinsurance Company) use-cases and examples
Travel Insurance
- If your flight from London to Vancouver is delayed by 4 hours, you get a payout of USD$250
ClimateRisk
- If an earthquake with magnitude 5.0 is located 2 miles from your home, then you get a payout of USD$500,000
Business Supply Chain Events
- If rainfall reaches 200mm over a 24 hour period, then you get a payout of USD$1M
S2 THE PROBLEM(s)
What are the challenges with Parametric Insurance?
Parametric Insurance is a powerful product that if executed properly benefits both insurance providers and policyholders. The automation, transparency, and speed of this non-traditional insurance product is a significant innovation. There are, however, challenges executing this type of insurance in a fully automated and transparent way. Let’s explore some of these challenges to understand how blockchain helps solve them.
- CHALLENGE 1: Multiple centralized parties are involved with bias and must conduct manual processes before a claim can actually be triggered.
- Parametric Insurance claims are sold and resold by multiple companies including a final reinsurance company to provide the coverage (money), each must agree that a real world event has occurred (parameter met) for triggering payout. Communication between these parties is manual and their processes for real world data validation can be distinct from each other and result in disagreements.
- Parametric Insurance products are sold to end-users (Policyholders) by Insurance brokers, these insurance brokers sell these products on behalf of Insurance companies (taking a commission), and those Insurance companies often sell these products on behalf of Reinsurance Brokers (such as Howden Group), and then ultimately Reinsurance Companies are the financial institutions that back the policies with money. See some examples below:
- Reinsurance: <https://www.reinsurancene.ws/top-50-reinsurance-groups/>
- Reinsurance Broker:
- Howden Group
- Insurance Company
- Aon
- Insurance Broker
- Marsh
- IMPACT: Manual processes cause delays
- Problem a: No consensus on data sources between parties
- The problem with multiple parties is that they each will verify whether a threshold parameter for paying out a Parametric Insurance policy (e.g. Earthquake magnitude and distance from location) accurately got triggered by real world events. So, each party will independently find a data source and validate the data.
- Problem b: Data validation is not automated and streamlined
- Instead of relying on a shared agreed upon data source and verification process that can be automated, each party has to complete their own process for a claim to be approved, adding significant delays.
- Problem c: Friction between parties during data validation process resolve with manual processes
- During each parties independent data validation, there can arise discrepancies between the data that require additional dispute resolutions to come to mutually agreed measurement of a real world value. For example, a reinsurance company may cherry-pick data sources that suggest the magnitude of an earthquake was 4.9 instead of 5.0 while an Insurance Agency has sources that show the earthquake at 5.0. Resolving disagreements is a manual process that negates the benefits of parametric insurance.
- CHALLENGE 2: Management of Parametric Insurance Policies have the potential to be much more transparent
- Parametric Insurance is already much more transparent from traditional insurance products by showing exactly what parameters need to be met for exact payouts. However, there are still ways to improve the transparency of these products when it comes to automating the execution of the real world data monitoring, validation of parameters, approval of claims process, and payout process.
- IMPACT: Increasing transparency increases adoption and security
- Problem d: Although policies have clear parameters for payout conditions and exact payout amounts, the execution of the claims process is still unclear to buyers/policyholders.
- Problem e: Policies are backed by coverage (money) that may not be available. There are notable examples in the industry where Reinsurance companies were bankrupt. (Read about an example here)
S3 THE SOLUTION
Please note that we dedicate the first milestone to reviewing the scope and project plan in this proposal after conducting research. The exact implementation during the project may deviate from the proposed description and scope here. We will follow the procedures and rules of Catalyst if making any significant changes.
Once again, our solution migrates the verification process onto blockchain oracle networks using Charli3’s core architecture and migrates the automated payout process by converting policies into smart contract logic integrated between oracle data input and payment output mechanisms. This latter part is designed by Fida Finance. Howden Group is responsible for directing design to fit their needs.
The solution has three main parts:
- Database of Policies
- Real World Data Verification System designed by Charli3 Oracles
- Risk Transfer Platform designed by Fida Finance
1 - Database of Policies
The first task for the team is to convert policies from their standard format (basic documents such as a car insurance policy) into configurations ready to determine the operations of both oracle networks and the Risk Transfer Platform.
Parametric Insurance Policy → Configuration file for blockchain oracle network setup
This is one of the few parts of the process that will remain manual at this time. A configuration file for a blockchain oracle determines parameters such as data sources, triggers for updating data on-chain (e.g. such as price deviation), regular heartbeat update intervals, number of nodes, and so on. For this project, Howden Group will direct our team in selecting optimal data sources for real policies and other parameters for the blockchain network. The total number of policies and data sources will be determined in milestone 1 where we will commit to delivering a working solution for a real use-case. At this time, it is likely we will be building a POC of policies for winemakers in the Mendoza Argentina wine region to protect against earthquakes and/or temperature anomalies such as late summers or early frost.
Parametric Insurance Policy → Smart Contract Logic for the Risk Transfer Platform
Likewise, the Fida Finance team needs to know the exact parameters and threshold values for triggering policy payouts. These will inform the creation of smart contracts and allow configuration of smart contract logic for each policy. Each policy will have a corresponding smart contract that triggers upon receiving data and causes an automated payout in ADA (or USDM or fiat if we can implement these solutions in time). Converting policies into smart contracts is likely a manual process for this project, but can be automated in the future to enable rapid scaling.
The project team will need to build a reliable back-end database solution to store this information, it will become the source of truth for both the Data Verification and the Risk Transfer Platform. In milestone 1, we will consider an entirely on-chain solution if feasible.
2 - Parametric Insurance Data Verification System
Second, Charli3 Oracles will design and build a Parametric Insurance Data Verification System (PID System) that is optimized specifically for this use-case and driven by Charli3’s enshrined blockchain oracle networks.
Charli3 Oracles is the first decentralized enshrined oracle solution on Cardano. The first live data feeds on mainnet launched in 2022. We specialize in delivering real world data onto the Cardano blockchain to be used as input in Decentralized Applications.
15,000+ hours of continuous Ecosystem uptime (100% uptime)
30,000+ successful updates on-chain
125,000+ successful node updates on-chain
4 distinct alert and monitoring systems to catch issues before they happen
Partially Open-Sourced
Want to understand how Charli3 works? Click here to view a short video
Configuration of Oracle Network
The policies will be converted into configurations that direct the function of an oracle network. An exact number of node operators will monitor exact data sources for exact data and events. Although we will have a database of configurations ready to launch networks to support a real use-case (e.g. Argentinian Wine policies), we will only be launching networks pulling mock data for milestones 2-3, then for testing purposes integrating the real world data sources in milestones 4-5. This will do two things: lower project costs and enable demonstrations of the system’s capabilities… or we would have to wait for an earthquake (or some other event) to occur before a demo could take place.
Data Monitoring
Once an oracle network is configured and deployed, the first function of the system will be to monitor data sources in real-time (e.g. every 2 minutes). Since Nodes running the Charli3 Node Software already monitor deviations for price pairs, we can adapt this monitoring tool for different policies. There may be customizations to the current Charli3 Oracle architecture to optimize for this use-case that we’ve accounted for in the milestones and budget. Positive responses from the monitoring solution trigger the second part of the solution: data verification.
Data Verification via Oracle Networks
After the monitoring service (run by node operators, automated, and built into the node software) identifies a parameter threshold being met, it then triggers the oracle network assigned to verify the real world event by querying the data sources, aggregating the results, and passing it along to an on-chain (second processing step) aggregation contract.
Charli3 Oracles has an already built and tested system to do all of this work. It just needs to be optimized for the data sources, parameters, and expected on-chain value for Parametric Insurance policies. The final on-chain is the culmination of all the independent external node operators verifying multiple data sources and the Charli3 aggregation contract removing any outliers and nefarious node activity. This on-chain data becomes input for the third part of the system, the Risk Transfer Platform.
The expectation is that a single Oracle Network will service multiple policies, but we will likely need to create many networks to scale the service. We will determine how to do this efficiently during the project architectural design phase.
What are the unknowns? What’s actually being delivered for the POC?
It is unclear how easily Charli3 can adapt its current architecture to support this use-case, so some design and restructuring is likely. It isn’t clear what data sources we will be using, so it is unclear if we will need to custom build integrations with sources for this proof of concept. Data sources may incur costs without live customers. Lastly, as noted before, we can’t force world events. For these reasons, we will prepare mock data sources in addition to preparing real world oracle feeds ready to go live with the end-to-end solution. In other words, we will create mock data sources with mock data (databases and endpoints) that will allow the team to test the system. At the end of this project, if Howden Group would like to launch a live customer POC, then the necessary oracle networks would already be deployed on testnet – requiring a push to mainnet.
3 - Risk Transfer Platform
The function of the Risk Transfer Platform is:
- to consume values from the PID System
- trigger the automated claims approval process
- trigger the automated payout system
- act as an UI/UX for customers to check statuses of claims
Leveraging Cardano’s smart contract functionality and Fida’s knowledge of converting policies into on-chain smart contracts, the Risk Transfer Platform is an end-to-end solution for automating Parametric Insurance. While significant challenges with the current way parametric insurance is executed by integrating with a blockchain oracle solution, the adoption of smart contract functionality on Cardano, to execute the approval and payout process, is essential to solving the challenges we address in the previous section.
Integration with PID System
For this project, Fida will drive the design of this platform by translating parametric insurance policies into smart contracts with specific logic. An integration between the PID System may also be necessary to identify what specific feed values trigger which particular policies. There are different ways that we can integrate the two parts of the solution and will research which is the best option during the design phase in milestone 1. There have been discussions of a bitmap on-chain, but more research is required to settle on the right solution here.
Risk Transfer Back-end and On-Chain Setup
The core function of the platform is to identify the right policies when a verified parameter is satisfied, then automate the claims approval and payout process. After receiving a triggering event from the PID system driven by Charli3 Oracles, the Risk Transfer back-end is a set of smart contracts that ensure that the specific policies triggered automatically lead to the right payouts. For this project POC, we will payout in ADA and likely on testnet to conserve funds. We will provide a report at the end of the project to describe the implementation of a live customer solution where payment may occur in fiat too (optional: if possible we may implement fiat or USDM for the project).
Risk Transfer Platform Operation
Once smart contracts are configured, then the process between the PID System and payout should be seamless and automatic. The Fida team will construct a payment mechanism that gets triggered by the policy smart contracts. For the MVP, this may simply be an ADA payment to a crypto wallet or, if possible, a USDM or fiat ramp to a bank account of a policyholder.
Risk Transfer UI/UX
In addition to automating Parametric Insurance, we will create a front-end. Prospective policy-holders can view policies and buy policies. While policy-holders can view and manage current policies. The exact design and functionality of the front-end will be determined in the design phase of the project. For example, if the front-end is supposed to be optimized for Argentine winemakers, then content ought to be written in Spanish. At the very least, the project will have a front-end that allows viewing and basic management of policies.
This is not a mock-up of the front-end, but gives an idea of the direction the project will be going.
S4 PROJECT OUTPUT
Here is a quick flowchart to illustrate everything described above.
PROJECT OUTPUT 1: Demos of System Functionality
- Demonstration using mock data of a single policy triggering automated payout on Cardano testnet
- Demonstration using mock data from multiple data sources triggering automated payout of multiple policies on Cardano testnet
The first demo for this project will output a single policy demo where a mock data source is monitored, triggers an oracle network verification event, and culminates with a verified and aggregated data value placed on-chain consumable by a single smart contract. That smart contract automatically executes the payment of a single policyholder.
The second demo for this project will output a multiple policy demo where multiple mock data sources are monitored, triggers multiple oracle network verification events, and triggers multiple policies to execute automated payment. This “scaling” demo will likely show a few scenarios. The point of the second set of demos is to show the system works under stress. We will create test cases and showcase the functionality of the system.
PROJECT OUTPUT 2: POC in “ready-to-go-live” state
- Fully deployed Cardano testnet solution with live oracle networks
- Demonstration of readiness to go live with real-use and customers
- Launch plan for deploying live service
Upon completion of the project, we can demonstrate an end-end solution on Cardano testnet that is missing only real customers and coverage.
What is project success?
The POC will deliver a PID System and Risk Transfer Platform designed by the requirements of the Howden Group with the intention to launch a live customer version after the success of the POC. This live customer version may include moving millions of dollars on the Cardano blockchain to payout policyholders. For the POC the payment solution will likely remain ADA, but if we can build a full USDM fiat ramp enabling customers to receive payments directly to their bank accounts that would be the best possible solution. As we develop this project, the Howden Group team will direct us to the best fit for their needs.
Success is creating a Cardano testnet end-to-end solution that works as expected, demonstrates the benefits of using Cardano and Charli3 Oracles, and convinces the leadership team at Howden Group to move forward with a live customer pilot program.
How does Cardano and enshrined Charli3 Oracle Networks solve those challenges of executing Parametric Insurance?
Although it is easy to see the automation benefits from adopting the Cardano blockchain, let's take a moment to address each problem identified and explain how this solution solves that specific challenge:
S5 Post-Project Paths
Without going into more detail in this proposal, we will share a few thoughts on where this implementation goes next:
- Live Customers: Let’s suppose we choose the Argentine winemakers use-case for the project. We will be ready to onboard new customers on the front-end shortly after project completion. Part of this project will involve getting users (e.g. farmers) to test our systems (milestones 4-5).
- Coverage on-chain: This point was already covered, but it can’t be understated that if the POC becomes a live customer platform liquidity must move on-chain in some way. We are already working with USDM and other banks to determine if a fiat ramp is possible even for this POC.
- Fiat Ramps: Placing coverage on-chain comes hand-in-hand with the potential to create fiat ramps.
- Definition of Success: An end-to-end working testnet deployed proof of concept that accurately triggers on real world events and payouts policies according to the parameters in them. A front-end interface for policyholders that is intuitive to use and friendly enough to onboard. Success is the Howden Group’s blockchain division having a working blockchain engine that drives their parametric insurance product and integrates seamlessly into a front-end such that customers hardly realize they are relying on blockchain technology.
- Requirements for a live customer pilot approval will become known as we work through this proof of concept. The Howden Group are the overall guides in this technical implementation and will ensure the project output addresses any of their concerns (regulatory, technical, or otherwise)
S6 Closing Note: The Benefits of smart contracts and Blockchain Oracles in Parametric Insurance
Blockchain Oracles, like Charli3, play a crucial role in automating parametric insurance by providing real-world data to smart contracts on the blockchain.
1. Real-Time Data Collection:
Oracles act as a bridge between blockchain-based smart contracts and external data sources. In parametric insurance, the triggering event (e.g., a natural disaster like a flood, drought, or earthquake) is defined by a parameter, such as the amount of rainfall, temperature, or wind speed. Oracles gather this data in real time from trusted sources (like meteorological databases, satellite imagery, or IoT devices).
Example: For flood insurance, the oracle might fetch rainfall data from a trusted weather station or a government database. Once a predetermined threshold (e.g., 200mm of rainfall in 24 hours) is crossed, the data is sent to the Risk Transfer Platform and the smart contract(s) that represent the policy.
Parametric insurance, unlike traditional insurance, triggers payouts based on predefined parameters or conditions rather than assessing the actual loss. This makes the claims process faster, more transparent, and efficient, especially with the integration of blockchain technology and oracles.
2. Triggering the Smart Contract:
Once the oracle confirms that the parameter has been met (such as an earthquake exceeding a certain magnitude or rainfall reaching a critical level), it sends this verified data to the Risk Transfer Platform on the Cardano blockchain. The smart contracts that represent the policy, pre-programmed with specific conditions for payout, automatically triggers based on this data.
Automation: Since the process is automated by the smart contract, the insurance claim can be processed without any manual intervention. The smart contract calculates the payout based on the parameter and instantly transfers the agreed-upon compensation to the insured party.
3. Transparency and Trust:
The use of oracles adds transparency to the process. All stakeholders—policyholders, insurers, and regulators—can access the same data used to trigger payouts, which is publicly recorded on the blockchain. This reduces disputes and the need for third-party verification, improving trust in the claims process.
Trustless System: Traditional insurance often requires claim adjusters to assess the damage, but with parametric insurance and oracles, the reliance on subjective assessment is reduced. Since oracles provide unbiased, real-world data directly to the blockchain, the process becomes more transparent and less prone to fraud.
4. Efficient Policy Payout Processing:
Because smart contracts execute automatically once the conditions are met, the entire process of claim settlement is expedited. Policyholders no longer need to file claims or wait for approval. This automation dramatically reduces the time and administrative costs for insurers and provides quicker relief to policyholders.
Cost Efficiency: By automating claims processing and reducing human involvement, insurers can cut down on operational costs, making parametric insurance more cost-effective.
5. Customizable Insurance Policies:
With oracles feeding different types of data, parametric insurance policies can be highly customizable. Businesses can choose specific parameters that matter most to them. For example, a farmer may opt for insurance against drought based on soil moisture data collected by IoT sensors, while a shipping company may insure its operations based on wind speeds or sea conditions provided by oracles.
---
Example of Blockchain Oracle in Action:
Imagine a parametric insurance policy for farmers to cover crop loss due to drought. A blockchain oracle is connected to weather stations and satellite data that measure rainfall. If a particular region experiences less than 50mm of rainfall over a 30-day period, the oracle would fetch this data and automatically trigger the smart contract policy within the Risk Transfer Platform to release the insurance payout to the farmer, without the need for traditional claims adjustment or verification.
Benefits of Combining Blockchain Oracles and the Risk Transfer Platform in Parametric Insurance:
1. Speed: Immediate data transfer and smart contract execution reduce payout time.
2. Accuracy: Oracles provide precise, real-time data, ensuring that payouts are based on factual, verified information.
3. Lower Costs: Automation decreases the need for manual labor and paperwork, reducing overhead for insurance and market providers
4. Fraud Reduction: With transparent data inputs, fraudulent claims are minimized.
5. Scalability: Oracles allow parametric insurance policies to cover a broad range of parameters and industries, from agriculture to travel.
By integrating blockchain oracles, parametric insurance can transform how claims are processed, providing a fast, transparent, and efficient alternative to traditional models.