4 ms·

AXA trialed a blockchain insurance product called fizzy. The concept was that you bought the insurance, and an oracle published flight information, and if your

AXA trialed a blockchain insurance product called fizzy. The concept was that you bought the insurance, and an oracle published flight information, and if your flight was delayed, the payout was automatic. They haven't continued with it, so it may have had problems, and I don't know if it required proof that you actually had a ticket (not doing so could create various problems), but actually I think the blockchain is a great option for this. The reason is that many people do not trust insurance companies. There is a feeling that they will find any excuse to avoid paying out. To have a blockchain solution where payout is according to a smart contract that is transparent and public is a way to build trust with your customers.

fabian2k 5y ago
After quickly looking this up, it looks like this automatically sent the money to a supplied credit card. There is no part here that actually needs a blockchain or smart contracts, it's just automated evaluation of the insurance claims. The "smart contract" can't force AXA to pay money to your credit card, so it's entirely superfluous here. You could implement the same thing witout a blockchain or a smart contract.
- kybernetikos 5y ago
  Sure - this product may not have ultimately worked, but the general concept is finding ways to make insurance payouts more transparent. That is actually a good idea given the severe deficit of trust in insurance companies that has been identified as one of the issues stopping people purchasing insurance.
  - black_puppydog 5y ago
    The point is not that the product didn't work. The point is that the use of blockchain technology had absolutely no (positive) impact on its viability or usefulness or reliability. Blockchains have very few very specific usecases, and nobody wants to admit that their usecase isn't one of them.
    - kybernetikos 5y ago
      Your point seems to be about this specific product. My point is about the idea of using a blockchain to increase transparency and verifiability of a process that makes payments. This is one of the 'very few, very specific' use cases that blockchains are good at.
      - theaeolist 5y ago
        You don't seem to understand what the previous poster said: all of this can be achieved with a database that allows some open access. You don't need a consensus protocol on a distributed system.
        kybernetikos 5y ago
        I'm absolutely aware that there are other possible solutions, although I doubt any of them are as practical as a smart contract blockchain solution. Given that you seem to think that it's not that hard, I wonder if we have a different understanding of the requirements here. We're trying to make the payment process more transparent and verifiable as a way of increasing trust. You say that we can do that with a database that allows some open access. I don't really see how. For example - who runs that database? If it's the company that offers the insurance, it's a nonstarter - it doesn't help with trust. If it's some third party, then it's precisely as useful as the trust the customer has in that third-party. Such an approach could work, but in my opinion brings with it more difficulties than a blockchain solution in most cases. Even if we do find someone trusted to run the 'database with some open access', there's still the question of being confident that payments are made according to the data in the database, and that the data in the database is updated according to the appropriate rules.
        newswasboring 5y ago
        > If it's the company that offers the insurance, it's a nonstarter - it doesn't help with trust. If it's some third party, then it's precisely as useful as the trust the customer has in that third-party. Don't oracles have the same issue?
  - fabian2k 5y ago
    Pretty much every insurance I care about cannot be resolved with an API call. And the problematic cases are the ones with enough ambiguity in facts or insurance conditions to make things messy, and those are pretty much impossible to automate.
