Refactoring of coverage_code and coverage financial terms

[sstruzik]

Description

CoverageValues is a new sheet/csv file in OED V4. It is there to describe more formally the coverage id and coverage code for all class of business. Historically those information were implicit in the naming convention of the financial terms associated with coverage.
the following list will give some examples of "coverage terms":
for location
LocDedCode1Building
LocDedType1Building
LocDed1Building
LocMinDed1Building
LocMaxDed1Building
LocDedCode2Other
LocDedType2Other
LocDed2Other
for condition:
CondDedCode1Building
CondDedType1Building
CondDed1Building
CondMinDed1Building
CondMaxDed1Building
CondDedCode2Other
CondDedType2Other
CondDed2Other

As we can see in CoverageValues those implicit name have been translated to
CoverageID CoverageCode
1 1Building
2 2Other
3 3Contents
4 4BI
5 5PD
6 6All
and the new coverage for Cyber have been added but with a slightly different naming convention
7 BI
8 CBI
9 DIAS
10 EXT
11 FIN
12 INRE
13 LIAB
14 REG
15 ENO
16 CYB

I would like to take advantage of the change of major version to refactor the name of the coverages codes and the associated financial terms.
The new CoverageValues file will be like this.
CoverageValues.csv

In particular the most important change is the renaming of the property coverage codes and will imply the renaming of the financial terms.

To explain with an example,
From the name LocDedCode1Building, we extracted the coverage values => 1Building
I would like to change the coverage value to BLD instead of 1Building
and have the same naming convention as the cyber coverage
so LocDedCode1Building => LocDedCodeBLD
same for all coverage level terms (loc, cond, pol, acc)

I also would like to add an extra column SubCoverages in order to describe how coverage should be grouped for higher level terms.

Reasons for change

1. its always nice to have a consistent naming convention
2. This modification help removing the potential confusion between property 4BI and cyber BI. Each will have it's own explicit code readable without prior knowledge
3. It simplify the tooling to interpret each financial terms and may remove the necessity for hard-coding certain rules on third party provider (oasislmf)

Scope of change

• Location File
• Accounts File
• Reinsurance Scope
• Reinsurance Info

Impact of change

If accepted, ODS tool will provided an oed3-to-oed4 converter and the capability to seamlessly load oed3 file as oed4 ,or load an oed4 file as an oed 3 file.
So there will be no impact on existing oed exposure going through ods_tools.

[MattDonovan82]

So to confirm @sstruzik and for the benefit of transparent dialogue for everyone, you are looking to extract the coverage values (i.e. '1Building' to 'BLD') so the field for example LocDedCode1Building would become LocDedCodeBLD. This would then be applicable to all coverage levels (i.e. CondDedCodeBLD, PolDedCodeBLD, AccDedCodeBLD)?

This makes sense but it's obviously a major change and so I will need to highlight this to all major vendors and users. If this goes ahead we may need to delay the release of OED v4 a bit longer to honour the three month notice. The release date would go from 6th Jan back a few weeks towards end Jan.

[johcarter]

Would you also update TIV fields, so
BuildingTIV becomes BLDTIV
as well as
LocDed1Building becoming LocDedBLD?

I like that the ods conversion tool will allow people to continue using the v3 field names if they want to, as this will make v4 adoption easier for property users.

[PaulLDJones]

I agree with Joh, the TIV fields should also follow the same naming convention as the terms fields if we are making such a major change

[aiste-kalinauskaite]

As we discussed on our recent call, I wanted to reiterate my strong advice against implementing the proposed change. This change would be highly disruptive for all parties involved, including our clients, model vendors, and Nasdaq, and it offers very little to no benefit in return.

If you were to go ahead with this change, model vendors would be required to support two different formats within their models, necessitating different headers and sets of testing files. Our clients would need to be extra cautious about which models support which versions. Additionally, if they use multiple models that require different OED versions, they would have to prepare separate sets of input files for the same data and invest additional time to prepare OED v4 files. The data conversion processes would need to updated and have to support several versions at the same time.

From our side, the validation process would become significantly more complex, increasing the likelihood of bugs. We would also need to prepare a new set of test files and deal with the operational headache of running OED2, OED3, and OED4 in parallel for some time.

A more efficient solution would be to align the cyber names to match the logic currently used for property, without affecting the property itself. For example, using terms like 7NonPropertyBI, 8CBI, etc., would be a better approach.

[jones-matt]

I agree with Aiste - I think this is a very significant and disruptive change for seemingly very little benefit and advise against it.