A double design-science perspective of entrepreneurship – the example of smart contracts in the insurance market

Abstract

Purpose

Following the call for strengthening the third pillar of knowledge in entrepreneurship as well as work-applied management contexts constituted by pragmatic design principles, we present a case study on an insurtech for insurance firms specialized in smart contract insurance solutions such as flight delay or ski resort insurance.

Design/methodology/approach

Design science.

Findings

This not only serves as a pointer for how insurances may master their digital transformation while remaining competitive. But moreover, on the meta level, we find that the adoption of entrepreneurial design principles by the students, whose experiential project represents our case study, does not necessarily require continuous support or foundational knowledge to be delivered beforehand. However, for a deeper or more holistic assessment of the case sketched in their project, it makes sense to introduce them to newer developments such as the simple, practical framework of the Entrepreneur's Question Index.

Originality/value

Innovative teaching method on innovative topics.

Citation

Hoffmann, C.H. (2021), "A double design-science perspective of entrepreneurship – the example of smart contracts in the insurance market", Journal of Work-Applied Management, Vol. 13 No. 1, pp. 69-87. https://doi.org/10.1108/JWAM-08-2020-0037

1. Introduction

A field that has since long blurred the boundaries between work-based and academic learning is entrepreneurship. Following the call for papers for the “nexus” Special Issue, we propose that theoretical and practical knowledge of entrepreneurship ought to be complemented and mediated by a third body of knowledge that focuses explicitly on pragmatic design principles (Berglund et al., 2018). The current focus of journal publications in the field of entrepreneurship or management, more broadly speaking, is either on established theory with descriptive, explanatory and predictive power testing the (business) practice (e.g. by means of an experiment) or on the practice, propelled by knowledge of how to deal with specific problematic situations as they arise (Kieser and Leiner, 2009), generating theory. Berglund et al. (2018), indeed, pointed to the existence and importance of a third body of knowledge, namely, of pragmatically oriented entrepreneurial design principles that cannot be reduced to either theoretical groundwork or the situated expertise of practicing entrepreneurs (Dimov, 2010). To go beyond the commonplace of bridging the rigor-relevance gap by simply encouraging closer collaboration and more intimate involvement of practitioners in the research process (e.g. Shapiro et al., 2007; Starkey and Madan, 2001), the development and creation of pragmatic tools “in the service of action” (Romme, 2003, p. 562) should be embraced.

Even though the call for prescriptive procedural knowledge and a threefold epistemological focus, respectively, has been made, the interplay between theory, design and practice remains underdetermined. The goal of this paper is to explore the bidirectional relationship between practice and design further by putting the implementation of specific design principles for the attainment of desired outputs in specific contexts in the spotlight. Concretely, we will investigate the application of design principles in an educational setting where my (master’s) students in the course of a blockchain class were asked to develop, design, their own blockchain-based innovation or business idea and prototypes. Their project demonstrates a novel approach to using experiential, namely project-based learning to bridge the gap between settings in entrepreneurship theory and practice.

In the following, we present one outstanding student project as a case study in the realm of employing Ethereum-based smart contracts for insurance companies (Section 2). In Section 3, the business problem is restated as well as how blockchain can help address it. This is followed by an analysis of the current trends in the insurance industry and blockchain while also taking a closer look at already existing solutions. The students' business model is sketched in Section 4 where the Business Model Canvas tool (Osterwalder, 2013) was used to design it. The paper is concluded in Sections 5 and 6 where we, on the one hand, provide their self-assessment of their business model coupled with possible challenges that could occur when putting the proposed innovation into place (5.). On the other hand, we jump back to the meta level to derive lessons for the “practice – design” relationship in the new three-body space of entrepreneurship knowledge (6.).

2. The case study: some background information and methodology

Every semester, we weekly teach “Financial Technology” (fintech) on a weekly basis (Puschmann, 2017) at different universities. In the spring term 2020, we offered a course on the impact of blockchain on the business practice to master’s students in business, economics and computer science on behalf of an innovation lab hosted at a large university, a cross-disciplinary research program on the global phenomenon of innovation in the financial industry induced by fintech. This class gives an introduction to the topic and consists of two parts: theory – a misnomer in the binary worldview of theory and practice – including a mixture of scientific content and mainly practical contributions from guest speakers in different industries and lab, involving the design of a concept for a self-chosen blockchain solution. The theory part takes place during a weekly lecture, the lab part is part of a 2-days block event at a coworking space and fintech community-builder. The students present their developed concepts to a jury of specialists consisting of start-up entrepreneurs, venture capitalists and digitization experts of financial service providers and receive feedback. Students further have the opportunity to network with start-ups from both the local accelerator and incubation programs as well as the Crypto Valley train and via swissnex San Francisco, swissnex China, The Floor more internationally.

Like others before (e.g. Hyvärinen et al., 2017), this work follows design science research to guide the implementation of a blockchain-based business concept. In terms of design science, smart contracts in the insurance market is a typical “wicked problem” since (1) it may only be possible to find a solution to the business problem (see next section) that is “good enough”, rather than solving it completely; (2) the solution to the problem will be good-or-bad rather than true-or-false; (3) testing the solution is complicated and depends on several contributing actors; (4) the possibility to learn by trial-and-error is limited as every attempt at testing the solution is complicated and resource-intensive and (5) the problem does not have an exhaustively describable set of potential solutions or a set of well-described permissible operations. We, therefore, chose the ad hoc development approach by first learning more about the business problem in the next Section 3 and then designing a draft in Section 4, which we concurrently and conclusively evaluated (Section 5 and 6). Therefore, our design process follows the DSRM Process Model introduced by Peffers et al. (2007), see Figure 1.

