OasisLMF / ODS_OpenExposureData

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

New ReinsType - Stop Loss #164

Open johcarter opened 9 months ago

johcarter commented 9 months ago
## Description

Add a ReinsType to represent a Stop Loss Treaty, along with the ability to enter aggregate terms as decimals (options below).

A Stop Loss Treaty is an Aggregate Excess of Loss with attachment and limit expressed as a percentage of premium.

eg. AggAttachment = 0.75 means that as soon as aggregate losses exceed 75% of premium income, the treaty starts to pay out loss. Both AggAttachment and / or AggLimit could be expressed as a percentage of premium.

Options for implementation:

1) Use AggAttachment / AggLimit and enter decimals rather than monetary amounts. When the value is < 1, implicitly assume that it refers to percent of premium and multiply by the PolGrossPremium (the sum of this column for the risks under the scope of the SL treaty) to compute the monetary attachment threshold or limit.

When using ReinsType = AXL or =SL, AggAttachment and AggLimit should be used.

2) Introduce new fields into reins info to allow percent of premium attachment and limit to be entered for a stop loss

e.g. AggPctAttachment AggPctLimit

When using ReinsType = AXL, AggAttachment and AggLimit should be used When using ReinsType = SL, AggAttachment and AggLimit should be used for monetary terms, AggPctAttachment and AccPctLimit should be used for percent of premium terms.

Option 1 is less disruptive because no changes are needed to be made to existing fields, but Option 2 is clearer on how to enter the terms for each reins type.

Help wanted Some questions:

Reasons for change

Adding this issue in line with the proposal https://github.com/OasisLMF/ODS_OpenResultsData/issues/5 to include financial perspectives excluding Stop Loss, means that we need to formally identify a stop loss treaty as a type in OED and handles its financial terms. ## Scope of change - [ ] Location File - [ ] Accounts File - [ ] Reinsurance Scope - [X] Reinsurance Info ## Impact of change Validation software would have to be updated to allow the new value in the enumerated list, in order for ReinsType=SL to be used. Older OED files which don't use the new ReinsType or new fields (under option 2) would remain compatible after the change. ## Data type, default values, are blanks allowed, list valid values | **Field Name** | **Data type** | **Default values** | **Blanks allowed** | **Valid values** | |----------------------------|---------------- |---------------------|---------------------|-------------------| | ReinsType | string | enumerated list | No | Add 'SL' | | AggPctAttachment | float | 0 | Yes | [0,) | | AggPctLimit | float | 0 | Yes | [0,) |
aiste-kalinauskaite commented 8 months ago

Until we have more details on this type of reinsurance, this shouldn't be added in, as it's difficult to comment what the best structure should be when there are too many unknowns.

aiste-kalinauskaite commented 2 months ago

For any further consideration, all of the questions in the Description, plus the below should be answered first before any changes to OED to be considered:

  1. as already picked up by @johcarter - where will the premium information come from? PolGrossPremium represents just one policy or one policy layer, so would those need to be summed to calculate the values?
  2. should the new fields be added at all (or values below 1 represent percentages)? Could the monetary values be calculated and entered in AggAttachment and AggLimit fields? (I assume it will be % multiplied by a premium).
  3. if any changes are made to the OED, then Oasis LMF should also include the necessary calculations for the Stop Loss treaties to be modelled. Making a change to OED standard alone and not in the financial model is somewhat unnecessary. How would the loss calculations work for Stop Loss?

Comments on options: OED has been designed not to have implied assumptions (which is why we have types and codes for limits and deductibles, so that there is no guessing if it's a percentage or a value). So option 1 would clash with the logic behind the rest of OED. So it would need to be option 2, however, I am not yet convinced the change is needed at all (see question 2 above).