Page Comparison

Date

29 Apr 2022

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

• Dale Harris

• Libby Crews
• Greg Williams
• Ken Sayers
• Matt Hinds-Aldrich
• Nathan Southern
• Peter Antley
• Megan Ebling

• Eric Lowe

• Chudwick, Susan R
• George Bradner
• Kristin McDonald (Deactivated)
• Melissa Pereira
• Sandra Darby
• David Reale
• James Madison
• Bourjali Hi
• Reggie Scarpa
• Nick Vitale
• Tahoe Blue
• Ryan Blakeney
• Lori Dreaver Munn (Deactivated)
• Sean Bohan
• Allen Thompson

Goals

Meeting Minutes

I. Intro

 -Peter Antley opened meeting @1:03pm EST and read anti-trust notice, shared agenda on screen. 

-Called for introductions no responses.

II. Update 

-AWG met on Monday - discussed validation and hashing strategies and what it means to make a report. A1 discussion. 

-Tues. AM discussion more of a tech focused group. working with stat plan. Discussions about how to normalize data we have, and big discussion this Tues. is comparing/contrasting different modeling approaches for Data Warehouse. Dimensional vs. data vault. Tues. @ 9am. 

III. Dissatisfaction about subdivision or working groups

-Clarification of roles of working groups - concern internally about overlapping/duplication of functions. Travelers feels we need to stay away from non-data modeling discussions at rrdmwg. Feels it's becoming a burden to discuss tech everywhere, can we go back to siloing efforts/focuses?

-How do we effectively sub divide work? Can Fri.  stick with more of a business view of the data, and architectural focused on what database we use? Internal dissatisfaction about this.

-Jeff or Sean link between business and technology.

-Concern as well that we're making no headway on what the fields should be.

-Right now as well we should be focused on what our business needs are on Fridays.

-Tuesday morning calls wg should be focused on the shape of the model of the data

-Jeff Braswell best Linux contact as ED to bridge tech and business.

-AAIS not interested in cancelling or suspending Tuesday meanings. That is a non option.

-Travelers suggested they pull in another data modeling person.

-AWG needs a better format.

-Travelers feels neither business nor technical requirements for the HDS have been clarified yet.

-LF believes we are close to defining technical requirements, Travelers vehemently disagrees.

-A clearer roadmap is needed, technically. And dramatically improved communication.

-Basic architecture of IDL and HL not fully understood. Needs to be redefined, what we want at the end of the day. Unclear about what HDS does.

-Peter finally suggested picking up conversation at AWG - how to make awg more effective etc.

IV. Discussion at AWG Monday

-Hashing conundrum. Take time to talk about what we need to do to make a valid report.

-Hash requirements, report validations etc. Some are unclear on what hashing is specifically.

-How do we satisfy regulators with functional operations of network itself? They are unsatisfied.

-Currently all of carriers submit data to us, we do reconciliation and submit reports to regulators.

-Moving forward carriers will have their own nodes, extraction requests come from regulators, carriers fulfill requests. 

-Edit checks and data quality controls are necessary. Every stat agent has an edit package to make sure data is reasonable.

-Reporting has to be balanced against financials. Annual statement line and state, total, not individual records.

-Immutability concerns (valid) different than edit checks. This is a circular argument. Do we have to prove that data hasn't changed? Open question.

-Travelers: clarified - data may change over time. If someone pulls it at a later point, it may have been modified. Especially as statements get updated and numbers change. Who is tracking this and how? What are the mechanisms?

-Do we need to keep a series of time fixed snapshots, assuming that data is regularly updated and kept current? (member argued that no, it is not necessary to keep these snapshots as an isolated set of data). Right data must go to right fields, and if something goes awry (wrong info in wrong fields) the checks and balances must be in place to correct this. 98 or 99% accuracy is okay as long as nothing is egregiously off.

-Upstream system has to make basic corrections for initial data that is in error.

-Clarification: are we talking about dropping an aggregated report into HDS? Or transactional data? (Group said transactional data - where errors always inevitably occur.)

-Technical requirements and front end needs discussed, as well as auditing/correction mechanisms.

-95% rule - data must be flowing with reasonable accuracy as AAIS's track record has demonstrated. Becomes more complex with broader data integration.

-When regulators are interested in seeing: when data pulled from HDS it should match. (Comes back to flat file vs relational) - These are the kinds of checks we are talking about doing.

-Also: with stat agents, such a delay in reporting and issuing. The lag time. This will be reduced. But a 100% accuracy standard means a longer delay in getting the information and this is unacceptable - because then data is less valuable to us.

-Clarification of timeline - what timing is desirable? Active discussion of this

-Broader concerns: -gauging the temperature of the market. -trends from large #s in terms of what is happening. When focus is on this, and variances can be tracked, smaller errors become less relevant.

V. Conclusions to above

-In the next AWG or TSC  - are there business requirements on which we do not have clarity? And can we clarify?

Very effective if viewed from a top-down basis. (Consensus that some clarification has been occurring - but more progress is needed).

-Once informational data requirements laid down, what are business requirements?

-Looking ahead to future meetings, people can bring agenda items and raise these in biz working groups.

VI. Auto Discussion Resumed for 30 Min.

-Document opened to see how many fields are left

-Question about Peter - re: POC written up addressing concerns discussed in last meeting

-Peter circulated his document agreed to email later today to resume discussion of POC next week

-We already voted on fields and definitions. Changes identified after we last voted.

-We removed policy category due to ambiguity about personal vs. commercial, and policy tier added.

-And then in column J the yellow ones will be revised, wording will be cut down.

-Body style values have been defined. 

-Motorcycle field is too long, needs to be cut down (probably with implicit understanding that it includes mopeds and other variants)

-The goal is not being state specific, in theory. Exclusions dangerous.

-Trailer vs. "service or utility" discussed and clarified. This is broad. Can include boats, utility trailers used to haul motorcycles and dirt bikes, etc. Very broad.

-How specific do we need to be re: splitting hairs? (Reminder that Stat plan covers both domestic and commercial).

-Coverage code we added a tab for this.

-On policy tab some fields not finalized under 'expected values.'

-State exception codes discussed on auto stat plans.

-Combined first party benefits clarified.

-Income loss limits and funeral expense benefit limits added. Values added to these in column J (numeric with a decimal and negative sign when applicable etc.)

-Request that M. Pereira finish table and send to the whole group for individual review, off meeting.

-Peter plans to send this document out with the scoping document, to everyone, on Monday.

-Some of expected values in column J should be "N/A" - will be replaced with Day 2 fields.

-Gen 0 (current stat plan) vs. Gen 1  (unpacked values) vs. Gen 2 (New fields) discussed again.

-No additional questions. Another request to Melissa for this updated d

-Peter will find out more about Truman's interest in  pulling regulators into AWG discussion.

-Peter formally adjourned meeting at 2:57pm.

Discussion items

Notes

Action items