In our case, the research entry point was context-initiated by my master’s course on blockchain at the university in the spring term of 2020. During the course of that class, we reviewed literature from various sources such as academic papers, industry leader reports and other publications (see Section 8) to construct a landscape of current digitalization trends in the insurance industry in general and specifically with regard to blockchain technology applications (see Section 3.3. to 3.5.). We researched the most pressing technical issues that need to be addressed to make sure our solutions could be applied in practice. We interviewed blockchain experts at Trust Square in Zurich and insurances directly to validate our approach. When formulating ideas, we focused on solutions that would leverage the existing financial institutions and structures, enhanced by blockchain technology, to provide more value to their clients. Next, different ideas were researched and tested in student groups who prepared a preliminary business plan for each one, finally narrowing down the number of solutions to just the one we pursue in this paper. We then conducted a market analysis and attempted to position our lending solution for maximum market penetration, the results of which are presented in the following.

3. Problem statement for the insurance sector and links to blockchain

3.1 Business problem

Together with the students the business problem was analyzed as follows: The insurance market today is characterized by intense competition and price-sensitive customers. Insurance companies therefore experience an increased price pressure and must try to prevail themselves in the market. In addition, the insurances are at risk of not being able to adapt quickly enough to digital change, making room for new market entries by tech and insurtech companies that offer customer-oriented products and well-designed user interfaces. In order to be profitable in the future, insurance companies therefore search for new revenue sources and ways to be more cost-effective. In the current state, especially claims processing in the insurance industry, is a resource-intensive task that leads to high costs for the insurances (Sehgal, 2017).

Besides extensive regulations and a long-term low interest rate environment, the insurance industry faces various challenges. On the one hand, there is intense competition in the industry itself, even called a “hyper-competition” by some researchers (Fritz, 1999). It is amplified by the increased transparency through comparison platforms, increased price sensitivity of customers and new market entries by insurtech companies (Müller-Peters, n.a.). In this hypercompetition, insurance companies have to gain short-term competitive advantages in order to maintain supremacy in the long term. These competitive advantages can be achieved in the following areas: price, quality, speed and innovation as well as by setting up entry barriers (Fritz, 1999).

3.2 Links to blockchain

The adoption of blockchain technology could become a possible solution to address these challenges that insurance companies face today. Blockchain technology is among the most trending technologies (Gartner, 2016) and argued to disrupt various intermediary services (Tapscott and Tapscott, 2016). It acquired fame as the technology underlying Bitcoin (Beck and Müller-Bloch, 2017) but is currently expanded to other areas of application (Wörner et al., 2016). In its generic form, blockchain technology refers to a fully distributed system for cryptographically capturing and storing a consistent, immutable, linear event log of transactions between networked actors (Risius and Spohrer, 2017). This is functionally similar to a distributed ledger that is consensually kept, updated and validated by the parties involved in all the transactions within a network. In such a network, blockchain technology enforces transparency and guarantees eventual, system-wide consensus on the validity of an entire history of transactions (Risius and Spohrer, 2017) [1]. Particularly, the application of smart contracts, generally a transaction protocol which automatically executes actions according to the terms of a contract, may give the insurances a valuable competitive advantage by enabling automation which can lead to time and cost savings in administrational tasks. Smart contracts can be implemented on the Ethereum blockchain and offer new possibilities to create innovative products for customers (Cohn et al., 2017). The automatization of the contracts could improve the overall efficiency in the industry. Even if transaction costs cannot be eliminated completely with blockchain technology, the potential cost savings become visible when looking at conducted studies. The result of one study found that for property and casualty insurance, management and contract administration were the largest driver of cost variance (Mussenbrock, 2017). Another study concluded that improvements in IT efforts could actually reduce costs in the insurance market by 20 to 40 percent (Münstermann et al., 2015). These cost savings could be passed on to the price-sensitive customer in the form of lower-premium policies and offer a competitive advantage for the respective insurance company.

Another desirable competitive advantage is quality. According to a recent study by Bain and Company (Kinder et al., 2019), Swiss policy-holders do particularly expect quality and simplicity from their insurance. For normal insurance products, claims adjusters are required to assess a claim and its validity. If the parties disagree on the interpretation of the terms, the information asymmetry usually leads to the fact that the customer is in a weaker negotiation position than the insurance company (Cohn et al., 2017). In such a case, the insurance product neither promotes simplicity nor quality for the customer. This is where a main advantage of the blockchain technology becomes visible. Even if not all insurance products are suitable for a blockchain application, those that are, promote the values of simplicity and quality. The customer precisely knows the circumstances in which the blockchain-based insurance product yields its payout since the circumstances for a payout are already defined in a tamper-proof code. The payout is being triggered automatically based on a trusted external data source delivered by an Oracle (see Appendix 1). Therefore, the insurance company will hold its value proposition to its customer in any case. This solves the problem of trust issues and information asymmetry. In addition, an insurance product for which the customer has no need of filing a report to receive compensation further amplifies the simplicity of the product. Finally, the offering of blockchain-based insurance products does not only have great marketing potential for the insurance company but also sets up new entry barriers. This is due to the fact that the creation of such insurance products requires new know-how, the right personnel, financial resources and the technological architecture.