lampe3 5y ago
they probably saw they don't need a slow and pricey blockchain for that. They could just get flight data from API's which already exists. For example in the EU all flight and all flight passenger data are stored in a DB. Just call that API check against it and pay out the cash. No need for a smart contract Cheaper, faster and as secure as any smart contract.
- kybernetikos 5y ago
  The thing that is interesting to me about this idea is that it is at the moment the only way that you can have a program make an automated payment and have that program verifiable by your customer. Your point seems to be that having an automated payment for this case is easy. Yes, it is, but if it's running in a datacenter somewhere on hardware you control, the user cannot inspect or ask someone else to inspect the program that controls that payment. They can't see when it changes. They cannot be sure that a published claim that the payment is automatic will really be held to, or even that a trade reviewer will get the same treatment as them so it doesn't help address the deficit of trust. A smart contract gives you another way of making a publicly verifiable claim about your payments process. It's an additional tool in building trust.
  - lampe3 5y ago
    If I don't trust AXA I don't make any contract with them. If nobody trust AXA they will go out of business. I don't understand that logic. Why do I need more trust? Why should I care about the inner workings? At the end I want the money on my bank account Everybody should have there own data center? Even my 80 year old grandma? In what strange world do you live in? It sounds to me like your living in a trustless world were everybody has access to a datacenter and fast internet... Your trust issues are the problem here and smart contracts are not solving them
    - kybernetikos 5y ago
      > If I don't trust AXA I don't make any contract with them. One of the huge challenges of the insurance industry at the moment is that while research shows that 60% of people think insurance is important, only 30% have a positive view of the industry. https://www.nsinsurance.com/analysis/the-geneva-association-survey/ https://www.nsinsurance.com/analysis/the-geneva-association-... This leads to people still buying insurance, but buying much less of it than they or the industry would like. So yes, this lack of trust is leading to bad outcomes for both the industry and the individuals, but the argument I worry you're making - that the industry exists and so therefore is fully trusted is not a valid one. I think you've misunderstood my data center point. The point is that if our hypothetical insurance company has a brilliant automated payment system, but it's running in a place that it cannot be verified, then there's little benefit to trust. A smart contract solution on the other hand can be public and verified (without your grandma running a datacenter). None of this requires fast internet or even datacenters. Trust issues absolutely are the problem here, and a deficit in trust is leading to bad outcomes. Smart contracts are a tool that can be used to help, because they act as a public, transparent, verifiable statement of what the payments process actually is.
littlestymaar 5y ago
> To have a blockchain solution where payout is according to a smart contract that is transparent and public is a way to build trust with your customers. How many of the said customers are even remotely capable of grokking the pile of Solidity which actually make the smart contract? Software engineer don't even review code for their npm packages these days, and you expect random people to audit their insurance smart contract?! Additionally, we all know how be company marketing work: after a bit of time their will be hundreds of different contracts, with completely different guaranties and undecipherable naming schemes which would make it really hard even for the most motivated solidity programmer to actually know what he's bought.

fabian2k 5y ago

After quickly looking this up, it looks like this automatically sent the money to a supplied credit card. There is no part here that actually needs a blockchain or smart contracts, it's just automated evaluation of the insurance claims. The "smart contract" can't force AXA to pay money to your credit card, so it's entirely superfluous here. You could implement the same thing witout a blockchain or a smart contract.

kybernetikos 5y ago
Sure - this product may not have ultimately worked, but the general concept is finding ways to make insurance payouts more transparent. That is actually a good idea given the severe deficit of trust in insurance companies that has been identified as one of the issues stopping people purchasing insurance.
- black_puppydog 5y ago
  The point is not that the product didn't work. The point is that the use of blockchain technology had absolutely no (positive) impact on its viability or usefulness or reliability. Blockchains have very few very specific usecases, and nobody wants to admit that their usecase isn't one of them.
  - kybernetikos 5y ago
    Your point seems to be about this specific product. My point is about the idea of using a blockchain to increase transparency and verifiability of a process that makes payments. This is one of the 'very few, very specific' use cases that blockchains are good at.
    - theaeolist 5y ago
      You don't seem to understand what the previous poster said: all of this can be achieved with a database that allows some open access. You don't need a consensus protocol on a distributed system.
      - kybernetikos 5y ago
        I'm absolutely aware that there are other possible solutions, although I doubt any of them are as practical as a smart contract blockchain solution. Given that you seem to think that it's not that hard, I wonder if we have a different understanding of the requirements here. We're trying to make the payment process more transparent and verifiable as a way of increasing trust. You say that we can do that with a database that allows some open access. I don't really see how. For example - who runs that database? If it's the company that offers the insurance, it's a nonstarter - it doesn't help with trust. If it's some third party, then it's precisely as useful as the trust the customer has in that third-party. Such an approach could work, but in my opinion brings with it more difficulties than a blockchain solution in most cases. Even if we do find someone trusted to run the 'database with some open access', there's still the question of being confident that payments are made according to the data in the database, and that the data in the database is updated according to the appropriate rules.
        newswasboring 5y ago
        > If it's the company that offers the insurance, it's a nonstarter - it doesn't help with trust. If it's some third party, then it's precisely as useful as the trust the customer has in that third-party. Don't oracles have the same issue?
