Date
Attendees
Allen Thompson
Matt Hinds-Aldrich
Susan Young
Brian Mills
Michael Payne
Greg Williams
Kevin Petruzielo
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 - Peter Antley - Welcome to Group & LF Antitrust
II. Agenda - PA - Continuing discussion from last week about changes to stat plan and where to make updates
A. Recap
- Personal auto - light orange stuff will be removed, as this is commercial only
- We're putting ASLOB in red, positions 61-62
- Group discussed rating basis in position 63
- ASLOB pretty simple - 19.1 becomes 191 (decimal removal). Section will be added to stat plan
- Rating basis - this will be a reference code table - same with some coverage codes. Both of those - reference codes not avail yet.
B. Today's focus
- Accounting date (carryover from Fri)
- As it exists -works so that first two positions on it are the month and last position is the year
- If one is loading a really recent record, one can assume based on date abbreviations that it is the most recent year - e.g., '5' would be '2015' not '2005' or '2025.'
- Gets hazier when backloading a db or putting in historical information
- Proposed resolution: interpolating a 4-digit date (year) on the premium record. This was floated to the group. Pointed out that it could be an issue (despite 10 year limit on stat data plan) if HDS isn't purged often enough. Also participants asked why 8 digit date provisioning wouldn't be an option. Answer - what is already there will produce a high level of precision; a date wouldn't necessarily help.
- It was also noted wrt accounting date - this is really when as the accounting month it's being reported. But regarding the 15th, for purposes of earned, we want the data of the transaction. If the transaction happens after close, it might not be sent until the next month's file. The accounting month would be the following month, but the transaction date is what should be used when calculating earned. A transaction date that is more complete might therefore behoove everyone in terms of giving everyone a better calculation for earned. For earned premium, it will be necessary to have expiry date and transaction date; therefore we're talking two more fields. However transaction effective date is most critical in calculating earned premium.
- Earned premium isn't done very often and usually not unless someone is calculating a loss ratio.
- It was recommended to the group that there really should be (listed) policy effective, policy expiration, transaction effective and transaction expiration. (Broad agreement on this point).
- Accounting date is synonymous with the as/of date - when the date was extracted for a given purpose.
- If data is updated more frequently than monthly or quarterly, data may be different than snapshot date. PA: looking at building a ledger of policy and claim events. Might do in-line editing before records are uploaded, but once the records have been updated, they are largely immutable. Instead, additional records will be loaded.
- It was strongly argued that data should be accurate as/of given extraction date. Wrt dates -we're better off specifying a format that has some revisions and also being explicit about the date as opposed to coding the dates to retain flexibility (PA response: no one is advocating coding any more dates).
- PA: starts off by designating four positions to represent the year.
- JB: being more explicit about dates is almost always better given the critical role that dates play.
- Conclusion: the four aforementioned dates (categories) are necessary for certain data calls. For statistical reporting, significantly less is needed - only having a one byte year in accounting date is fine; not necessary to change accounting dates. Other dates can be added.
- PA: suggested leaving the accounting date in 567 the way it is and then having an optional accounting year in positions 68-72.
- It was also suggested that we add transaction date and accounting year if we're adding a date. Going through phase 2 of the data - the dates that need to be added as Day 2 have already been identified.
- On the claim record - there is interest in getting the policy identifier. This can be done on Day 1 per group's comments and would be an immese help in vetting claim erros.
- Decision: put it in position 168 so that it doesn't impact anything else. No objections at all presented by anyone in the group.
- 14 positions currently on policy identifier
- Should be whatever you're doing on the policy record, otherwise the ability to match is lost
- Most of the data that goes on the record layout goes away in Day 2, because you'll be able to match the policy attributes to the claim, not repeat the information in the loss record layout
- We need to figure out the migration plan and discuss with the AWG. As we see duplicate data, and things fall out, we'll leave a blank in those positions. We'll keep the layout about the same to do as few changes as possible
- Months Covered Field - positions 49-50.
- Jenny T. - Months covered field - positions 49-50 - illustrates how EP is calculated at the moment. For the claim identifier there are actually two positions on the loss side. Q: Is this just an extra key of the claim separating as a transaction? What is the difference between an occurrence identifier and a claim identifier? A: Within a claim there are multiple claimants. Claim identifiers identify the claimaints. On the policy side - 14 positions; on the claims side - 12. Do two more need to be added? Group said yes, absolutely add them.
- Discussion of red letters on the claim - haven't discussed this yet. Jen asked about this - red are the commercial version. training and penalty points for personal auto, commercial class and use for commercial auto. It was recommended by group that we strike through commercial class and commercial use.
- Commercial class changed to light orange on both sides
- With the rating basis and the subcoverage code, the reference tables for this need to be developed. Peter is going to work with Jennifer on this. Some input of this came from Susan, but this could have been only on the commercial side. On the personal side, generally just rating basis but could be others? Subcoverage codes can be potentially personal and commercial auto.
C. Summary wrt dates: the dates somewhat work; end dates will be Day 2 but the group isn't there yet.
D. Looking ahead: documentation will be added to stat plan that describes ASLOB positions 60-62; on claims side, documentation needs to be added about policy identifier; rating basis needs to be vetted and discussed.
View file | ||||
---|---|---|---|---|
|
Discussion items
Time | Item | Who | Notes |
---|---|---|---|
...