Open insurance has traditionally been an API-based digital transformation approach that exposes services and data that is consumable over secure, permitted channels. This facilitates enhanced revenue models, streamlines operations, and drives exceptional customer experiences. This innovation is also fueling the embedded insurance trend—another benefit of open insurance.
For example, consider an insurance firm that adopts open insurance to extend its capabilities. Its customers can receive quotes and secure insurance coverage for their shipments directly through their carriers using secure access over APIs. The legacy way would have been to call the insurer, fax or email documents, and receive quotes and coverage with latencies that cause breaks in what otherwise could be a seamless customer experience.
Under the hood, it is likely that the insurer has matured and transformed their technology landscape significantly to enable such real-time access over APIs. Indeed, by adopting an open insurance mindset, the development of internal applications and data storage is done in a way that facilitates these API based ecosystems. As a result, open insurance can be considered an important outcome (or driver) of digital transformation.
In this blog post, we will show how we can implement and enhance the promise of open insurance with smart contracts.
Specifically, we will show how the new approach using smart contracts can deliver these additional benefits:
- Simplify technology architectures and API management
- Bridge internal data islands
- Avoid multiple data stores that are necessary to be maintained by the partes at either end of the API
To illustrate the above, we will use a practical use case developed using smart contracts in Daml. We will also show how we can do all this without the need for a blockchain. In fact, the architecture will support using either blockchain or traditional data stores without sacrificing privacy. This is made possible by using the Canton interoperability protocol and is an important enabler of digital transformation..
Note: This complete and functioning use case has been developed using only 100 lines of Daml code described in the example below. It provides several architectural benefits, granular privacy, and tight access control straight out of the box. A little more detail around the data structures and this code can be ready for a pilot implementation to gather stakeholder feedback for a more comprehensive production implementation.
Our open insurance use case
Let’s consider that an enterprise customer is shipping cargo, for which insurance coverage is needed. The cargo carrier could either apply predefined insurance coverage or try to get customized coverage and premiums for the customer. The latter approach is indeed better because it allows the carrier to customize the insurance, thereby better managing risk. They can also offer lower latencies and a better experience to customers, thus enhancing the attractiveness of their services.
A traditional API based architecture may look like the below:
Apart from the obvious disadvantage of duplicating quotes, coverage, and pricing information in two different places, the insurance firm has the added complexity of maintaining a secure API management layer. The cargo carrier, on the other hand, has the overhead of integrating a secure customer portal and keeping it updated.
Here’s how the architecture using Daml will look. Some of the immediate benefits listed in the green boxes are:
- Golden source between parties (no duplicate data), but still fully private
- No separate API management layer to manage
- No fragmentation of business rules
- Increased compliance and security
The smart contracts-based API layer is part of the Daml platform, so it does not need to be maintained by either party. Daml also maintains the golden source while securing access to either party, thus eliminating the duplication of information.
As we touched on before, the API-based open innovation approach is supported by a significant level of digital transformation and application modernization programs. These programs can deliver much higher ROI if the data fabric and storage platforms can be streamlined and simplified as well. This data-driven innovation is strongly enabled by Daml, as we will demonstrate below.
Practical illustration of open insurance 2.0
A smart contracts-based language such as Daml is beneficial because of the dramatic improvements in productivity it delivers. Daml encapsulates significant complexity under the hood, thereby allowing developers to focus on the core business logic and the value it delivers.
Here’s our business process:
The first step is to create a platform that exposes the APIs to execute the various actions. We do that with a Daml smart contract that represents the ecosystem with two parties: The cargo carrier and the insurance carrier.
We start with an insurance carrier inviting the cargo carrier on to the ecosystem.
The signatory keyword represents a party that is accountable for what happens on this contract. You will see that the signatories also dynamically change based on the context of the smart contract.
In addition, the controller keyword represents the party that can take some action (has a right) on this contract. These also change depending on the context and the smart contract. In our case below, the insurance carrier takes the action of inviting the cargo carrier.
As you can see, Daml is incredibly easy to read. What you see is exactly what is happening. There are no complex object definitions, access control checks, or cryptography, as would be expected in a multi-party application. All of that is handled under the hood.
In the snippet below, the cargo carrier becomes the controller and accepts the invitation. Their role is created with both the cargo carrier and the insurance carrier as signatories. This illustrates an important property of Daml: Rights and obligations are managed at the smart contract level, and provide important privacy guarantees as well.
Daml’s privacy guarantees mean that even if there are multiple cargo carriers in the ecosystem, their roles are not visible to other cargo carriers. Any contracts they create are not visible to anyone else who is not listed on the contract.
For example, the CustomerCargo contract is only visible to the customer and to the cargo carrier themselves. This contract is not disclosed or visible to the insurance carrier too.
When the cargo carrier requests the quote from the insurance carrier, they pass along the cargo information to the insurance carrier. The insurance carrier can now respond to this contract and provide the quote. We list the customer as the controller who can accept this quote.
Note that only the customer is listed as the controller, so the cargo carrier can not accept the quote. This intrinsic capability of Daml to control the rights and obligations offers a multitude of benefits to developers, while eliminating the risk of compliance.
When the accepted quote comes back, the insurance carrier can then finalize the quote. Following this, the cargo carrier can finalize the cargo and specify the shipment details.
Note the use of the observer keyword in several of the keywords above. It implies that the contract is automatically disclosed to the parties listed against this keyword. That’s how we make the reporting of the process and the shipment available to the customer in real time. The developers never have to worry about running a SQL that can accidentally access incorrect customer data. This provides benefits for both compliance and security.
Flexible, multi-cloud physical deployment model
We discussed how we eliminated data silos and the API management complexity using Daml smart contracts, and there is one more critical requirement. For open insurance to be successful, every party should be able to select the cloud platform and technologies that are right for them.
Daml allows that through the Canton interoperability protocol. Each of the parties can use the infrastructure they need, because Canton operates across them under the hood.
That said, the cargo carrier in the example above does not need to be using Daml. They still receive the benefits of using the API and accessing the golden source of the data. And if they choose to, they could simply become an active party and streamline their technology infrastructure.
Conclusion
The time is right for insurers to adopt open insurance. The approach we outlined in this example leapfrogs the traditional, silo-based API ecosystem model by accelerating the harmonization of the platforms below. In other words, if APIs are the tip of the iceberg, the Daml-based approach to open insurance allows us to transform the rest of the iceberg as well.
