Date

Updates to the stat plan
1. Exploring the life cycle of data and how everything works
  1. By way of example - he might have a million policy records and 100,000 claims
  2. He uploads it - but when he uploads the next set of stat data, is this new policies/claims, or will old records/policies be updated?
  3. SC: Always a new record, but isn't always a new policy or claim. There could be a change, an offset/onset record, but everything is not "new."
  4. PA: The records e.g., that one uploaded in October, will always be those records; the ones uploaded the following month might be changes but are ones that would be interpreted in connection with the Oct. record so that you would see the total policy. (Susan agreed). All of the months have to be looked at for policy-level activity over the course of a year.
2. From last week - openIDL data standard developed by Peter to present to the group. (Pulled it up and presented to the group)..
  1. Color codes:
    1. Yellow - points of discussion
    2. Teal - sections identified as potentially being a preface in openIDL data standard - line of business agnostic, so they can apply to anything.
    3. Purple - introduction of SDMA vs. a new Olga Platform
  2. Instructions: General instructions (highlighted/color coded) vs. line specific instructions (not highlighted/color coded though the
  3. Modifications (in yellow on document)
    1. terrorism indicator removed from general stat plan
    2. zip code +4 suffix discussed wrt Table of Contents and retained.
    3. Report Frequency & Required Report Dates - part of general recording information. Specifies that all data is to be reported quarterly. PA suggested that this be modified to monthly; group said quarterly has been most common on a historical level and monthly might be a cadence to which we aspire. The regulators have complained in the past that the data takes a long time to reach them - so reaching a monthly cadence will get the information to them more quickly and increase openIDL's value. It was stressed that even quarterly however (on idl) is a vast improvement above traditional stat turnaround times, and that whether it is done quarterly or monthly the outcome at the end of the year would effectively be the same. (Travelers mentioned that some of their data calls are monthly, and some are quarterly). Hanover stated that they mostly have annual or quarterly calls. Peter decided from all this that it would be kept as quarterly
    4. Peter singled out two paragraphs that concern the AAIS data mgmt dept. and asked if these should be excised.
      1. The first indicates that data submitted via the SDMA must be done within 60 days following the close of the period reported. He was advised to retain the 60 calendar days, or some time after the end of the quarter. Decided to keep this sentence and drop sentence 2 ('Companies that cannot file on time must have an officer notify the AAIS Management Dept.')
      2. This led to a discussion about how it will be managed overall; PA stated currently there is no mechanism in place for auditing HDS data. The regulators with which AAIS has spoken have said they trust the HDS and if some instance of concern arises they will do what is necessary to obtain better data. Their goal is: how do we get accurate reporting more quickly. Ultimately Peter decided to excise the portions about AAIS Data Management.
      3. It is the stat agent who ultimately needs to be informed of data errors. openIDL's policy: carriers responsible for putting data into HDS; accurate when it is put in there. If it needs to be revised, it can be. openIDL will not manage the data ops, but the network itself.
      4. Questions arose in the discussion about who within the openIDL network will do the auditing if something is wrong with the data.
      5. It was suggested when one looks at the set of requirements that some will be predicated by the statistical agent. AAIS and openIDL are not the same thing and do not perform the same function. There will always be a stat agent, and the stat agent will likely also have rules on top of the AAIS rules. openIDL doesn't have those requirements. openIDL is just the platform or the format for making it happen. openIDL will have their permissioned network membership aspect, and members will consent to data calls from those sources including AAIS.
      6. openIDL has no data management function; merely provides the means for data call requestors
      7. Peter's summation: there will be an openIDL data standard that will describe how to holistically structure policy & claims information to make reporting efficient. But AAIS will also need the statistic reporting book as a handbook that it will use in its role, where applicable, as a stat agent, with the rules applied accordingly. (And the rules in yellow in the stat plan correspond to these). Others agreed. 'If you want AAIS to be your stat agent, you have to abide by these rules.'
      8. The purpose of the data standard in HDS is to have the common data model used in HDS support whatever applications openIDL is supporting with data calls.
    5. Peter and Mason - suggested changing the highlight color from yellow to light green to signify AAIS stat agent rules.
    6. Section 4 - Method of Reporting (SDMA) - changed to teal highlight color since it pertains specifically to OLGA. Changed to purple highlights.
    7. Timing of Corrections - will be green because it's going to be part of statistical element
    8. Line 56 deleted - indicating application to both personal and commercial
    9. Accounting Date - Within the HDS, how much data should be retained? Some claims could be 10+ years old. Will three digits be sufficient? Peter: has already highlighted this as an area that needs adjustment. Peter and Jen noted that CGL/New Jersey goes back 5 yrs. for auto (in lieu of 3). No one is 7 for stat reporting. So PA - it could make sense to go back 7 years just in case. Dale noted that this will be instilled on a go-forward basis, not in terms of looking/working backward to avoid recreating the prior 10 years in this format. Clarified that if this launches in 2024, it would start with 1/1/24, not go back to 2023/2022/2021.
    10. It would depend on what openIDL affiliate it is/was and when they joined AAIS. (PA).
    11. AAIS is now debating if all of the stat data requests in the future will be pushed through openIDL, or if AAIS partners will have the option of using legacy methods. Long term plan is to move carriers to SDMA and turn off the legacy systems, but this will likely not happen very quickly. The plan is for everyone to maintain their own data, and get it out of nodes to report it. AAIS: it may be a case also of doing 2-3 years on legacy system and most recent year on openIDL. The means of transition - still up for discussion. Data from both systems may be meshed together for several years while AAIS migrates off of legacy systems.
    12. A note was added to clarify instructions on the use of Ascii.
    13. All 'body sizes' of vehicles left in table to cover different situations and contingencies. Consensus that body size alone shouldn't impact what is in the table.
    14. Discussions of companies & payroll under 'exposure' - 'Companies reporting garage risks must report exposure in per $100 of payroll.' - This is a commercial clause (the group noted). Group decided to exclude this from personal auto data standard.
    15. Discussion of Package Code - 'Auto coverage written as an endorsement to a CMP, CPP or BOP Policy.' Changed to 0 - for Auto coverage written as a separate policy and not an endorsement to another policy; and 9 - for Auto Coverage written as an endorsement to any other type of policy.
    16. Exception Code D - Taxicab content. All commercial. Excluded.
Stat Plan Layout - Peter pulled it up and presented it on the screen - 'openIDL Data Standard Positions' - Premium record on left, loss record on the right
1. First point of discussion: ASLOB - wants to get this codified and add it to the stat plan. A couple of different Annual Statement Line of Business Codes associated with auto: 19.1, 19.2, 19.3, 19.4, 21.1, 21.2.
  1. Some of these are commercial - we only need 19.1, 19.2, and 21.1. The rest can be deleted
  2. We want to get rid of the decimal point and use positions 60-62 to capture the three digit code - e.g., 19.1 becomes 191. (No objections presented to this). No objections to putting ASLOB at 60-62.
  3. Rating basis: red ones are aligned what Susan recommended based on prior discussions with AAIS. Rating basis is a better way of identifying type of exposure - e.g., car years, vs. miles vs payroll. Trying to lock position in for 63 - iso has something similar in ratings. Not locking in codes.
  4. We will need to develop reference codes for tables - where to start/what is plan of attack? Gathering next week to start hashing this out for all auto personal & commercial. Question: would it make sense to bring example codes for discussion next week
  5. Peter and Jennifer will go over documentation
  6. Peter has a large list of additional positions to discuss with group - e.g., proper accounting date, effective and expiration dates, etc.

III. Logistics - moving meeting to Wednesdays - next one will be 11am EDT on Wed. May 3rd.

Discussion items

Time	Item	Who	Notes

Date

Attendees

Minutes

Action items

Browser not supported