OasisLMF / ODS_OpenExposureData

Open data standards curated by Oasis.
61 stars 8 forks source link

[Property] Clarify relationship between "required field" and "blanks allowed" in OED Spec #181

Open benhayes21 opened 5 months ago

benhayes21 commented 5 months ago

Description

It has been suggested that having both "required field" and "blanks allowed" columns in the OED spec is counter intuitive, confusing and can lead to different interpretations of the specification.

Reasons for change

Validation software can make inferences about what the data should look like, which can be different between applications. Oasis itself applies logic to, say, required fields that are blank (where it applies the default value).

Ideally the spec should be clear enough that inferences don't need to be made. It's proposed that all required fields should not allow blanks, and all optional fields should allow blanks. But then the question is whether we need two columns in the specification

Required fields not allowing blanks should not need a default value (because they will always be there)

Scope of change

- [X ] Specification - [ ] Location File - [ ] Accounts File - [ ] Reinsurance Scope - [ ] Reinsurance Info ## Impact of change Changing the specification to have only one column will cause validation software that uses the specification to break. Aligning the logic so that all required fields do not allow blanks (and vice versa) will not break the validation but previously valid OED files might no longer be valid. Fields to be discussed
johcarter commented 4 months ago

As discussed, this would be a breaking change and can be considered for OED v4. In particular;

Location file: Required TIV fields (BuildingTIV, ContentsTIV, BITIV) must be populated with 0's if no value is given. They will no longer be allowed to be blank. As an optional field, OtherTIV would continue to be allowed to be blank.

Reinsurance info file: RiskLevel (required field) will not allowed to be blank. Currently a blank means that there are no risk terms to apply, which is valid for some Reinsurance Types. We would need to introduce a non-blank value meaning no risk terms. e.g. 'NRT'. (char(3)) This would replace blank in the list in 'OtherValues'.

LocPopNumber is the only optional field which may not be blank. For consistency with all the other optional fields, this would be relaxed to allow blanks, with a default value specified (0?)

johcarter commented 4 months ago

Follow up proposal:

*RiskLevel only needs to be specified if the reinsurance files contain ReinsType = Surplus Share (CededPercent is present), or there are risk terms in the info file (RiskAttachment or RiskLimit is present). If none of these three fields are present, then there are no risk level terms and RiskLevel can be assumed to be blank for all contracts.

The end result will be a cleaner spec and no breaking changes other than the format of the OED specification file.

It also clarifies the relationship between RiskLevel and RiskAttachment, RiskLimit and CededPercent for reinsurance.

Note 1: TIV fields are generally not required for broader use cases of OED, e.g. development / humanitarian sector. At least one TIV field is required for catastrophe modelling of property (i.e Oasis use cases), but this can be added as an Oasis-specific validation rule on top of OED validation.

Note 2: the specification file will change in OED v4 anyway due to the integration of Cyber and Liability fields.

benhayes21 commented 4 months ago

I think the proposals look good. It should be much cleaner and less liable to interpretation.

johcarter commented 4 months ago

Final proposal following TWG call this morning

Outstanding: Questions raised on LocPopNumber and whether it is a necessary field so this will be tackled in a separate issue

FYI @benhayes21 @MattDonovan82 @aiste-kalinauskaite

johcarter commented 3 months ago

Conditionally required tab codes

aiste-kalinauskaite commented 1 month ago

Latest Joh's proposal from May 23 looks fine.