Date
This is a weekly series for The Regulatory Reporting Data Model Working Group. The RRDMWG is a collaborative group of insurers, regulators and other insurance industry innovators dedicated to the development of data models that will support regulatory reporting through an openIDL node. The data models to be developed will reflect a greater synchronization of data for insurer statistical and financial data and a consistent methodology that insurers and regulators can leverage to modernize the data reporting environment. The models developed will be reported to the Regulatory Reporting Steering Committee for approval for publication as an open-source data model.
openIDL Community is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://zoom.us/j/98908804279?pwd=Q1FGcFhUQk5RMEpkaVlFTWtXb09jQT09
Meeting ID: 989 0880 4279
Passcode: 740215
One tap mobile
+16699006833,,98908804279# US (San Jose)
+12532158782,,98908804279# US (Tacoma)
Dial by your location
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 929 205 6099 US (New York)
+1 301 715 8592 US (Washington DC)
+1 312 626 6799 US (Chicago)
888 788 0099 US Toll-free
877 853 5247 US Toll-free
Meeting ID: 989 0880 4279
Find your local number: https://zoom.us/u/aAqJFpt9B
Attendees
- Tahoe Blue
- Lori Dreaver Munn (Deactivated)
- Nathan Southern
- Peter Antley
- Greg Williams
- Eric Lowe
- Megan Ebling
- Dale Harris
- Kevin Petruzielo
- Brian Hoffman
- Chudwick, Susan R
- Reggie Scarpa
- Bourjaili Hi
- Jason Buchek
- Ken Sayers
- Ash Naik
- Nick Vitale
- Allen Thompson
- Truman Esmond (Deactivated)
- Kristin McDonald (Deactivated)
- Michael Payne
- Ryan Blakeney
Goals
Meeting Minutes
I. Introduction
A. Peter excited about work happening in other groups
B. For the time being we're going to cut down from the summer months for a one hour meeting of RRDMWG.
II. Agenda - Two items
A. Given the need for more of a voice from the regulators: what kind of clarities do they need to see? What kind of data? Frequency? Expectations re: next generation data platform.
- Mr. Lowe: difficult to comment to some degree as nodes will vary a bit among the carriers. On a row-by-row basis.
- How frequently will carriers update their rows? (Monthly? Weekly? Quarterly?) The expectation would be that queries are date-driven. For example: for today what is mix of auto insurance limits in Virginia? Does it vary by geographic area in the states? Can we aggregate by zip code? Zip code based experience data.
- If this information resides in every carrier node, the query can be run and will produce the needed results.
- If basic level data is in the nodes, we can do this.
- We want to be able to do comparisons through ad hoc queries
- Devil will be in details of architecture and our understanding of what row-level data will look like.
- Will we be putting raw data or coded data in? Coded may not allow us to break it down beyond stat data level
- One of things most DOIs are called to be: anecdote-busters. Getting beyond the testimonial level which is less concrete, sketchier.
- Almost anything could conceivably be done if aggregations are allowed.
- Vehicles can be broken down by model, year, etc. to run statistical queries. Aggregated information on which we can build trend and change data
11. Antley clarification: Do we foresee a need for looping? For doing a window function or cursor or looping? Preprocessing and then second transaction on process data? Mr. Lowe uncertain - probably out of scope.
12. Question raised re: dashboard. A lot of slicing and dicing is very ad hoc. Process in making an extraction is very complex. Goal: to simplify dashboard? Can we get to a place where we have a base data set for dashboard, where carrier provides same data every month? Or does it need to be aggregated before it leaves? Is there a process level difference to this? Current process with legal consent etc. is a bit stilted
a. Once data is in HDS, anticipation is that carriers will have - and not be bothered by - presence of anonymized access. Field level data that is acceptable in a queriable format as long as query cannot be narrowed so much that identity can be determined.
b. Can we can define queries that we do regularly and get clearance to do this? Yes. Publishing queries that we want against HDS instead of getting consent every single time.
c. Mr. Lowe agreed to this concept in principle. That is the goal. Doesn't have to be real time on day 1 - even quarterly would be preferable to what we have now.
d. Mr. Lowe pointed out that many regulators are not in business of data and data science. This level of regulation will not necess. emcompass every state. Pointed out NAIC data calls as a key example, with the caveat that their data is quite old (>3 years) before it is published.
e. Hard to give definitives and be pinned down on this. Won't know until he can see what we're looking at it.
f. Contributor pointed out that we can be aspirational based on desires and accomplishments in the past.
g. Mr. Lowe pointed out that what he's been able to do in the past has been somewhat limited, given lack of access to data on a granular level. This is intended to open those doors. He has put out a wish list for this.
13. Mr. Antley called for expectations and input from other regulators, in particular Ms. Crews.
14. Ms. Crews: not a regulator but work done at NAIC is focused on getting data more quickly so easy access to data is critical. Referenced Birny Birnbaum who has been promulgating this. Giving regulators easy access to pull what they need in lieu of individualized data calls for companies. Latter is too much work. Speed and trying to get more expeditious output.
15. Mr. Reale: careful about "speed" - relative term. Doesn't need to be speed of access, but lag time, how far back are we going? Age of data relative to today. So if query took an hour and it were recent data, this is ok, yes? (Mr. Lowe clarified: period of coverage we're looking at would be articulated in individual queries - we aren't talking about speed of processing. Speed - "Most recent data I can get.") "Age of Data" might be a better term.
16. Mr. Reale: wants to make explicit data versus use of data. Once data elements are approved are they approved for multiple uses? Travelers understanding is that uses are limited.
17. Mr. Lowe: concept of narrow use for innocuous data is a bit anathematic to him. "We can produce aggregations of data not separately exposed."
18. Mr. Hoffman: important for us to be all on same page.
19. Mr. Lowe: if there are elements 
that we can all agree would be readily avail. in HDS... But regulators also have to be reasonable about it. Beauty is that once data is in HDS we don't need to bring in programmers. This should take away from complaints he hears commonly from carriers about diverting resources. It should save money.
20. Mr. Braswell: one way to look at reuse concept: if data is rehashed by regulator and reviewed for other searches and queries, this is different than it being used in other capacities.
21. Mr. Hoffman: point taken but there are cautions to be taken about security and knowledge of where the data is.
22. Mr. Antley: data is typically geared for single use. To do multiple queries on HDS will be a major shift. Mr. Antley: data going into HDS should be sufficiently anonymous.
23. Mr. Lowe: asking for this per his authority as regulator knowing that carriers must agree to this. Question: how can we do this without giving away keys to competitive or behavioral kingdoms?
24. Mr. Hoffman: desire to look at particular company data is a different beast.
25. Mr. Lowe: not their intent to get any data used to create a market content prioritization tool and answer market behavioral questions. Will evaluate and provide statistical info about what carriers and regulators are doing, not what consumers are doing. Goal is to produce a tool that will make his job exponentially easier.
26. Mr. Reale: government process will always be slower than any technical implementation, si that fair? Mr. Lowe agreed. Mr. Reale: this will help as we are architect this. Needs to be accurate, resilient and acceptable enough to answer key questions. Mr. Lowe agreed
27. Mr. Lowe: architecture is build it and not let anybody in, but let everyone know what you've got in there.
28. Mr. Reale; are we formalizing any of this? Are we generating a user story or business case requirements out of this? Mr. Antley: will go through and make documentation from meeting. He plans to go through meeting on Monday and take outcome to AWG, will go through it with Mr. Williams. AWG is an iterative process.
29. Mr. Braswell: transcribing Mr. Lowe's use case is a narrative would be key. Document this as a starting point. Mr. Antley indicated that he will have this by 3pm on Monday. Mr. Lowe: 'majority document' (not consensus)
30. Mr. Lowe pointed out that the use cases for this are very similar to what is being done in North Dakota. Also brought it back to the staggering amount of money that this will save.
B. Looking ahead: Mr. Antley is looking at existing auto stat plan... will work on fields and corresponding definitions.
| View file | ||||
|---|---|---|---|---|
|
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
...