Page Comparison

Date

01 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

• Eric Lowe

• Peter Antley
• Jeff Braswell
• Sean Bohan
• Dale Harris
• Karunakar Vangala
• Stephen Lee
• Jodi Ebersole
• Brian Hoffman
• Kristin McDonald
• Ken Sayers
• Kevin Petruzielo
• Libby Crews
• Melissa Pereira
• Jim Baronowski

• Chudwick, Susan R

• Ash Naik
• Sandra Darby
• Joan Zerkovich (Deactivated)
• Brandon Roche
• Nick Vitale
• David Reale
• Truman Esmond (Deactivated)

Goals

Meeting Minutes

• Truman introduced meeting and provided LF Antitrust notice with accompanying snapshot
• Recap on meeting from last week
• Various introductions from attendees
• Started out by reviewing POC presented by AAIS, created by Peter Antley this week. We will focus initially on four lines.
  • Who is doing this? (us)
  • How are we doing it? (multilayer approach)
  • LLVs - deep roads into auto. Homeowners next? Then BOP then GL.
• Phase 1: Analyze fields from carriers available to day 
• Establish dictionaries and definitions associated with stat plans
• Tuesday group: normalization and more technical side of the modeling - move beyond simple object model
• Phase 2: Unpacking the existing fields and decodifying everything - breaking into more detailed coverages
• Analyze: what is the next level of detail we want
• Tues. group: normalization of unpacked data
• Phase 3 - Define additional fields based on gaps etc.
• With this approach, two things to consider: concept of a model that will be "versioned" - so if we pick 4 lines we can have an MVP model put together very quickly
• In parallel, we can create value by making the data richer.
• Attendee responses: clarification of meeting purpose. What does it mean to commit to moving forward etc.? What do people in the meeting need to do to commit to moving forward? 
• We can start simple with data, but should begin with clear-cut alignment on goals. Data can be simplified but should be used to demonstrate technology first and foremost. Does the tech work, etc. How much value will it provide?
• Recap from last week: we need to use this call to begin getting alignment around the scope. (Agreement on this point).
• Initial POC is done, but we aren't clear on how quickly this needs to be moved into production.
• Will effort of using auto stat plan work? We should join/align around this effort, and make sure tech and data sides are aligned. (Informal consensus on this point).
• Build out as full a version of the tech stack as we can and see if it's palatable - put production on the back burner. But what minimal model/architecture do we need to test the pipes? What's the system, abstraction level, transformation, etc.
• Focus on big picture: where is transformation going to happen, how is that permissioned, etc. Fundamental implementation details need to be defined.
• Slight course correction - for this call: focus on the Day 1 feature set. 
• Initially just give the data block as we would
• Clarification of timelines: how much time are we talking and how many changes can we make within the scope of Day 1. What fields by when? And where does it go architecturally?
• Phase 1 is basically complete. (Some disagreement about how much value Phase 1 data provides). How much more value if it is built out?
• Many ready to provide more data support and get behind unpacking data. How can we show that architecture underway in WG is a viable path forward.
• Once stat plan is in place and we have a fully functioning architecture/data set, everything else will fall into place. Later: deeper modeling that will require more intensive time investment. Basic stat plans vs. deep ISO stat plans
• Return to discussion re: using initial POC Proof of Concept. Run a fairly simple/straightfoward POC. (Consensus)
• Discussion about what happens to this group after Auto finishes? Possibility of a 3-4 month delay until architecture group makes some add'l decisions. Arch. group will continue.
• Day 2/3 Auto or Homeowner Day 1? (Choice)
• All Day 1s first for all lines of business to get all statistical reporting done prior to moving into production. (Broad consensus on this).
• Initial stat plan - normalize and get through all lines of insurance.
• Architecture Group: clarification of prioritizing in AG - can be making sure that architecture is suitable as a working way fwd. Make sure that whole stack really delivers on full value add or is capable of doing so. What does architecture look like and how do we make sure it's reliable? Has to have all the pieces in place.
• Bottom up vs. top-down holistic approach. Can go either way.
• How many types of solutions do we want to support in initial rollout of architecture? Extended discussion about this.
• One POC that works as an interface layer, more service based.
  • Okay with multiple ways to access OpenIDL network? Q: Will data ever leave node? (A: No - no talk of this at all).
  • Functional network independent of carrier networks, adapter, networks interface with that adapter without data leaving nodes, aggregated results will be returned. All critical pieces are there are part & parcel of initial POC. Then: if we are to expand it, it would be stable & functional sans major changes
  • One large POC or many sub-POCs? (Question raised to group). Answer: One comprehensive POC.
  • Discussion about naming new POC - Alpha, Beta, etc. PPAD1 Architecture - Private Passenger Auto Day 1 Architecture PoC
  • Success criterIa: successfully recreating statistical reports for private passenger auto.
• Looking ahead: architecture group meets next week.
• Defining Day 1 work
  • Hoping to get Susan and Andy with us to discuss possible addendums to auto list. Slight modifications to make process better. 
  • After that, enumerations to get done.
  • We need to go through existing stat plan and restructure data (from flat file) and determine modifications we need to make and hold a vote on it, then follow suit. Improvement of documentation.
• Susan discussed deficiencies of current auto stat plan - has gaps. Suggestions for changes, but will have to be documented and run by other customers, and effective in 2023. So this may not impact Day 1 POC.
• Nick: discussed 19.1 vs. 19.2 key differences. 
• Reconciliation is absolutely necessary.
• One core problem: coverage code listing is not complete enough. Recommendation is to add addl coverage codes plus annual statement line. Just adding annual statement line alone will not resolve mapping issue
• Possibility of two addendums: temporary fix?
• Can vote on all this next time to give AG something to work with. (Placed on the calendar for next week). Show to different providers.
• Connection point defined btwn AG and RRDMWG. Critical. Make connection more seamless to keep everyone on same page
  • Prior to March we didn't have the AG, and now that we have both groups we can keep separation. RRDMWG should stay focused on Data
  • Quarterly meeting of both groups together proposed (consensus on this from LF rep). Or something in middle between monthly and quarterly.
  • One of challenges: overlap between the two groups. 
  • Updates can be collected btwn meetings - would be incredibly helpful. Provided to each at beginning of meeting re: latest updates from other groups.
• Discussion resumed about coverage codes, additional categories, and associated/required timings.
• Wrap-up: look ahead to next week, discussion of auto stat plan and possible modifications.

Discussion items

Notes

Action items