# Blockchain and Smart Contracts for Insurance: Is the Technology Nature Enough?
## 3 Blockchain Applications in Insurance: Selected Use Cases
### Improvement of Customer Experience and Reduction of Operating Costs  
In this use case, blockchain and smart contracts could be exploited to increase the speed of claim processing as well as to reduce the costs (and mistakes) associated with the manual processing of claims. From this perspective, a smart contract could encode the rules for enabling the transfer of refund from the company to the insured.  
A simple application could consist of triggering an automatic transfer of refund only if the customer repairs the car at a certified mechanic, with the mechanic sending a transaction to the smart contract to prove its identity.  
More complex use cases could also involve oracles to gather information from the real world. To make an example, in crop insurance an oracle could periodically check weather data and push this information in the blockchain. A smart contract could then read these data, and trigger a payment in case of persistence of bad weather.  
These problems have been dealt with, for instance, in the prototype presented in [45]. In this case, the focus is on travel insurances, and the idea is to exploit a smart contract developed on the Ethereum blockchain for automatically refunding travelers if their flight/train was delayed.  
Another interesting use case, which could widely benefit from the increasing diffusion of sensors, is the exploitation of smart contracts in combination with IoT. For instance, homes could be equippedwith sensors that can directly notify a smart contract of a damage (e.g., damp sensors could be used to monitor damages on the roof) [46]. Similarly, smart appliances could automatically monitor their state, and initiate a claim or directly contact the repairer for a quicker assistance when needed.  
Solutions such as the ones envisioned above bring benefits to different actors: to the insurance company, which could reduce the amount of resources normally devoted to claim processing, but also to customers, who would receive money even before having become aware of the damage.  
Another advantage would come from the fact that everyone could inspect the smart contract. That is, the customer undersigning a policy would get a clear idea of its contractual conditions (even though, at the moment, he/she should master some programming skills in order to understand the smart contract code). Consequently, it would become easier for him/her to compare policies. Furthermore, the choice of a policy would no more based only on how much he/she trusts a given company (since trust would be implicitly guaranteed by the smart contract), but on objective data.  
Despite these advantages, it must be said that the scenario above could be adopted only for a limited number of policies. In fact, the majority of claims processed by insurance companies still need to be evaluated by an external expert before being settled. In case of manual processing, however, the customer experience could still be improved by managing payments in cryptocurrencies, whose transfer would be quicker than with traditional methods (several seconds or minutes depending on the blockchain used).  
From the architectural point of view, probably the most suitable choice is to adopt a combination of private and public blockchains. The private blockchain could be used to record policies and claims data, whereas the public blockchain could be used to trigger the refund in terms of tradable cryptocurrencies (such as Ethers or Bitcoins). The private blockchain could be maintained by trusted company's computers/nodes characterized by lower mining costs with regard to those of public blockchains. The public blockchain would be maintained by the wider public, through the mining incentives presented in Section 2. Alternatively, the company could decide to exploit only a public blockchain. This choice could be successful in case the company needs to improve its own reputation and obtain customers' trust (as the process would be fully decentralized), but would imply higher transaction costs.