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

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:



Meeting Minutes

Discussion items



RRSC FocusRobin

MVP discussion


Peter opened meeting @ 1:06pm.

Robin Westcott began discussion for AAIS. 

I. Different ways to statistical collection: -stat reporting is not really working, let's do something different, -work from a basic data model, and -everything in between

We don't approach this as traditional voting but as consensus building

This standard, while it's a legitimate exercise to support statistical reporting activity and takes some effort through Sandra's working group to change perspective and mandate, we need to understand what the statistical reporting model really is

At AAIS they went back to square one. Dug back into why they were doing this again. What do they need to do to make sure data was being reported as it should be, they went back to stat reporting handbook. How has it permeated thought processes?

Re: surveying and legal research, we learn it's not what we think it is

AAIS has done research in all 50 states re: their provisions about collecting statistical data. Usually rooted in losses and experience. Very few written mandates however.

Only 4 states have adopted stat reporting handbook by statute. A few follow it nominally but not in practice. 23-24 states have rules for collection of statistical data, no reference to handbook but something about collecting in general (Texas is an excellent example, Illinois as well). Variance from state to state.

AAIS spoke with all but about 2 states to find out what they are doing, who it goes to in their depts, etc. etc. 

AAIS doing this activity, but doing it without very cohesive or firm legal requirements or codification (no consistency). This inconsistency is a real problem.

Fast-track reporting is in the handbook - assumes there is a consensus about this but there isn't.

What are the metrics? How are they determined? Not transparent.

Key to start thinking about "why we're doing this" again.

II. May 10 - RRSC monthly meeting is coming up. 10 voting members will be present, to ensure we start to give better policy decisions, and better able to strategically support work going on at NAIC, & w/ various working groups around data.

Voting groups need to be formally approved. Eric Lowe, George Bradner, Kim Bradner, etc. Call.. interested in being voting members? Goal: 10 party voting members. Hopefully no split within voting member body. Whole purpose consensus.


-Voting members solidified

-Even for those not interested in voting, please sign up for attendance.

-Lori & Robin will work to get results of research re: stat reporting posted on wiki, from per state discussions. 

-They will also be formulating an agenda for that steering committee meeting. 

-Key question: what do we really want to create when we are pursuing a standard?

-Many of states get report and are unsure what to do with it. Digestible format is critical for them. User friendly etc.

-Regulators need to get full value out of it.

-This points to why dashboard design is critical. What does a regular really want/need to know? This needs to be clarified.

-How do we make it valuable for the regulators and companies viewing this data that is coming in? This is a critical question. Better resources to NAIC.

Two ways to look at this (listener response)

From statistical plan perspective data is valuable, but it is not being consumed

From an industry perspective (Travelers) no benefit from it

This is the broad hope for IDL.

Goal: looking at their data compared to total industry

How also do we accelerate the collection of data?

Wide consensus auto plan is the best place to start.

Response: We need to look at elements we are collecting and see what is consumable. NAIC has done great work. How do we take this data into dashboard, making it consumable by everyone?

How will output structure impact work we do from here on? Dashboard. Digestibility. 

Peter: we need to lock down what MVP is .Also has drawn up a lucid chart he's about to share. (This presented formally)

Questions: -What is available today (aais stat plan and data elements).

Resumption of question: what is value of starting here? Objections discussed.

Peter: delay of data collection is a serious problem. This will impact overall timelines. Also they went through Eric's policy - some we can do immediately some further down the road. We need a plan for updating versions of model.

Question: what is the minimum model we need? This will define what AWG and TSC are doing as work. Practically.

Architects must understand what we ultimately want. This has to be defined. 

Distinguish between tech and data architecture critical.

Also question flat model vs. relational. Flat doesn't scale. It hits a wall, while a well normalized model can scale. This is an architectural shift. It enables scalability. Add-ons via add'l attributes.

(Some disagreement about elements and what data is needed).

AAIS auto stat plan - onto next step? (Survey taken - broad consensus).

Objection raised: flat vs relational model irrelevant. By startingl with auto stat plan data, add'l lines can be added to it.

What adds value: question of what are we going to publish out?

Time to do some work about what we will be giving at end of MVP to prove we did stat reporting through openIDL

AAIS auto stat plan - generation zero, will be sent to AWG & TSC. Can move forward from there.

Architectural objections raised. We need to place more of an emphasis on architecture moving fwd.

Counterpoint: Architectural aspects of plumbing and data modeling are intertwined.

Any objections to Peter taking AAIS stat plan w/addition of NAIC statement 1 and going to AWG on Monday so we can produce reports? Some clarification requested before yes/no vote taken.

Clarification from Peter re: nature of an extraction plan. Gen Zero model, any extraction plan given will be able to run against this. Normalized model - Generation 1 Model. However multiple layers of versioning will be required.

Gen Zero Model - Flat Stat Model.

Gen 1 not additive to gen zero. Changes to all codes, etc. (There is also a migration plan Gen 0-1 in place). Gen 0 key for establishing value.

(Note: Broad Consensus on this).

Not much more to build out with the auto.

One of key obstacles looking forward: each of stat agencies coding something differently. This has to be resolved. 

Output has to be semantic, readable, not esoteric codes, etc. (Again broad consensus on this).

Susan Chudwick and Melissa Pereira pulled up codes (in spreadsheet) for auto.

Timeline clarified for gen zero implementation - and redirected for Architecture WG. (Noted that it isn't very clear from perspective of this group). AWG will build a timeline out after working through a bit more of backlog. AAIS very much wants to know/clarify timeline.

AAIS focused strongly on end dashboard.

Broad consensus reached - no objections raised. 

Rough timelines again requested surrounding build-out.

MVP defined by group.

Gen 0 data: how valuable is it? A: some of the carriers needed to justify amount of time put in and what they could materially show to companies to reflect value? Regulators have the same question.

Proof of Concept POC might be the key. If output is interactive and accessible, this accrues more value - easier to show it to other regulators, take it to stat data RG, etc. Great way to get conversation going - about triggering some level of fundamental change in industry.

Gen Zero - visualization will be included, at the same time we are testing the system to see how effectively it works. Value will be seen that we didn't expect and didn't know was present. This always happens.

Looking ahead: Gen 0 - all codes, Gen 1 - Unpacked + expected values - Gen 3 - w/day 2 fields

peter antley  wrapped meeting/adjourned at 2:28pm


Action items