3.3 Insurance market trends

The future insurance market will be characterized by a high level of innovation and by further intensified competition (Wiener and Theis, 2018). The high saturation of the Swiss insurance market makes further growth difficult for existing market participants. It will be necessary to make use of disruptive technologies such as digitalization, big data science or blockchain that could expand the value creation of the insurance companies. Furthermore, the use of these disruptive technologies could sustainably improve the efficiency of internal processes, thereby significantly reducing operating costs (Contri and Galaski, 2017). Experts believe that in the future cooperation with new tech companies as well as with competitors will become increasingly important in favor of ecosystems and clusters (Gackstatter et al., 2019), especially when considering that new insurtech startups or subsidiaries of technology companies could successfully enter the insurance market and further accelerate the digitalization of the industry. This development could lead to shifts in the market positioning of individual insurance companies and to an increase in new market entries and exits. In the future, it is well possible that traditional insurance companies will more often take the role of pure risk carriers when cooperating with technology companies. When focusing on customers, the insurance market will develop positively for them. Experts assume that there will continue to be a high diversity of providers and a wide range of insurance products (Wiener and Theis, 2018). In terms of blockchain, particularly, the hype is over and companies are done with experimenting (Dalton et al., 2020). The trend indicates that the question is no longer “will this technology work” but rather “how can we make this technology work for us”.

3.4 Blockchain-based insurtech solutions

3.4.1 Axa Fizzy flight insurance

Fizzy is an insurance product by AXA that insures flight delays on the Ethereum blockchain and was launched in 2017. All steps from claims assessment to payment are processed fully automated through smart contracts. The product therefore takes advantage of the benefits that smart contract insurances offer and which is covered in Appendix 1 (Hill and Knight, 2019). The basic idea of Fizzy is fairly simple [2].

The customer can enter his flight information online and select the desired damage coverage. The system then shows the premium of the chosen insurance, which can be paid directly by credit card. After the successful payment of the customer, the new insurance policy is created and written on the blockchain with the help of the smart contract. The smart contract then obtains flight data or flight delay data from publicly available databases via an oracle. The time of arrival is also processed onto the blockchain, and if the flight is delayed by more than 2 h, a payment is automatically made to the customer (Temperli, 2018). After two years, Fizzy was closed down by Axa since the platform struggled to reach commercial targets making it an unprofitable business for the company (Hill and Knight, 2019).

3.4.2 Etherisc - Ethereum based insurance platform

Etherisc aims to build a free, open-source, open-access platform for decentralized insurance. Their goal is that independent developers can create and offer their own smart contract–based insurance products on this platform. Etherisc wishes to tokenize the risk pool of these insurances and offer them as financial investment to the public. With their approach everyone could take the role of an insurance or reinsurance company. Overall, Etherisc could make the purchase and sale of an insurance more efficient (smart contracts), enable lower operational costs (lower personnel and management costs), provide greater transparency into the industry (blockchain technology) and democratize the access to reinsurance investments (tokenization of risk pool). For their business idea, briefly depicted in Figure 2, they received the Oscar of “the most innovative blockchain startup” at the Blockshow Europe 2017 (Etherisc, 2017).

3.5 Gap analysis of previous solutions

As illustrated by those two examples, there are already different approaches in the direction of smart contract applications for insurances. The presented solutions are on opposite ends of a spectrum though – Etherisc attempts to totally disrupt the insurance market by basically cutting out insurance companies and by working fully decentralized. On the other hand, Fizzy was developed by the insurance company Axa in-house, and the related smart contracts are not available for anyone else but Axa.

The business approach of Etherisc that enables everyone to build an insurance upon their platform involves certain issues. We believe that it will be difficult for Etherisc to establish a customer base in an environment where insurance customers still distrust blockchain (to some extent), especially if we consider that an insurance needs to be trustworthy. Without trust, people would never buy an insurance product (Millen and Wright, 2000). Secondly, an insurance company usually has a specific customer group which allows a better risk management. For example, a flight delay insurance could be offered only for flights starting in Zurich which leads to a risk reduction for a parametric insurance contract. On the Etherisc platform, this customer selection process is not possible. Thirdly, to create this platform, a whole new token ecosystem needs to be established. It will take a very long development time to balance this system and to make it tamper-proof and moral hazard–free. Etherisc is still in its infancy, and from our point of view, it will take years until they are fully functioning and have a sufficient customer base, if ever.

The in-house development of Fizzy also suffers from shortcomings. The main reason for the closure was that the financial targets could not be met by Fizzy. However, these targets may have been set too high in the first place, considering that within one year Fizzy already sold 11'000 contracts, making it one of the top users of the Ethereum network back in 2018 (Al Saqqaf and Mathur, 2018). In addition, Fizzy was one of the first blockchain insurances on the market. Potential customers were not yet aware of the advantages of blockchain insurances or the advantages were not communicated well enough. Axa lacked important cooperation with third party companies to find further sales channels for the product such as online travel agencies, airports and travel apps. Insufficient marketing could also have been a potential problem.