- fabian2k 5y ago
  Pretty much every insurance I care about cannot be resolved with an API call. And the problematic cases are the ones with enough ambiguity in facts or insurance conditions to make things messy, and those are pretty much impossible to automate.

lampe3 5y ago

they probably saw they don't need a slow and pricey blockchain for that. They could just get flight data from API's which already exists. For example in the EU all flight and all flight passenger data are stored in a DB. Just call that API check against it and pay out the cash. No need for a smart contract Cheaper, faster and as secure as any smart contract.

kybernetikos 5y ago
The thing that is interesting to me about this idea is that it is at the moment the only way that you can have a program make an automated payment and have that program verifiable by your customer. Your point seems to be that having an automated payment for this case is easy. Yes, it is, but if it's running in a datacenter somewhere on hardware you control, the user cannot inspect or ask someone else to inspect the program that controls that payment. They can't see when it changes. They cannot be sure that a published claim that the payment is automatic will really be held to, or even that a trade reviewer will get the same treatment as them so it doesn't help address the deficit of trust. A smart contract gives you another way of making a publicly verifiable claim about your payments process. It's an additional tool in building trust.
- lampe3 5y ago
  If I don't trust AXA I don't make any contract with them. If nobody trust AXA they will go out of business. I don't understand that logic. Why do I need more trust? Why should I care about the inner workings? At the end I want the money on my bank account Everybody should have there own data center? Even my 80 year old grandma? In what strange world do you live in? It sounds to me like your living in a trustless world were everybody has access to a datacenter and fast internet... Your trust issues are the problem here and smart contracts are not solving them
  - kybernetikos 5y ago
    > If I don't trust AXA I don't make any contract with them. One of the huge challenges of the insurance industry at the moment is that while research shows that 60% of people think insurance is important, only 30% have a positive view of the industry. https://www.nsinsurance.com/analysis/the-geneva-association-survey/ https://www.nsinsurance.com/analysis/the-geneva-association-... This leads to people still buying insurance, but buying much less of it than they or the industry would like. So yes, this lack of trust is leading to bad outcomes for both the industry and the individuals, but the argument I worry you're making - that the industry exists and so therefore is fully trusted is not a valid one. I think you've misunderstood my data center point. The point is that if our hypothetical insurance company has a brilliant automated payment system, but it's running in a place that it cannot be verified, then there's little benefit to trust. A smart contract solution on the other hand can be public and verified (without your grandma running a datacenter). None of this requires fast internet or even datacenters. Trust issues absolutely are the problem here, and a deficit in trust is leading to bad outcomes. Smart contracts are a tool that can be used to help, because they act as a public, transparent, verifiable statement of what the payments process actually is.

littlestymaar 5y ago

> To have a blockchain solution where payout is according to a smart contract that is transparent and public is a way to build trust with your customers. How many of the said customers are even remotely capable of grokking the pile of Solidity which actually make the smart contract? Software engineer don't even review code for their npm packages these days, and you expect random people to audit their insurance smart contract?! Additionally, we all know how be company marketing work: after a bit of time their will be hundreds of different contracts, with completely different guaranties and undecipherable naming schemes which would make it really hard even for the most motivated solidity programmer to actually know what he's bought.