2023-04-14 Meeting Agenda

Date

14 Apr 2023

Attendees

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

Hicham Bourjali

Jeff Braswell 

Allen Thompson

Jenny Tornquist

Dale Harris 

Susan Chudwick

Joseph Nibert

Ken Sayers 

peter antley 

Nathan Southern 

Reggie Scarpa

Kelly Pratt

Susan Young

Lori Munn 

Mason Wagoner

Mike Nurse

Greg Williams

Patti Norton-Gatto 

Sean W. Bohan 

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

Artifacts:

example-rules.xlsx

AAIS Rules Engine Documentation.docx

Minutes

I. Introductory Matters

A. PA - welcome to attendees

B. PA - acknowledgement of LF antitrust statement.

II. Agenda

A. Recap

1. Excellent discussion last Friday: stat plan and related documentation.
2. A copy of this revised will be available a week from today.
3. A couple of minor internal checks to do before it is fully open sourced, but last week was helpful - when many of the commercial auto references were removed from the personal auto stat, in-meeting.

B.  Today's business/points of discussion

1. Validations and how the rules engine/rules are working
   1. Peter began looking into rules as they are and open sourcing them and sharing them with the group.
   2. The company specific rules are now co-mingled with the ones not specific to AAIS. His riding assumption is that companies with specific rules will not want those shared with other companies. (The others in the meeting strongly agreed).
   3. For today, Peter pulled out a small subset of rules to go through them, with accompanying documentation
   4. Over the next week, the plan is to go through auto, remove all the company-specific rules, and then look at all the rules.
   5. Two documents to review today:
      1. AAIS rules engine documentation. (Name is tentative subject to change) - will be rebranded for openIDL.
         1. There is a set of validation rules for each line, and some validations for dates and for geography and common validations.
         2. Rules get saved into an excel template. That tests for four errors. Positive identification of errors in lieu of positive identification of correct values. 
         3. There is one column for each position in the stat plan - e.g., LOB. 
            1. Example of this: rule 9.1 - affects LOB 56 and will say re: Program Code '<>blank, 0,3,5,C, F' 
         4. A unique error code is associated with each rule (.e.g, Error code 9.1., 9.2., 9.3) - there is also a human readable error message corresponding to this along with 1, 2, 3, 4 id #s to make them trackable.
         5. It is possible to have multiple rules about any column.
         6. Different errors will emerge if it's blank vs. Not blank but with a restricted value.
         7. May come up as 'missing,' 'invalid,' or in some cases, 'state-specific.'
   6. When the SDMA runs, it pulls from these documents as a configuration, to enable running the rules against the stat records.

-Rules get saved in template. As laid out, it tests four basic errors. Seeks to positively identify errors as opposed to positively identifying correct values. One column for each position in the stat plan. 

-Rule 9.1  - LOB 56, it shows that program code should not be blank for multiple fields. Unique error code associated with each rule. Also provides description, and an ID for tracking. 

Discussion items

Action items