Thirdly, the payout structure was not optimal. It took up to seven days until a customer of Fizzy received a payment which is slow for a blockchain solution based on smart contracts. Fourthly, it is very costly to acquire the necessary knowledge to build the technological architecture without prior experience in blockchain technologies, not to speak of the inefficiencies that occur if every single insurance company tries to build up their own blockchain expertise. The investment in such a project poses a high risk for the firms and is only feasible for larger ones. This is an entry barrier for smaller insurances that otherwise would be interested in leveraging this new technology too.

Therefore, we believe that there is a place in the insurance market for a tech company that offers blockchain expertise and sets up the insurance products for existing insurance companies. The demand for such a service would be given by existing insurance companies that wish to make use of blockchain technology, without having to set up everything by themselves. Moreover, a third-party offering can leverage the brand name of existing companies to overcome the identified trust issue. Thus, the business model proposed in the following sections has great potential to position itself successfully in the insurance market.

4. Business model design

In this chapter, the design of the business model for a fictitious company “Smart-Insure” is presented and explained in detail using Osterwalder's Business Model Canvas. Building on our previous findings, we show how we would position our company in the insurance market, especially in contrast to the existing insurance solutions presented in chapter 3.4.

4.1 Business model canvas

“Smart-Insure” is an insure-tech company that specializes in the development of smart contract based insurance solutions on the Ethereum blockchain. The core idea is to set up a portfolio of different smart contracts which we can offer to our customers. On the one hand, our business model includes the sale of these preconfigurated blockchain-based insurance solutions to insurance companies. Then, we implement the blockchain technology without having to discard the current IT systems of the customer but complementing the architecture and making it available through several cloud services providers (Cohn et al., 2017). On the other hand, we take care of customizing the smart contract insurances to the customer's needs. Moreover, we offer predesigned user interfaces which we can implement on the insurers' website, creating the frontend for the end-customers that buy the insurance product. With these activities also comes a certain consulting service which we will also offer to the insurances.

We chose Ethereum as a platform since it is the largest (e.g. in terms of market capitalization) and best established blockchain today, that offers the implementation of smart contracts. We are aware of the fact that there is a scalability issue with Ethereum due to the usage of proof of work for consensus and limited block space. However, Ethereum, has already announced plans to adopt a different mechanism of proof of stake in the future (Sutherland, 2019). Therefore, we are justified to assume that scalability will not be an issue for our company. With that in mind, high on-chain transaction cost will not be further discussed. In the following, a detailed explanation of our business model is given with the help of a Business Model Canvas in Figure 3. Even though the Canvas is static, we think that it is a sound tool to develop and present a business idea.

4.1.1 Value proposition

The value proposition addresses the question of what value we will deliver to the customers. “Smart-Insure” has a multitude of different value propositions. Firstly, the use of smart contracts allows an automation of certain insurance contracts. Both policy issuance and claim handling will be executed automatically without the need of human interaction. This results in lower administrative expenditure for the insurance company. Furthermore, it increases the convenience for an insuree as he/she will no longer need to file any claim report and receive his/her money claims a lot faster than in a regular insurance environment. Secondly, the usage of blockchain technology offers high transaction security and data that have great auditability and are immutable. With the core fin-ech features like decentralized verification and privacy data-preserving in the shared ledger, the clients' information is stored in a secure and reliable way. The strict consensus mechanism further ensures the integrity and immutability of the data process procedure. Moreover, fraud risk exposure is a long-lasting problem the insurance industry faces. Smart contract-based insurances however are almost impossible to misuse with false claims. Thirdly, we provide insurances the opportunity to use blockchain technology without having to make a large investment compared to an in-house solution. This opens up the possibility for small and big insurance companies to profit from blockchain technology with a small investment and gain an advantage in the highly saturated insurance market. This goes hand in hand with a lower risk for a blockchain project and from our point of view great marketing potential for an insurance company. Finally, “Smart-Insure” will deliver support in the processing of the smart contracts and create new products for the insurance companies along the way.

4.1.2 Customer segments

“Smart-Insure” will target Swiss insurance companies as their primary customer group, constituting a strictly defined market. This allows us to tailor our smart contracts to a restricted market, which leads to a simpler risk management. We will focus on insurances that are interested in providing blockchain-based insurance solutions to their customers while requiring the expertise and developing skills from “Smart-Insure”. In the current business model, “Smart Insure” does not consider offering the insurance portfolio to individuals nor operating as an insurance company itself, at least initially.

4.1.3 Channels

In this section, we present the different channels through which we reach our customer segments. An insurance company that is interested in our service and insurance portfolio would first contact us through our off-chain website. All the needed information about what we do, how we do it and who we are will be found there. We use this channel to create awareness for our product and services. In case of a commissioning, the website of the insurance company is an additional channel. It acts as a gateway to process the customer information to the Ethereum blockchain. Finally, the Ethereum blockchain creates another channel where our smart contracts are deployed and interact with an oracle.

4.1.4 Customer relationship

This section is characterised by the question of what type of relationship each of our customer segments expects us to establish and maintain with them. We consider a co-creation approach throughout all activities as our main type of relationship. After the insurance company commissioned “Smart-Insure”, the first step is to select the desired insurance products from our product portfolio. The product portfolio provides different standard solutions, that are fully functional and which can be implemented on the backend of the insurance company's website. However, each product also offers room for customization. The customization could concern the risk assessment, at what margin the product should sell and how it should look like. These customizations will be handled by “smart-insure” in co-creation with the insurance. This also applies to the user interface on the insurance's website, which will be created and adjusted to the company's needs. This interface creates the user experience for which “Smart-Insure” is able to provide existing templates for the insurance company.

