Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Date

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

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



Minutes:

I. Introductory Comments by Mr. Antley

A. Reading of LF Antitrust Statement

B. Welcome to All Attendees.

II. Agenda

A. Updates - for AWG and RRDMWG (high level)

  1. In last week, switch to PostgreSQL. Data engineer has been onboarded - he's working on loss records, Mr. Antley working on Premium and ETL to load Premium records. Table set up. Function distinguishing between dates (SQL server function).
  2. Two queries for calculating EP based on work over the summer - laid foundation for a very quick transition
  3. Observations
    1. We originally talked about utilizing year/month/day. The team didn't want to put a timestamp, but to keep things simple. However on this database engine, that creates a problem. Mr. Antley worked with this and couldn't get it to drop timestamp aspect. Mr. Antley asked if having extra precision on dates will cause issue. (Unsure about the exact source of this issue, i.e., auto add of timestamp). No concerns presented. Mr. Antley will discuss in AWG Monday. Mr. Harris noted the variable we get today is 3 digits - month month year. Asked how this will be transformed into date. Mr. Antley: AAIS handles this by assuming the 15th (mid-month accounting), and effectively adds a level of precision. For now everything will stay the same.
    2. 2b - numeric for data type. Car years - exposure x months covered / 12. Calculation for car years requires some division, auto generates four decimal places. Mr. Antley asked if team wants to do fixed decimal places. Are 4 decimal places enough? Should we cap everything off to round dollars/round #s. Mr. Braswell pointed out that this may be more of a formatting issue, or a question of how it is represented; asked if it is just a floating point #. Fine as long as numeric translates to a double.  Mr. Madison: per PostgrSQL manual it is not a floating point, but a user-specified precision. Mr. Braswell: level of precision depends on how/for what fraction will be used, in terms of how much it impacts the end line #s. 
    3. Mr. Madison: if we agree that we maintain the highest level of precision as long as possible into the processing, this is a solid guideline. Only downshot w/higher precision is cost. Mr. Madison advocated taking the performance and storage drawbacks to store it more exactly and avoid major end-line aberrations. 
    4. Mr. Madison: it's a business question to decide what level of precision we want to use (4th place, 10th place). 4 places feels comfortable. Simply rounding to penny is probably inadequate. 
    5. Group decided to run decimals to four places. 

Goals

Discussion items

TimeItemWhoNotes




Action items



Wrote 


Cre


In 

I

  •  
  • No labels