New ReinsType - Stop Loss

[johcarter]

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:

• Confirm the representation above of how Stop Loss treaties work is correct?
• Percent of premium aggregate attachment and limit: are these the only extra terms needed for a stop loss treaty?
• Is PolGrossPremium the correct premium field to apply the 'percent terms' to?
• What is the preferred implementation, option 1 or 2 (or alternative suggested)?
• Valid value range for percent of premium - can this value exceed 1 in practice ? e.g. A value of 1.5 could mean 150% of premium?

Reasons for change

Adding this issue in line with the proposal
OasisLMF/ODS_OpenResultsData#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
• 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]

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]

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).