peter antley 

Susan Chudwick 

Nathan Southern 

Brian Mills

Justin Cimino

Ken Sayers 

Mason Wagoner 

Greg Williams 

Lanaya Nelson

Ash Naik 

Allen Thompson

Jenny Tornquist

Jeff Braswell 

Patti Norton-Gatto


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:


I. Agenda

A. Classification Codes - Assigned Risks - Stat Plan (Personal Auto Data Standard Draft) - worked way up through p. 37

  1. Positions 104-109 do not explicitly say that they are commercial auto, but when Peter looks at the different classifications they are using, they reflect this line
  2. Peter will therefore delete the commercial content from classification codes - set about deleting multiple pages
  3. He also deleted Michigan (21) from Exception Code A - these are all commercial. Also deleted New York (31) taxicabs and public library - also commercial. 
  4. Private Passenger Non-Fleet Retained
  5. Penalty Points/Surcharge (108-9) Retained
  6. Assigned Risk Coding - Auto Stat Plan-Extended  Discussion

B. Discussion of SDMA Uploading in EBCDIC Format - Peter asked if this is an older relic that should be removed. Group: revised date in the lower right corner means it should still be there. (Peter agreed with this as a rule of thumb). Point raised that openIDL needs to be able to receive both ASCII and EBCDIC formats.

C. Discussion of Acceptable File Formats - raised by Peter - txt zip and pgp, but for mvp for this application, what file types should be supported? Zip files a necessity or only text files? (result of this question inconclusive in meeting).

D. Statistical Data Management Application Basics - Section 2. Peter highlighted this section, because it describes how to work with the SDMA. Highlighted it, for now, because it needs to be addressed, but until loading application is set up, it will be difficult to write the instructions for it.

Peter noted that he will clean up the document and then have Tornquist go through it, then post next week on the wiki.

Noted that functionally we will be closer to the GT2 but functionality will be much closer to the SDMA

E. Project Roadmap

  1. Imperative for running openIDL: a way to submit data, run editing packages, inform in-line editing, and submit to the HDS so that it is ready for reporting.
  2. Mason and Peter developed a project roadmap in 8 phases:
    1. Phase 1: Gathering Current Functionality (This is ongoing right now - in April applies to both the SDMA and GT2 (identifying gaps and issues)
      1. Carrier input (likes, dislikes, needs, wants, etc.)
      2. Login
      3. Landing Page - login, and can see a list of all the submitted files, so base of operations
      4. Upload Data 
      5. Run Validations in an Event Driven Way
      6. Editing of Single Records and Bulk Updates
      7. Run Validations Again - Make sure it's under error threshold
      8. Submission of data - which will move data from staging in the upload application into the actual HDS so it can be used in reporting, pending approval of extraction pattern
    2. Phase 2: Identifying Gaps/Issues
    3. Phase 3: Solution Discussion
    4. Phase 4: Pixel Perfect Mockups (clear sense of what we're going to build)
    5. Phase 5: PoC API/Database  
    6. Phase 6: PoC UI/UX React
    7. Phase 7: Production Migration Plan
    8. Phase 8: Production/Deployment
  3. Application Requirements
    1. Login
    2. Upload P&C Insurance (Local-→OLGA) openIDL Loading Graphical Applications
    3. Running Validations (Edit Package)
    4. Review Validation Errors
    5. Review Records
    6. In-Line Record Updating
    7. Bulk Record Updating
    8. Submit P&C data OLGA-→HDS. 
  4. Questions
    1. Susan: Do we have the capability when we review the validations - are there reports we will review and download if we need to, into our own space? Peter: yes, would like to set up/explore customizable workflows.


Discussion items


Action items