Date

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

Goals

Discussion items

TimeItemWhoNotes
1Anti TrustPeter
4AgendaPeterWe can add items
20Final Review of CharterGroupGoal is to do final review- Regulatory Reporting Data Modeling Working Group Charter 
30Business RulesGroupAttributes Index
5Plans for next weekGroup

Action items

  •  

2 Comments

  1. James Madison

    Per my action item on putting together a list of the global traits a data model should have, it's below.  Per the discussion of approval, this is 100% industry knowledge, so I'm not worried.  You can find this in some industry literature somewhere–I just consolidated it.  It's not even from a particular company standard.  Just stuff from doing modeling for a quarter century.  The COLUMN label means you can solve some/all of it at model definition time.  The ROW label means the ETL jobs when it loads rows has a part to play.  May need both.  I'm sure there are more, but this is a good start.  Not all are self-explanatory, but happy to discuss more in our meetings. 

    • Dollars are onsets/offsets.  $800 to start, goes to $1000.  Send $200, not the $1000.  ROW
    • Favor meaningful labels over cryptic codes.  Extremely common codes allowed; states, coverage codes.  COLUMN/ROW
    • Dates are stored as dates, not string-encoded dates.  COLUMN
    • Date/time stamps are at a consistent precision.  (Day?  Minute?  Microsecond?  Need to standardize).  COLUMN/ROW
    • All numbers are at the same grain, and it is the grain of the entity.  COLUMN/ROW
    • Primary keys are actually unique.  ROW
    • Primary keys are not smart.  COLUMN/ROW
    • Foreign keys actually have parents.  ROW
    • All entities are at the minimum declared level of normalization.  (Need to standardize).  COLUMN
    • Weak entities are favored/discouraged.  (Better versus easier.  Need to standardize)  COLUMN
    • All entities must somehow allow for 100% traceable history.  COLUMN
    • Do the logical model at the Silverston level, not the Kimball/Inmon/Vault level.  COLUMN
    • Avoid bucketing data at the transactional grain.  COLUMN
    • Provide coding tables for every enumerated attribute.  COLUMN
    • Use only values from the enumerated attributes for attributes with coding tables.  ROW
    • Cells are always atomic.  Date, number, string, etc.  Not JSON and such.  COLUMN/ROW

    Other opinions very welcome.  This is just my two cents.

    Thanks!


    1. Ruturaj Waghmode

      Thanks James.