Categories
- 17.3K All Categories
- 9.5K Mining
- 574 Pool Discussion
- 378 Promotional
- 1.4K General Project Discussion (non-technical)
- 485 Education
- 811 Protocol and Client discussion
- 170 web3-js
- 29 Whisper
- 16 Swarm
- 3 RLP
- 303 IoT & Hardware
- 1.2K Smart Contracts and Dapps
- 28 Serpent
- 359 Solidity
- 664 Projects
- 1.2K Reference clients code and builds
- 249 Eth & AlethZero- Cpp Implementation
- 471 Geth - Go Implementation
- 242 Mist
- 15 Node.js Implementation
- 36 Python Implementation
- 49 Mix
- 36 Other Implementations
- 170 Meetups
- 40 Other Events
- 226 Jobs & Skills
- 281 Press and Articles
- 75 Audio/Video
- 296 Ether Sale
- 1.2K Other Languages
- 96 Chinese
- 255 German
- 33 Italian
- 111 French
- 3 Hebrew
- 42 Japanese
- 75 Portugese
- 46 Romanian
- 185 Russian
- 231 Spanish
- 47 Turkish
- 125 Watercooler
Ethereum Insurance Projects?
Hi, Is anyone thinking about/working on an insurance piece? Would be interested to chat about possibilities.
Best Answer
-
aatkin
Member Posts: 75 ✭✭
A paper I'd like to implement is the reputation system called TrustDavis which is implemented using essentially performance/insurance contracts. http://www.cs.ucdavis.edu/~defigued/index_files/trustdavis.pdf
Answers
As actuaries, our first intuition was to start off with a simple insurance product like a whole life insurance policy. The idea seemed simple enough but implementing it as a complete DACs was very challenging.
Still need to work on a few things, but it's finally coming together!
Operational risk is a hot topic with regulators these days. Your software is going to do wonders!
I like @kmhaps idea of doing it with a whole life insurance as a use case, since the underwriting process is fairly straight forward and the policy is binary.
If you don't mind explaining a bit how you guys went about it years ago and what challenges pushed you guys to cover digital data instead of more traditional insurance.
This is a topic I'm really interested in. The problem is of course how do you validate a claim. Arbitrators and game theory comes into play, but would require mass-adoption before becoming useful. Ideas welcome!
I would separate between entitlement, quantum and payment to start. Stated differently -- decide whether you are trying to validate someone's right to be paid, the amount of payment, or receipt of payment. Validation and quantum are probably harder -- but if you break into elements, they are easier to understand.
After you pick the top level issue, pick a type of cover -- first party (property)? third party (liability)?
If you're looking at entitlement (which I think may be the hardest), pick a type of policy. For this example, assume third party -- take a commercial general liability policy (or "public liability" policy as it's called outside of the US), and then pick an item to validate. If you have a policy with a time based entitlement feature -- say, notice in a claims made policy, that might be a place to start. Or if it's an occurrence policy, did the alleged damage "take place" or "occur" in the policy period. It's easy to establish the policy period (that's on the dec sheet) considerably harder to provide something "took place", particularly if you have a progressive loss implicating multiple policy periods. Still, even the most intractable disputes are solvable if you break into pieces.
Another way to approach this is in the context of settlement. Assume that the parties are engaged in dialogue and lawyers are involved. A problem my clients face all the time is that after providing documents or other requested items to support a claim we'll wait, wait and wait and either nothing happens or we're asked for more things -- payment never arrives. This is a little bit different than claim validation, but lives in the same system -- assume two parties agree to resolve a claim -- x tells y that x will pay if y provides z documents by a date. x provides the documents by z date -- if we can validate production of the requested documents, payment should issue automatically.
Stephen
This pool MAC could also select (vote) to invest a portion of the premiums and send moneys to another contract for that can yield a return, a return to the pool.
1. The data insurance standard title is a.k.a. — Cybersecurity Data Insurance (CDI).
2. The underwriting system and method is a.k.a. — CloudCover protocol.
Please allow 24hrs for me to arrive back to my place, and collect the thoughts, and express a few more reveals.
Thx, Stephen
Closed / Patented systems go against what ethereum's eco system is trying to achevie with the openness and decentralization. Unless contracts contents can be obscured / protected in the future then ethereum contracts may be forked as with any opensource application.
I understand how your experience and work relates, just not clear how you intend to work with ethereum.
As I read online: "Mr. Cardot is a primary inventor of the patent systems and methods to underwrite, bond and insure TCP/IP data, which in turn address the elemental loss control requirements to deliver truly cost effective cyber risk insurance. This fundamental risk transfer protocol represents a new category of insurance, as well as providing data governance and protection, collectively known as the CloudCover Protocol."
I believe a majority of us in this thread on interested in disrupting traditional insurance products/systems, not specific to TCP/IP Data and or cyber liability as with your CloudCover protocol seems to be doing.
Editorial comment, in line with yours: I'm deeply skeptical of any closed insurance platform or self-styled "proprietary" insurance product. Insurance needs transparency and simplicity. Companies should be judged on claims-handling practices and financial strength.
Even though we are discussing data insurance, I first should disclose some history how I (we) arrived here.
I come from an art background with a business and technical history.
You see, I got a glimpse of ARPANET while I was attending Illinois State University in the 70's. The University of Illinois shared course work with ISU, and I was later enrolled into an experimental course applying COBOL and FORTRAN in the micro-macro application attempting predictive economic modeling. Again, this was advance stuff in the 1970's.
That said, in the 1980's I further envisioned this idea of truly effective privacy and security of our digital information one day — our unique personal cyber essence would become "our digital virtual selves" within the future cyber information network — which later was named the Internet.
From 1980's onward, I (self) taught myself the information sciences, digital switching networks, etc. concerning the possible future web beginnings. Anything computer — digital retouching, digital printing, desktop design, I surrounded myself.
In early 90's I was one of the first to learn about the Web — and the http world. I later integrated online banking technology solutions for major banks as well as the first websites for Target, ITT, and fortune 500 clients. Everyone else were looking into making e-commerce applications (we also) — however, I saw privacy and security problems surrounding the entire TCP/IP security infrastructure. Encryption was not as good as is could be. We found gapping holes, backdoors in Y2K code when we (my associates) were brought in to rewrite the data systems for American Express. Security needed a serious overhaul but they didn't actually change the protocols much. Data was, as it is today — still very much at risk. I was unwilling to stick our (my) necks out and like chicken little, express that the sky is falling. There had to be better way. Industry does not appreciate innovation when you have to explain that their current security systems are faulty. Sort of throw out the old and start anew. No way, too expensive!
So data security patchwork proceeded. SSL (128, 256, 512, etc.) including newer firewall technologies therefore emerged. But, just like then as like now, this is not cutting it. The MITM (i.e. hacker) is very, very sophisticated, today. We knew in 2000, that SSL (PGP) could be broken in near real time — less than four seconds. Today, SHA1 can be compromised in near real-time. Other encryptions, have backdoors still to this day. If https data is at risk, who or what can we trust? What a mess!
So that being that, I decided to create a "group of free thinkers" and determined to consider what was the Internet missing to actually become a viable trustworthy delivery platform for communications. This is when we determined that data insurance was the possible answer… and data risk not yet understood. In historical terms, insurance has always been the last guys to show up to the "party of risk". They have always allowed the creative people to go first, then they show up and confiscate all the business opportunity.
First, foremost privacy and security is paramount. Security by way of technical prowess is potentially always hackable. This is where the technology world must work together with the risk transfer world. The cyber insurance underwriting has it wrong also. Things must change.
So, I patented TCP/IP data transmission insurance and underwriting data risk. R&D began 2001. Progress and setbacks ensued.
The years followed an outcome: CDI
Next: CDI status of today.
First thing, the basic takeaway below is that all of the R&D had to occur behind the curtain over the previous years, until it made sense to us, the (cyber) insurance industry, and alpha entities who's data was at risk, i.e. data breaches. As you know the daily media is awash in data breach this. Data surveillance that. We refer to these as "victims in the streets".
Second, I have always been a fan of opensource. CDI has a useful place in an opensource platform. Ethereum appears to be that possible platform. Let us see, how this plays out.
Now for CDI today — the status overview.
CloudCover represents a cyber-security insurance solution that underwrites and enables risk transfer (i.e. insurance) of data in-transit at the incremental packet level real time. We refer to this underwriting protocol as the CloudCover Protocol, which leads to the deployment of Cybersecurity Data Insurance.
As the CDI master policy (inclusion, exclusion) development moves from alpha development into beta testing, i.e. actuarial-feasibility metrics, we continue to refine CDI’s product description to address underwriting guidelines into unified risk system and method of instructions that enhance, and improve the effectiveness of the CDI Risk Formulation Index (CDI/RFI). This understanding can be used by risk managers to further understand CDI integration and practice for their customer’s (cloud) data services and thereby promote the cost-risk-benefits of insuring data in-flight, in real-time over any network.
Traditional technology is not sufficient to satisfy a firm’s contractual obligations to customer’s increasingly stringent governmental requirements or fiduciary obligations to customers, investors, and especially in cloud computing scenarios. The newer ‘cloud tech’ offerings are also not quite meeting the challenge. With the increase of imposed data security compliance to protect sensitive information, many companies are struggling to keep the cost and complexity of cyber-security protection under budget control. CDI addresses that reality, face on. This is known as being CDI smart.
Going far beyond simple deep packet (tag) inspection, CloudCover's CDI smart server scans multiple netflows, risk applications, data types and/or TCP protocols to incrementally identify network packet data. CDI shall make it practical to transfer risk and protect internal and/or external ingress/egress data attacks, as well as application vulnerabilities. Unlike other DPI scanning engines, the CDI/DPI method is not limited by IP traffic volume or TCP data type it scans, making CDI risk knowledge second to none.
The underlying CDI technology entails a risk scoring of egress (deep packet) data and therein classifies risks in real time associated with digital transactions or data transmissions, e.g. TCP/IP, NFC, etc. Such risks include data loss, theft and errors in the transmission, errors in the transaction, privacy violations, copyright infringement, digital piracy and a host of other digital perils. At present, many of these risks are not actually insured and are excluded from current cyber-insurance programs, presenting opportunity to solve this cyber underwriting dilemma.
CDI is process patented (PCT) twenty ways to Sunday…so that the insurance industry cannot (would not) trespass on the underwriting protocol nor its technical insuring system and method. Insurance has a history of mucking up the gears of innovation when comes to new insurance products. Information technology has major tendency to get buried in the weeds due to VC stupidness and greed, as well as management takeovers who do not understand the power of innovation or the agile application of a disruptive product.
Note: Cyber insurance today is simply "dartboard" underwriting with a D&O spin. It may explain the reason why there has not been a truly new form of insurance since 1987. Workers comp.
In a nutshell, CDI allows individuals, companies, telecom's and the cloud service enterprise to enjoy truly practical data insurance of their Internet traffic within their pipelines in real-time and deliver targeted cloud risk-less solutions with real-time monetization. By working at the application layer in real-time, CDI underwrites the hidden application vulnerabilities, anomalies and unknown threats that may be inadvertently letting attackers send data "in-and-out" through an unknown hidden port or method. CDI's cyber-security insurance can turn enterprise organizations networks into real-time 'risk smart' insured networks.
Next: CDI, very near future.
What I was speaking to, was that there has not been a new insurance method since. I received patents as a result of the unique nature of my data insuring system and method. This means, CDI is a completely new insurance system and method — incremental nano-risk transfer pointed at real time data transmissions. The CDI nano-policy opens and closes in 700ms (nano seconds) — i.e. nano insurance. Therefore, nano-premiums. Digital currency at the 100th of the penny was (is) part of the CDI's premium structure and payment processing. Ethereum could assist to manage (via opensource) the nano-premiums thru a bitcoin-esk or any other "CDI acceptable" digital coin payment method. Open for discussion on this topic.
CDI near future, 2014.
CloudCover shall also borrow the concept of decentralized consensus that makes bitcoin (crypto-currency, micropayment, etc.) so resilient, yet makes it so awkward to build an insurance system on top of the “lack of risk transfer” foundation. CDI appropriates an underlying risk premium (escrow) protocol for CDI’s incremental nano-premium architecture, and thereby applies proprietary underwriting and therein symbiotically underwrites the overall digital trust near real time.
Note: A majority of netflow risks are learned near real time — following the first twenty minutes of CDI (ip endpoint) crawling a network. The risk meta-data information is collected and sent back to CloudCover to underwrite “smarter” policies against future unknown threats (which are anomalous, yet become more knowable over time) thereby more risk predictable and classified accordingly. This continuous actuarial risk approach can dramatically reduce the number of threats that may penetrate an organization and greatly reduce the need for costly human remediation.
This verifiable, incremental insured transmission-transaction shall become the digital insurance standard based on being able to underwrite risk data at the packet level — whether it is a crypto-currency, encrypted or unencrypted transactions, micro-payments — any risky data traversing the Internet.
This is where I wish to begin to engage and exchange thoughts on the CDI protocol with ethereum group.
Next: 2015 and CDI expectations beyond.
@Stephan_Tual In the U.S. we could use the Social Security Administration's Death Master File. Insurance companies often scan this to identify policies that have not been reported as deceased. I think it's safe to assume that this will continue to be a resource, even after Ethereum goes live.
@giannidalerta You are correct. I think the only way to do this is as a Mutual company. This could also be a morale mitigation strategy if we move away from traditional insurance (e.g. may act as a deterrent from somebody crashing their car simply because they know they have insurance).
I think that it would be good to get some general principles for how peer to peer insurance works. I attempted to do this in a white paper on peer to peer insurance and I would like to hear others insights on how they would actually implement in Ethereum. You would have to solve several issues but to sum up the major ones I would say that they would be:
1. Sybil attack prevention
2. Fraud in relation to new policy creation
3. Fraud in relation to opening a claim
4. Fraud in relation to receiving a claim award and closing out a claim.
5. Compliance with existing laws and regulations.
My paper addresses all of these issues so it might be worth your time to check out. I've gotten some great feedback on the Sybil prevention mechanism that made my paper better and any feedback I get I greatly appreciate:
https://www.dropbox.com/s/tu7bsdati64d0h2/Peer to Peer Insurance white paper.pdf
~J
Soon Dynamis (www.dynamisapp.com) will be creating blog posts which will outline a real insurance product we are building to be released in early September. Our first attempt at insurance will be to implement unemployment insurance.
Joshua