...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Date
12
Attendees
Allen Thompson
Joseph Nibert
Michael Payne
Hicham Bourjali
Patti Norton-Gatto
Lanaya Nelson
Brian Mills
Rambabu Adabala
Kelly Pratt
Kevin Petruzielo
View file name GMT20230510-150233_Recording_1920x1080.mp4 height 250
| name | GMT20230510-150233_Recording_1920x1080.mp4 |
|---|---|
| height | 250 |
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
Minutes
I. Introductory Comments - Welcome, LF Antitrust Statement - Peter Antley
II. Agenda - Peter Antley
A. Primary focus of meeting: review of current ASLOB (Annual Statement Line of Business) section
- Last week, the group discussed putting ASLOB line - positions 60-62 - in the stat plan. This has been done. Peter gauged everyone's thoughts on this and asked them to review accordingly and gauge its suitability as-is. (Does it need to be revised?)
- This needs to be defined - no fault liability is 191, other liability is 192, physical damage is 211, an elaboration of the listed ASLOB codes. Move ASLOB column over to left, and definition of what those Aslob codes mean will be placed on the right. On the lefthand side, the decimal points need to be removed. (PA did this in-meeting)
- Question raised about making it "19,1 no fault liability," e.g., putting the number before the description, on the right; Peter agreed. No objections from group
- It was clarified that 19.3-4 shouldn't be added because they are commercial and this is a personal stat plan, and 212 is commercial physical damage, so this shouldn't be added.
- Private passenger added to definition -
- Sentence - "Convert the ASLOB code by multiplying the value by 10 to remove the decimal" - removed from document
B. SDMA Replacement OLGA (openIDL Loading Graphical Application - used to load HDS) - Peter working on architecture diagrams for this and meeting with AWG on it. Needs clarity around in-line editing. Highly GT2-styled application - runs rules, lets user see errors on the page and do in-line editing.
- First type of in-line editing has been figured out. Invalid zip code - one update on one row.
- Wrt bulk updates - when more than one update is done at a time, what kind of business use cases make this a requirement and when are said bulk updates done?
- It would apply when a large number of records for instance are missing a specific damage coverage code - and the answer is the same in many fields (perhaps all of them)
- The number could potentially be anything - probably not more than 10,000 however. Typically smaller amounts but not necess. as small as 5-25.
- There could be more than one column at a time that need to be updated in bulk along these lines. This has occurred in the past.
- General updates on this process: most of the functionality for the pages (olga) worked out, now the focus per Peter's team has shifted to what will happen on the back end of the database layer. Next week, Peter will do a high level presentation on how they will organize the application and what kind of functionality they might need, etc.
- Wrt bulk updates - when more than one update is done at a time, what kind of business use cases make this a requirement and when are said bulk updates done?
- Extraction Pattern and current status of that - Peter is meeting with stakeholders following this meeting. It should be resolved this month and will be given first priority
- Other implementation work- Mason has been working with the stat plans from homeowners, dwelling properties and mobile homeowners to do residential properties, and the team has done multiple reference tables to load these into the HDS. They've also hired a new intern to speed up this work.
C. Discussion about where the group wants to go. Now that they have the stat plan, needs to figure out the rating basis code etc. Stat plan is mostly open sourced and ready to go. OLGA isn't finished; until it is, and the workflow is figured out, Peter can't include first chapter about how to upload data. Peter's team will get OLGA built; they will be able to load test data into HDS; they will have the extraction pattern; they will create the auto covg report with openIDL. This is the implementation prep. Does the group want to start talking about homeowners, or talk about day 2 stat plan with auto or wait until it gets further with OLGA?
- Slowing down the pace advocated - meeting every other week until auto and property are done
- Then the next step might be Day 2 for auto and property
- From a stat reporting prospective important to avoid multiple processes
- Peter's implementation team will be working to ingest all stat data across all lines using stat plans as they exist today
- Ultimately decided to take next week off and pick up in two weeks - and then to do biweekly at the same day/time for the time being. Nathan indicated that he will modify calendar as needed - next meeting will be on 5/24.
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|