2022-08-09 RRSC Agenda and Meeting notes
- Nathan Southern
August 2, 2022
When:
Tuesday, August 9, 2022
9am to 10am PDT/12:00PM-1PM EST
ZOOM Please Register in advance for this meeting:
https://zoom.us/meeting/register/tJwpcO2spjkpE9a1HXBeyBxz7TM_Dvo8Ne8j
Attendees:
Lori Dreaver Munn (Deactivated)
Brian Hoffman
Colton Schulz
Regina Daw
Lanaya Nelson
Kyle Bocci
David Reale
Jessica Meister
Birny Birnbaum
Andy Case
Aaron Brandenberg
Denise Matthews
Chris Aufenthie
Recording:
Agenda Items:
- Review of Technical Infrastructure –
- Network for North Dakota POC - Ken Sayers
- Review of Progress of the Working Group - Peter Antley
- Discuss POC for first Statistical Reporting
- Objectives and Key Results
- Stretch Goal
Adjourn
Meeting Minutes
I. Introduction
A. Mr. Southern began with a welcome to everyone physically present at the meeting and present remotely
B. Mr. Southern read the Linux Foundation Anti Trust Statement
II. Agenda Items
A. Ms. Westcott w/reminder that we want to use this time to go over POC that are in flow/in progress right now especially for those who aren't on weekly calls. Also what we're doing in ND, what we're learning from architecture there, and the background on the work going on in the various WGs. Central network and corresponding buy-ins and set up of notes is central to project and one of the most pronounced challenges handled by the idl team.
B. Mr. Sayers introduced self and position/responsibilities at AAIS and openIDL (system dev. etc.) - lead tech on idl project.
1. Discussion of activity in ND and what this reveals about architecture of system
a. Ms. Westcott: discussed how ND ins. Commissioner Godfread did requests for information and procurement proposals around using blockchain to examine unins. motorist #s in state of ND. About 20 states already pool this type of information for DOT. However, commissioner sought to do this through idl
w/corresp. blockchain technology. AAIS went through procurement process, and idl chosen for POC. Godfread has done a data call w/10 largest carriers in state to work with us as the vendor for the "data call" and each set up and have an openIDL node with populated VIN #. We need to show network can share information/insights, and ND DOT holds vehicle ID registry. POC is ltd to this - matching VIN to VIN. Prove the technology can work. Kickoff meeting a couple of weeks ago.
b. For ND commissioner: question of can this technology be used to help him find better ways to procure data for policy making.
c. Some small carriers but also includes some of the largest and most powerful carriers in ND.
d. Ran through an illustration of what this will look like on a grassroots level.
e. Concerns from group presented re: lag within the data (lack of timeliness, data uploaded into DMV 1x or 2x/month etc. Loopholes) in terms of how it is done traditionally. Attendees argued that this new approach will be more seamless and leave room for fewer loopholes. Qualifications in group: commissioner only wants to confirm that technology is successful. Has not given a clear indication of how he intends to use it. At this stage, primarily gathering clear and concise information for his legislature, down the road.
f. Mr. Birnbaum expressed a concern about VINs and cleaning VINs. Because what insurer and DMV has may not be flush.
2. Mr. Sayers discussed: How idl community is working on architecture, and complimentary efforts
a. Responded to concerns about timeliness/freshness of the data - this is not a technical issue. More a question of: -What kind of data are you feeding and -How often are you doing it?
b. To support notion of what DOI is looking to do - make it visible to show tech can support this kind of interaction between carriers and DOT - and not worry so much about the details. They picked this particular use case bc it's simple. Not intended to just do this. That's why some other options were not considered as the solution. This is more of a general purpose initiative, focusing for proof of concept on a very specific problem - unins. motorists. To get it to work, we have to set up a network. Generalized idl system must be tweaked to fit this particular use case.
c. We have set up a testnet to test the interaction and loading of vins and creating reports. This will test functionality.
d. We closed security issues uncovered with static and dynamic security testing, had kickoff in Bismarck. System is not ready for launch yet but will be soon. Vast progress with preparation.
e. Vis-a-vis stat reporting, the plumbing is 90% the same. This is generalized plumbing of using a blockchain network to make sure the interaction is captured, using specific architectural features of Hyperledger to make data movement private and ensure that carrier/DOI interaction is appropriate, and that data is moved in correct way through private channels. Idl supports general process of data calls. Unregistered auto POC is very specific narrow use case for this. Stat reporting - a repeat activity for idl data calls.
f. Next, meeting with individual carriers, setting up the network (pulled up a diagram to illustrate this), onboarding the carriers as their nodes get set up. Simple user guides will be issued, and AAIS will go through the guide with them, how to login, etc. Then testing with all the carriers. Then real POC calls, 1-3, Dec. '22, Jan-Feb. '23
3. Mr. Sayers pulled up schema of the network that we are targeting, and did a run through -
a. Network of nodes using HL and dist'd blockchain network as the communication mechanism
b. 3 types of nodes, each an indep. hosted set of software, separated from each other re: infrastructure.
c. Each carrier nodes supports 1 carrier, hosted in a unique account.
d. Account can potentially exist inside of a carrier's cloud - possible legal issues notwithstanding. AAIS is hosting accounts, has no access to them if carrier doesn't want that. for POC, setting up nodes with Chainyard, giving credentials and URLs to do the note. If carrier desires only then and Chainyard will have the ability to look at data on node.
e. Two nodes up top: AAIS node is a multitenant node. Can manage data from multiple carriers, also acts as main hub for DOI for AAIS to interact with system. Analytics node: where all of the reporting happens. When one puts data into node, a query is run against that which the carrier approves. Nothing leaves any node in any raw form, only shared with the analytics node through a private channel. Generally speaking only results of a query are shared. Most of the data returned by an extraction is pre-aggregated - all premiums by zip code or coverage e.g. HL fabric in middle gives user the opportunity as a carrier to approve disapprove of any attempt to access result data.
4. Mr. Sayers ran through detailed architecture of ND Uninsured motorists
a. 11 carrier nodes + multitenant node interacting through HL fabric
b. Most of work is done through blockchain which has full transparency - this is where data call is stored, data itself cannot be seen, however.
c. When extraction is executed, data is extracted from carrier nodes as a query and results of query go into a private blockchain channel that no other carriers can see; this in turn goes to analytics node on the right side, and a report is produced. W/ND architecture we're also loading reg. VIN from ND DOI Motor Vehicle Services Division
d. Question posed: does DMV have own node? Mr. Sayers: No, it is a possibility to set it up that way but we do not believe they need one for POC.
e. Question posed: why is carrier data going through their own personal channels and also through the blockchain default channel? Mr. Sayers: the default channel makes sure everyone sees data call/request itself. Plus carrier's like/consent/dislike. This is all that's on default channel. None of the actual insurance data is on this channel. Hyperledger permissioned network enables this. Channels make it possible to share data privately from one node to another. Data in carriers node is not shared, but extracted data is put into private channel on analytics node. None going into default channel.
f. Mr. Sayers: hash returned that no one can reverse into the actual secure data. Held in HDS, and comparisons done hash-to-hash. Double protection = hash + private channel. (Here Mr. Sayers clarified purpose of hash - fingerprint-like. May not be necessary but a little extra protection). Guarding more granular data. Another layer of security
g. But when it is received by the entity the entity can see? Mr. Sayers. Yes, because registered VINs and those actual #s will be on the report. Encryption code comes into play when it's inside encrypted structure.
h. Question: how are we getting at personal autos vs. commercial? Answer: we are telling them the data code they have to use is minimum bodily injury ($2550 ND), and saying any VIN # insured under - and using service identification code 19.0 - any policy that has 19.0 filed in this way and reported... if that policy has the VIN #, that's the VIN #... This is the first step. Later we subdivide the uninsured into personal and commercial.
5. Mr. Sayers pulled up a grid of the data we're seeking: Organization ID, VIN, State, Transaction Date, Transaction Month, and turned over to Mr. Antley. Noted that ND will only return: -VIN and -Whether or not it is insured.
C. Mr. Antley - Discussion of Data Format for ND
- When an organization submits data, they will have an organization ID, and submit in the form of a .csv, similar to an excel file. They give us organizational id inside carrier node, will be providing VIN, state, transaction date (as per this date we had reason to believe that this VIN had coverage etc. etc. etc.), and transaction month.
- We need requirements, then load in dataset, maintain a way to hash and salt data.
D. Mr. Sayers called for questions on the ND Project.
1. Question: can I just drop in a VIN and say "is this insured right now?" Mr. Sayers expressed his feeling that this is very much in reach following the POC. All depends on their ability to get a daily feed of VINs. Mr. Antley and Ms. Munn: current cadence is monthly, but if theyis were to become permanent, they could get it down to a daily level.
2. Ms. Westcott - stressed fact that AAIS doesn't ultimately want to own this. This is why they choice the Linux Foundation as a home for it. Really needs to be somewhere where the network has independence.
. 3. Question: is AAIS still planning to offer that multitenant node? Ms. Westcott yes - this still still be set up and maintained especially in light of the smaller companies who cannot do this on their own, such as smaller mutuals. Key to give them a way to participate, look at analytics, comply with cyber security, etc. AAIS sees this as its role. Keeping the market viable for companies like this. As we look to new committee about what does it mean to be an advisory organization, etc. Those are difficult decisions about adding value, etc.
4. Though from Colton Schultz in ND: Some of smallest companies do same process nightly submissions automated data feeds to reinsurer - good analogy to give to some of carriers - many are already doing some variation of the same process
E. Mr. Antley - brief discussion of data models that are being developed and used for personal auto.
III. Adjournment - Meeting Adjourned at 12:35pm EST/9:35am PSD