A user shopping for auto insurance seeks direct insurance quotes, quickly, without dealing with an insurance salesperson. Additionally, this user wants to avoid the wave of solicitation that follows any insurance quote query.
Solution:
A downloadable app (from a neutral web repository) that a user runs locally against data entered into their auto-insurance section of their Solid POD. Taking this approach, it is not necessary for an insurance company to receive a user’s information unless that user is ready to complete the purchase. This safeguards the user’s data and prevents the user from being the target of solicitation.
This will also provide highly competitive prices, since there is no middleman, requires no advertising or click-through fees, and should reduce the cost of completing the final purchase.
Our team offers to build the ontology if others build this app.
My team believes that this approach demonstrates a unique value proposition for Solid users. Let’s work together and build this app.
Hi @JKReynolds
first I need some precision
I’m french and I need to understand what is for you an “auto-insurance” :
is it a “car insurance” or a “self insurance” ?
next, the if the user’s data is on his POD, where are insurence companies data ? in the app? in a POD dedicated to collect/provide insurance company’s data ?
I think the “Solid” way to do that is that each company update his own POD with their data, but we must convince them to share that, I think that’s the harder step, don’t you ?
I apologize for any confusion, it is “car insurance.”
These are certainly a few ways that this could be approached. I can’t say what would really be best.
Yes. I suppose in retrospect it might be necessary for an application like this to be built by the insurance company itself. However, there are certainly third party sites that currently do auto insurance quoting for several companies. I’m admittedly unsure of what their arrangement is.
This idea is quite ambitious, and rightfully so as it would revolutionize the quote system of all types of insurance companies (health, car, home) and companies would truly compete to give you the best price and service.
Basically in your model, the consumer enters all the PII information only once, and the insurers would get to peek into your data.
What do insurance companies need to underwrite a policy? In your case, gender, age, number of traffic accidents, number of moving violations, what else?
Since once the companies get to peek into your data, they’re free to use it in which ever way and the consumer has no way of controlling, unless regulators intervene, but then again, what’s the point of decentralization if there’s a regulator/centralizer in the middle, so. Why not offuscate the PII? Why not hash the driving history and guarantee its integrity using the blockchain? Why not force the insurers to run their underwriting algorithms (and lookup data) in some controlled environment (perhaps a serverless environment that can be provisioned at the moment of the query, and then trashed after it’s done) and thus they don’t get to have your data at all, unless the consumer decides to do business with them.
The possibilities are endless… Ping me if you want to talk.
This is not actually what we’re proposing. My team was thinking something more like this:
A user could download the application that contains whatever algorithms and information necessary to calculate the insurance cost and then run their information against this to produce a quote. In this scenario, the insurance company itself is never given a peek at the user’s PII.
I do agree that there are a lot of alternative ways to pursue this though. Especially this bit:
Which I think is very much in the spirit of what we had in mind.
to test, load the robots3.xls file and take a look at the console (output: rdf and without WebWorker (for local test)).
Prepare the xls file as follows:
column name starting with “!” -> infos are not taken into account
column name starting with “O_” -> ObjectProperty -> a link to another URI
column name starting with “D_” -> DataTypeProperty -> a link to text (== “Literal”)
The rest -> Subject of the triplet -> implies that there is only one column with nothing in front: all the others must start with “!” or “O_” or “D_”. possibility of having several columns with the same name -> the subject will have two links of the same type.
