Proposed format of OED v4 spec for multiple classes for review

[johcarter]

Issue Description

@OasisLMF/oasisdevteam Could you consider the proposed format of the OED v4 excel spec using the attached sample and highlight the implications for validation in ODS tools? Any suggestions for improvement and to minimise disruption to property account file validation?

Changes compared with OED v3 'OED Input Fields':

• Addition of columns for different classes of business: Property, Cyber and Liability (cols L, M N)
• Addition of new fields which relate only to Cyber or Liability or both.
• Addition of duplicate fields which are loc fields for property but acc fields for Cyber and Liability (e.g. CountryCode, StreetAddress, PostalCode)

Explanation:
The proposal for OED v4 is the three separate specifications will be integrated into one file, resulting in not one but three variants of account file, one for each of these classes of business. Each class has a different set of fields (including different required fields) as well as common fields.

The priority is to keep validation of property account files working with the new spec format (ignoring Cyber and Liability required fields), but be able to support Cyber and Liability account files in future.

Some questions:
Is the change to the table format machine readable enough for ODS tools or is there a better format?
How do we recognise what class of business the account file contains in order to validate against the correct fields?

A few options are;

• In ODS tools have different variants of 'account' file for each class of business. rather than just one 'account' file which is for property, we have account_prop, account_cyb, account_liab and then we associate the input file with the correct account file parameter and validate against the relevant subset of fields.
• keep one account file but add a new account data field such as 'OEDClass' which specifies which class the data relates to in the account file so that it can be validated against the correct subset of fields.

Sample file attached, thanks!
OpenExposureData_Spec_sample.xlsx

[sstruzik]

I would like to propose a different perspective and move the 'cyber account' concept to the location file.
my reasoning is as fellow, historically, we use loc for gul and loc + acc for gul + fm.
I can guess the naming account is better for cyber but it seems to me that they are actually "oed location" because they are an entity that can have a catrisk with a certain value at risk. oed Account, on the other end, are insurance entity with insurance terms and not catrisk.
If i look at the new fields with this in mind,
CountryCode, StreetAddress, PostalCode, City are "area peril" information and stay in loc (no duplicate)
AnnualRevenue is akin to the tivs we already have in loc, it can be a new coverage type
AnnualRevenueCurrency is not needed, we can use loc currency
I'm not sure if those CoverageClassDescription, CoverageTerritory, DefenceCost, are insurance terms or risk modifier terms but that can decide on where they should be.
with this new approach, we have less change in OED and also less change to make in oasislmf.
For example, for the key server at the moment we only pass the loc file, but if country code is needed for the area peril, we will need to change that
Same for the gul input generation, AnnualRevenue seems to be needed.
I don't have the complete picture on what a cyber exposure would look like but functionally I think moving what looks like a risk information column to loc is preferale

[johcarter]

I'm generally supportive of risk characteristics being kept in the location file as you suggest, and keeping the account file more neutral. The main risk characteristics for cyber, for example, are the country of domicile/headquarters, the industry sector, and the annual revenue. There are a lot more fields to integrate than in the attached which is just a small sample. Lets work through them and decide which file each field belongs in to be as consistent as possible with the structure for property.