4.1.5 Key activities

Our core activity to provide our value propositions will be the development of a portfolio of different insurance products based on smart contracts which meet diverse customer needs. The possible insurance products of our portfolio will be covered in more detail in Section 4.2. Another key activity will be the implementation of the needed backend on the customer's website which allows policyholders to conclude an insurance contract. Furthermore, with the acquired knowledge of the portfolio development, we will be able to offer customized smart contracts to an insurance company and consult them regarding blockchain technology.

4.1.6 Key partners

Our key partners are oracles. As explained (see Appendix 1), Oracles will be needed to provide off-chain data to our smart contracts to a specific point in time. The availability of data is one of the main factors that could limit the application of smart contracts today. Therefore, we will work on establishing a good relationship with an oracle that can provide us with personally tailored information in a trustworthy way, as for example the provider Chainlink does.

4.1.7 Key resources

One of the key resources will be the data which an oracle can provide. Without, smart contracts would not be deployable. Particularly for a future portfolio this will be crucial. With more information provided in the future such as sensor data from intelligent cars or personal health information, the application possibilities of smart insurance contracts will be even greater. A second, more general key resource will be financial resources and an experienced development team. Thirdly, our reputation will be key. Our created insurance contracts need to be absolutely trustworthy and functioning. Otherwise, customers cannot be onboarded.

4.1.8 Cost structure

Our business approach involves high fix costs to develop a well thought-through product portfolio. Once we reach the point of having a good base portfolio, experienced developers and functioning contracts, we can leverage economies of scale and scope. The development of a first product will require many resources. However, additional insurance products can make use of economies of scope as they will have a similar structure, need similar expertise and a relationship to a trustworthy oracle. The economies of scale will occur with every additionally sold contract as we then can spread our fixed costs over a larger amount of goods. Furthermore, we have very low variable costs for our smart contracts. Cost positions like transaction costs (gas) on the Ethereum blockchain, oracle fees and payment fees can be passed on to our customers.

4.1.9 Revenue streams

Our business model involves four revenue streams. Firstly, we will deduct a usage fee for every concluded insurance contract. Secondly, as the implementation of a backend for the insurance website will be complex, we will receive a negotiation-based implementation fee. This fee should only cover our hourly working costs and is not meant to make any profit. This lowers the project costs of an insurance company and gives them an incentive to work with us. Thirdly, we will also offer fully customer-tailored smart contracts that are not present in our product portfolio. This will result in higher development costs as for a standard contract and therefore will need to be prized additionally. Fourthly, we can use our knowledge to consult insurance companies on their own blockchain projects. This would be a consultancy service. However, we do not see this as our core business, but rather as another way to generate income.

4.2 Insurance product portfolio

In this section, we sketch possible insurance products that are suitable for blockchain-based smart contract applications. The resulting product portfolio is divided into insurance products that are possible with the current state of the art and insurance products that might be realized in the future when blockchain will be more common. As this is our core asset, we wish to mention some examples although it has not been developed in practice.

4.2.1 Today's novel insurances

4.2.1.1 Index-based insurances

Index-based insurances are typically used in agriculture and linked to an index that measures local weather events such as humidity, temperature or rainfall (Adam-Kalfon et al., 2017). These weather parameters have a direct influence on a farmer's agricultural production. If an index exceeds a predefined threshold, farmers receive a payment to compensate them from possible harvest failure (IFAD, 2010). The payments are therefore determined by objective measures, such as the extent of a weather event (Cohn et al., 2017). The goal of such index-based insurances is to protect farmers against increasingly unpredictable weather and climate events which could affect their crop security, especially in developing countries (CCAFS, n.a.). The given “if-then” arrangement of such an insurance product shows that a blockchain-based smart contract is very suitable to execute an insurance claim efficiently.

The following example explains the concept of an index-based insurance which is executed with the help of a smart contract: A given index measures the number of days without rainfall in a given area where farmers grow crops. The farmers have signed an index-based insurance to protect themselves against drought, which could negatively affect their crops. The smart contract between the farmer and the insurer may stipulate that a payment is due after 30 days without rainfall (Adam-Kalfon et al., 2017). The exact thresholds and circumstances are predefined in the contract between the two parties (Jha et al., 2018). The index is fed by a reliable and trusted external data source such as rainfall statistics from national weather services and provided by oracles. The payment to the farmer is automatically triggered after 30 days of drought without the need for an on-site assessment or an insurance claim by the policyholder (Adam-Kalfon et al., 2017). Furthermore, the insurance claim remains immune to corruption, fraud, or human error (Jha et al., 2018). It is important to note that in case of a payment no property damage needs to occur as the triggering of the contract is only linked to weather data.

