Page Comparison

Date

13 Sep 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.

You have been invited to a recurring meeting for openIDL



Ways to join meeting:

1. Join from PC, Mac, iPad, or Android

https://zoom-lfx.platform.linuxfoundation.org/meeting/93089763014?password=f0e7ee48-7c14-4906-b1c1-3013f0aae7a1

2. Join via audio

One tap mobile:
US: +12532158782,,93089763014# or +13462487799,,93089763014

Or dial:
US: +1 253 215 8782 or +1 346 248 7799 or +1 669 900 6833 or +1 301 715 8592 or +1 312 626 6799 or +1 646 374 8656 or 877 369 0926 (Toll Free) or 855 880 1246 (Toll Free)
Canada: +1 647 374 4685 or +1 647 558 0588 or +1 778 907 2071 or +1 204 272 7920 or +1 438 809 7799 or +1 587 328 1099 or 855 703 8985 (Toll Free)

Meeting ID: 93089763014

Meeting Passcode: 850916


International numbers: https://zoom.us/u/alwnPIaVT

Attendees (12):

Dale Harris 

Jenny Tornquist

Brian Mills

Peter Antley 

Patti Norton-Gatto

Susan Young

Josh Hershman

Jefferson Braswell 

Greg Williams 

Sean Bohan 

Chudwick, Susan R 

Ash Naik 

Minutes

I. Introductory Comments - LF Antitrust and Welcome by Peter Antley

II. Agenda/Meeting Business:

A.  Updates on OLGA 

1. Much of content wrt OLGA that has been shown to date was prototyped and set up as a front-end website. This week the team has worked on the services layer- connecting database to front end
2. No webpage updates today - more coming next week
3. Focus of today: data elements and data extraction information with CAT reporting they are looking into
   1. Jeff - talked through various elements - data element definitions for NE CAT PoC that will be used for report
      1. Line of insurance - homeowners in this case
      2. Transaction date - date when the transaction was booked - fixed format codes (mm yy) - they talked about the poss. of making this an actual date if this fixed format makes it more difficult to use
      3. State code - reference codes for this are documented in separate tables.
      4. County Code - per state - ties in later with the zip code element, used for isolating claims pertaining to areas afflicted by catastrophe, and used to weed out unaffected areas.
      5. Transaction Code - includes paid loss + outstanding loss; 6-7 digit codes for new members that haven't used this format; mapping from their systems to these codes needs to be set up
      6. Loss Amount - table for this that is in this document as well
      7. Cause of Loss
      8. Accident date - actual date in which the loss occurred.
      9. Zip Code
      10. Claim number - says all of these claims in the event record are part of the same claim # (each claim has a unique identifier)
      11. Claim identifier - the identifier for each particular claim event
      12. Catastrophe indicator - identifies catastrophe, but for the purposes of the PoC, limited to this particular catastrophe -  we determine from whatever data is extracted a binary indicator - was this part of the catastrophe or not?
      13. Accounting Date - it was recommended that this actually be a date. Suggestion: perhaps a placeholder for the date, and then it would default to the 15th if said date is unavailable). - Agreement with this change, no objection.
   2. Peter discussed calculation of the various amounts for the reporting side of things (pulled up excel sheet to illustrate). Looking by zip code; reviewing by county as well
      1. Looking at Number of Claims Recorded
         1. From our table - want to count the amount of records and alias to the claim count - where accident is greater than start date and less than end date
         2. Causes of loss - in a, b, & c - which are yet to be determined.
         3. Group by claim identifier to avoid double-counting records
         4. If multiple transactions in same accounting period and same claim: if they have the same claim identifier, they will be grouped together into one record - so can only count as one in this case.
         5. Claim count will indeed be a unique count rather than per transaction (not a record count but a claim count based on the claim # and id)
         6. Peter pulled up an example - made sure that the given record had a transaction code '2'  which means it has a payment associated with it. (It was noted that he should further filter by location). For number of claims closed with payment, trans. code 2 needed, but to assume it's closed, they need to make sure it also has a transaction code '3' with a loss of 0 - to have an outstanding of zero. It's an open claim if it has an oustanding reserve.
         7. Looked at number of claims closed without payment (first) before coming back to one above it.
            1. Peter said 'I want to find all the ones that have 0 outstanding.'
            2. Of these, he said 'I also want to get rid of all the ones that have a level 2 transaction code associated with them.'
            3. Table A - outstanding with loss amt. 0 - without pay; table B - records that have a trans. code 2- there was a payment. Give me all the claim identifiers not in table B
            4. All of the amounts from these transactions will be summed up (but have not been accrued yet) - loss amounts. Peter will add this.
            5. We're aggregating based on these criteria that we have.
            6. Need to find the most recent outstanding.
      2. Also looking at number of claims with payment
      3. Number of claims closed without payment
      4. Paid loss (pure indemnity)
         1. Make sure it has the right accident date
         2. Right cause of loss code
         3. Transaction code of 2 or 6 (latter to accommodate ALAE).
         4. Accounting date is before reporting date
      5. Outstanding loss - (for transaction code  - 3; ALAE would be transaction code 7).
      6. Case of incurred loss
   3. In code:
      1. Peter will get the Most Recent Outstanding updated on here
      2. He will try to track down some documentation on the report and share with Jenny Tornquist
   4. Peter also received the error count on the error component but Peter doesn't have it available to show as of yet - will get the database connected for this
   5. Will also be running the DROOLS engine
   6. Also working on getting sample data and hoping in oct to have the application deployed somewhere, so that guests on the RRDMWG call can explore it in real time and get a sense of how the filters work.
   7. DH noted - Travelers - that with stat records, they don't provide outstanding loss = 0; it was noted that if they don't provide it, it is assumed to be 0. This is in the pseudo code they are trying to find.
4. Discussion about the next RRDMWG on 9/27
   1. Looking ahead - Jeff will meet with Peter later in the week to review code
   2. They will also meet with Jenny Tornquist to discuss further.
   3. What is available from the claims side from the carriers - Dale & others need to be corroborating what is available/what they can provide to help fine-tune this. Derived fields are simply based on what we think we can get from the data extracts. Progress definitely being madeddddddddddddddeeeeeeeeeee

Discussion items

View file
name GMT20230913-145703_Recording_1920x1080.mp4 height 250

Action items