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.
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
Using stat plan as it exists but we want to highlight gaps in plan.
Re: Coverage Code 9 - reporting problem. In a position to change our generation table to no longer use 9, force to other buckets. (Short term - 2022 reporting, 2021 already done).
Longer-term: many other coverages have not been identified and should be. (List presented in meeting). Exception codes: certain states look for certain coverages. e.g. Pennyslvania. Identifying numerous subcoverages. Could potentially be opened up to other states. Short term we need codes for add'l coverages.
Re: coverages - base and non-base. Many of these coverages would be added on top of base coverage. This needs to be identified. Exposures can/should be reported.
Ran into trouble for coverages for hired and non-owned. In those situations we mapped to coverage code of 9, had to.
Ultimately, states will want more information at coverage level. For initial phase we can report for each state what they want. But as this is mapped out, states will want broader coverage info reported regularly, even on a per-line basis (auto et. al.). Therefore we shouldn't limit scope of what we're doing long-term.
Meeting with other states: get more consistency as far as what is being reported. Many of states are collecting info but not doing anything with it, perception is that it is old and not so useful. One of critical goals: keep project at high level, useful information, project should stay as broad as possible.
Peter: our current charter speaks to regulatory reporting re: satisfying existing legislation. (internal disagreement about requirements of the legislation itself - some attendees saying legislation is very minimal).
We started w/auto - what fields make sense, and what words (as opposed to codes) do we put around these fields? Close to finishing auto.
Do we want more regulators and companies to get on board? Yes, so we need something to show. Existing stat plan - Day 1 - get this into OpenIDL and produce reports accordingly.
We need to get recentered in next meeting - careful not to let it go too far off track. Simplicity of how we do this on a streamlined basis w/o getting mired in code. More we can get it centered on a simple blockchain distributed effort, the better we are (internal agreement on this point).
Question raised about next meeting re: Good Friday. Suggestion of postponing and then we will reconvene 4/22/22 Fri. (No objections here).
Subcoverages added to AAIS stat-plan - building for the future, etc. (Agreement on this point). Our goal is to get it all out of Coverage Code 9.
Detailed discussion of Pennyslvania and how PA breaks down coverages. Do we need a subcoverage field added? Statement line itself great first step, we add new data element later to help break it out even further.
We can't implement stat plan changes until Jan 2023.
Can PA breakdowns be applied to other states? (This is a possibility).
Very difficult to do stat-plan changes in mid-year. Necessitates retroactive changes for the sake of consistency.
Peter going to check on auto state plan changes for first quarter of this year and get back to everyone this week
Two other WGs met this week: TSC and Architectural WG. Good progress on both fronts re-orienting ourselves and discussing key points re: technology. Test-driven developments and validations, where technology will live, how it will interact.
Another Architectural WG 4/11 3pm EST: discussing IDL as a service and what is happening within the enterprise. Everyone on this call invited.
Topic raised: how do we harness data in a common way, where everyone cedes to same rules. Yet edit package needs to be run outside of nodes by stat agent. Otherwise stat agent cannot say they have checked the data and it is all valid.
Part of doing an extraction: certifying that data has already been verified and it meets x requirement.
Non-reporters list for individual reports - data that didn't make it. Vs. list of data that is accepted.
Edit package - ensures validity of data within specific percentage.
We cannot just have the edit packages in the nodes. Need to be validating external to notes. This is exactly the issue we need to define, will simplify whole process. Info in nodes: subjective. What carriers know to be valid. This is my experience for this month or policy, this policy is current up to x day or x month. But it is not final until year has closed, then reconciliation occurs w/financial data.
If initial data is high quality (integrity + trust), it can virtually be used for any reporting. If it can be used for a month-to-month policy dashboard then it becomes much more useful. But has to be much more timely. Acceleration of data is possible, but we can't get more detailed data until we break through to identifiers like address, zip code, etc. and do add'l decoding.
Looking ahead: do we want to go for a simple data model or something more? This is a decision that needs to be made
We will reconvene in two weeks' time? Broad consensus on this point.