The application of a blockchain-based smart contract for index-based insurance holds two main advantages. On the one hand, farmers receive their payouts instantly and automatically based on objective measures. This makes the insurance product transparent in operation since all aspects of the system are on a public blockchain (Jha et al., 2018). Furthermore, the execution with a smart contract reduces frictional costs as well as management costs. Previously unprofitable policies could now become profitable and could be offered for a lower premium. This is especially important in developing countries. Parametric insurances that usually cover natural catastrophes such as tornadoes, hurricanes or tsunamis could also be handled by blockchain-based smart contracts (Cohn et al., 2017). Such an index-based insurance is a good example of our proclaimed economies of scale. If we are able to create a functioning index system, a well-coded contract and a reliable oracle to provide the data, such a contract can easily be adapted into a new product. A crop insurance could be converted to for example a “holiday weather insurance” with only a few adjustments. Imagine for example you book a three-week holiday, and you want to get an insurance in case it is only raining during your holidays. With this index-based insurance, we could offer such a contract. As we try to focus on the Swiss insurance market first, an insurance for ski resorts could be interesting as well. If there is less snow than usually, ski resorts need to invest a lot of money into producing artificial snow and have fewer customers. We could offer an index insurance for such a case based on snowfall data. This would give the ski resorts a certain financial security in case of insufficient snowfall or too high temperatures, not unlikely in the wake of climate change.

4.2.1.2 “Upfront-payment” insurances

Many insurance products require an assessment of the damage that determines the payout to the policyholder. For such insurances an application of blockchain is not possible since no oracle can assess the damage automatically. However, for such insurance products a combination with smart contracts is an ideal solution to provide further value with the product. One examples are life insurances as the basic insurance which are combined with a final expense policy based on a smart contract. The usual life insurance takes a long time until payout and is relying on the beneficiary to notify the insurance company. The final expense policy however can be constructed to rely on oracles which monitor specific sources of information about individual deaths. This way an up-front payment can be triggered to the beneficiary (e.g. a remaining relative) way faster to cover the immediate costs of the funeral (Cohn et al., 2017). This system of an up-front payment may also be applied to other insurance products. In France for example, such up-front payments are also made in case of traffic accidents involving two land-borne vehicles by member companies. Irrespective of the type of traffic accident and the nature or amount of damage, a trusted oracle such as the police could give the information about the involved vehicles. Based on this, the payment can be triggered, helping the policyholders to cover the immediate costs. At a later time, the insurance assesses how big the actual damage was and whose fault the accident was. In this case, the normal car insurance comes into play (Adam-Kalfon et al., 2017).

4.2.1.3 Flight delay insurance

This insurance was already covered in the previous sections (see 3.4.1.).

4.2.2 Portfolio in the future

The insurance contracts that could be offered in the future mainly depend on the information provided by oracles and their quality. Oracles are evolving rapidly, and we believe that more and more data will become available through the (mass) application of blockchain technology. At this point, we would just like to list a few ideas for the future. For example, car insurance is an interesting future product. As a second very attractive field, we would consider personal health data. Imagine a health insurance would give a payment back to the customer based on his or her own behavior. For example, for every ten gym visits the customer will get a CHF 5.- cashback. This offers great marketing potential and positively influences customer behavior. Furthermore, if Switzerland ever manages to record personal data in a trustworthy way like Estonia does, a wide range of new contracts could be made available.

5. Evaluation and outlook on the object level

We believe that our proposed business model has great potential. The first main hurdle we would need to overcome though is the development of a first working solution which can be offered to an insurance. The development of this solution requires a significant initial financial investment as well as a highly skilled and motivated development team. The second pain point is to find insurances that are willing to work together with a startup company and that take the risk of possible reputation damage in case of a malfunctioning contract. However, we believe that our products can be designed and deployed in a reliable way in the blockchain. Furthermore, our revenue is highly dependent on the number of concluded contracts. To become profitable, a long period of time is required. Yet, the revenue could be increased if we charge the insurance companies for the implementation of a product. This in turn could be a deterrent for some insurance companies to hire “Smart-Insure” in the first place. Other problems are the involved scalability issues that lead to high transaction costs on the Ethereum main net. For this business to become more lucrative, this issue needs to be tackled. However, we believe that right now would be a good time to start the development of such a project. Our research has shown that companies take blockchain more seriously nowadays and try to make their own applications work. By offering the blockchain solutions to existing insurances we believe we would close a profitable gap in the market. With this business model, we would be able to add value for the insurance companies, their clients and thus empower the application of the blockchain technology. In the long run, a company like Etherisc might be able to offer cheaper contracts as they would cut out insurance companies. However, as long as the customer is not fully trusting such a fully decentralized approach, our proposed business model will be superior at least in the more immediate future.

6. Evaluation and lessons on the meta level

The student group's work is interesting and insightful on many levels. Firstly, in terms of the subject matter itself, they developed a, at least prima facie, compelling case and a nice overview of the blockchain and insurance industries, which is both of value to scholars and practitioners in the field of fintech, entrepreneurship and beyond. Their analysis points to specific blockchain/smart contract adoptions as well as applications in different insurance contexts. Practitioners might find it worthwhile to elaborate on this prior work and spell out the case further. Scholars will conceive of the case study not only as a business plan or industry research (which might be enlightening but not fitting with the requirements of an academic journal), but view it more in a design-science perspective of entrepreneurship. This leads us, secondly, to an evaluation of the case study from a threefold epistemological focus, thereby acknowledging a third body of knowledge given by pragmatically oriented entrepreneurial design principles that cannot be reduced to theory (focus on rigor) or practice (focus on relevance).

In this light, we conclude that the adoption of entrepreneurial design principles by the students, in our case study embodied by the Business Model Canvas tool and expressed by the activities of building (the case, implementation efforts (Appendices 2 and 3) and evaluating (previous sections) (March and Smith, 1995), is sound. This is remarkable because the students were not taught about any entrepreneurial design principles or pragmatic tools in the service of action in class. The group did not necessarily require continuous support, accompanying judgment calls or foundational knowledge to be delivered beforehand. However, for a deeper or more holistic assessment of the case sketched in their project, it would have made sense to introduce them to newer developments such as the simple, practical framework of the Entrepreneur's Question Index (Kromer, 2019). Even though the students considered at least some weaknesses of the Canvas by referring to it as static, they were not making use of other tools to complement it and to avoid pitfalls.

With regard to the juxtaposition and role of skills and knowledge learned in a hands-on fashion during the project with that of academic learning (Bravenboer and Lester, 2016), we note, firstly, that the former does not replace the latter because the systematic teaching of the scope, limits etc. of a tool (such as the Business Model Canvas) and alternatives to it (such as the Entrepreneur's Question Index) would have rendered the student evaluation more sophisticated. Secondly, we also see, however, that in practice-oriented fields such as entrepreneurship, in general, or fintech, in particular, practical skills and knowledge are key, not just for the success of the project but also for the students in a bigger picture, i.e. network with possible employers, exposure to business expertise on latest technologies or starting points for building a venture after graduation.

Figures

Figure 1

The design science research process

Figure 2

Etherisc revenue model

Figure 3

The business model canvas for “smart-insure”

Figure A1

Commissioning of “Smart-Insure”

Figure A2

Conclude smart contract

Figure A3

Application of “addNewInsurance” function

Figure A4

Conclude smart contract

Notes

1. For context-specific key terms such as Ethereum and smart contracts, see Appendix 1.

2. Cf. https://www.axa.com/en/magazine/axa-goes-blockchain-with-fizzy.

Appendices

Appendix 1. Fintech-specific concepts and terms

1.1 Ethereum

Today, a lot of our data is stored on servers or clouds that are owned by big companies like Google. All corresponding transactions and data storage are managed centrally. This comes with a certain vulnerability. Firstly, the cloud company has potential insight into our personal data. Secondly, hackers or adversaries could try to gain access to our data without our knowledge by attacking this third party. Therefore, the manipulation, leakage and rightful ownership of the data can pose an issue. To overcome this problem, blockchain technology comes into play. The basic idea is that instead of using a centralized server, the information is stored in an encrypted and decentralized manner on so-called nodes.

Ethereum is a public blockchain that follows this approach. The concept of Ethereum was initially described by Vitalik Buterin in a white paper in 2013. The project was then launched in 2015 with the contribution of various people. Ethereum's goal is to become the first decentralized data exchange platform where everyone is able to create and run their own complex applications using smart contracts and distributed applications (DAPPs) (Buterin, 2013).

Similar to the bitcoin blockchain, Ethereum uses a coin called Ether (ETH) that is issued by the consensus protocol. Every transaction made on this blockchain costs a variable amount of “gas” that needs to be paid in ETH. Furthermore, Ethereum allows its users to issue their own cryptocurrencies (tokens). These tokens can be traded and used in different ways to ensure that working transaction protocols lie within DAPPS. The Ethereum blockchain is using its own Turing-complete programming language called Solidity, which allows the coding and deployment of smart contracts (Pauline and Corentin, 2019).

1.2 Smart contracts

In Ethereum, a smart contract is a contract between two or more parties that do not necessarily trust each other. When a certain encoded event happens, the contract will be executed automatically, without the need of a human middleman verifying the event or triggering the contract (Aung and Tantidham, 2017). Those contracts can be simple logical if-then statements or more complex contracts that interact with each other. Each transaction costs a certain amount of gas that needs to be paid in ETH. As an example, an insurer can design a contract according to which she promises to pay a compensation when a flight is delayed. When the condition that the flight is delayed is met, a predefined payout will be triggered automatically. The information needed to execute the smart contract is not available on the blockchain itself, but somewhere in the outside world. To translate this information to the blockchain, a so-called oracle is needed. An oracle is a third party that is able to provide real-world data in a trustworthy way to a smart contract. In the flight delay example, an oracle that can access the worldwide air traffic database would provide the information if a flight is late to the respective smart contract at a predefined time. If the flight is late, a payment transaction will be executed immediately and automatically to the policyholder. Smart contracts have the clear benefit of automating processes based on real-life data as well as high transparency due to the underlying blockchain technology (Pauline and Corentin, 2019).

A downside to the immutability of the on-chain data is that once a smart contract is issued it cannot be deleted anymore. Furthermore, the on-chain data might be perfectly auditable and immutable. However, if off-chain data is required the oracle can be a point of failure as the data usually comes from a public API. Therefore, it is crucial to evaluate where an oracle gets its information from. To overcome the issue of bringing centralized data into a decentralized network, a smart contract can use multiple oracles to verify the same data point (e.g. Chainlink).

Appendix 2. Student mock-up

In this appendix 2, we will explain how the commissioning of “Smart-Insure” looks like and how the process flow of a sample smart contract works.

As shown in Figure A1, we divided the commissioning into two parts - a customized solution and a standard solution.

In the standard solution, the insurance can choose from our existing product portfolio, and the smart contracts only get slightly adapted. The process of the standard solution begins with an official commissioning, followed by the implementation of the user interface and the required backend until the final “go live”-phase. In the customized solution, an additional development phase is needed to customize our service and products to the customer's needs. The customized solution is more labor-intensive and therefore comes at a higher price. In Figure A2, it is shown how a policyholder would conclude a contract offered by an insurance. The process flow is based on the example of a flight delay insurance product, which will be in reference to Axa one product in our portfolio.

The insurance will do its own individual marketing for the new smart contracts. Based on the raised awareness, a customer that is interested in the new insurance product can see the offered contracts on the respective insurance company's website. By bringing the insurance product to the customer through existing insurance companies, “Smart-Insure” benefits from many advantages such as the existing customer base, a good reputation as well as the built-up trust a customer has in the specific insurance company. In this example, the customer chooses the flight delay insurance and must first identify himself/herself. This is solved by a login or by a one-time registration as a new customer of the insurance company. The blockchain insurances will only be available for customers of the respective insurance company. Through that measure, we do not have to deal with anonymous individuals, which limits the possibilities to abuse our system. The customer can then enter his or her flight information, directly sees the price for the insurance and the possible payout in case of a delay of lets assume one hour. The product details such as the required delay for an insurance claim will always be specified with each insurance company individually. However, “Smart-Insure” will propose one applicable product solution to the insurance. After the customer agreed to the terms and conditions of the respective insurance, the insurance contract will be concluded with a payment by credit card. At this point, a payment in ETH would also be conceivable if the customer has an Ethereum wallet. The possible compensation payment would then also be made to the customer's wallet. While most of the paid money directly goes to the insurance company, a predefined percentage fee goes to “SmartInsure”. After the contract is concluded, the customer's flight information is automatically sent to the Ooracle. Besides, the smart contract creates the new policy with the respective flight information and an anonymous customer ID on the blockchain. More details about this kind of smart contract will follow below. After the plane is landed, the oracle sends the necessary delay information to the smart contract. The smart contract then processes this information and possibly triggers a direct payment in case of a sufficient delay or sends the information for an off-chain payment to the insurance. Furthermore, we would like to integrate the terms and conditions (T&C) of the respective insurance company into the smart contract. This allows the insurance to exclude payments that would violate their T&C. To keep that simple, we will ask a second oracle if the T&C of the respective insurance are met. Delays that occur because of a pandemic like COVID-19 could then be excluded. In our example of an off-chain payment, the insurance company will receive the information for payment by the smart contract which will be executed automatically. We wish to keep the payment off-chain as we believe that the majority of people today are not willing to have their own Ethereum wallet and prefer to receive “real” money.

Appendix 3. Technical architecture of flight delay smart contract

In this appendix 3, we explain which key functions the smart contract entails and which necessary information are written on the blockchain. We use excerpts from Fizzy's smart contract, which we analyzed as good as possible to provide a technical insight into the subject.

The smart contract by Fizzy comprises the following three main functions:

1. AddNewInsurance

2. UpdateFlightStatus

3. ManualInsuranceResolution

The “AddNewInsurance” function adds a new insurance policy to the Ethereum blockchain with the necessary information. The “UpdateFlightStatus” function is needed to update the insurance policy with the actual landing time of the plane, the data for this is provided by the trusted oracle.

The third function is “ManualInsuranceResolution” which is used if the contract was cancelled by the customer before flight departure. This function allows a manual stoppage of the smart contract if needed. The smart contract itself is therefore twice in use for every new policy. A first time when the policy is created with the “addNewinsurance”-function and the second time to update the arrival time at flight landing with the “updateFlightStatus”-function (Clement, 2018).

With the creation of a new policy, the “addNewInsurance” function is used to write the necessary information on the Ethereum blockchain in form of an Ethereum Transaction Hash (TXHash). In Figure A3, we can see five different TXHashes that contain different information when decoded (Etherscan, 2017).

After the TXHashes are decoded, they reveal the information as seen in Figure A4. The “flightId” identifies the specific flight a customer takes. In addition, the code also encompasses a time stamp of the corresponding time of departure of the respective flight. The information “limitArrivalTime” contains the threshold of time at which the customer will get the compensation. For Fizzy, the maximum delay was two hours; after that the customer received a compensation. The “premium” tells how much the customer paid for the insurance.

On the other hand, “indemnity” shows the compensation in euro that a customer receives if the flight lands with a delay of 2 h or more. Lastly the “productId” entails a randomly generated ID, used to identify the policy which allowed Fizzy to connect it to the corresponding customer in their local database.

After the flight landed, the smart contract is used the second time with the function “UpdateFlighStatus”. The function adds the actual landing time of the flight to the policy. As already mentioned, this information is delivered by an oracle. Further information such as the compliance with T&C could be delivered by an additional oracle and also added to the policy with this function. The time of arrival is then being compared with the value from “limitArrivalTime” which comprises the threshold of the delay. If the delay was larger than this threshold, an event is generated by the smart contract that informs the insurance company to trigger the compensation to the customer with the respective policy. This event is called “InsuranceUpdate”. It is entailed in the function “UpdateFlightStatus” and reports the final status of the policy to the insurance company (Clement, 2018).