search

OasisLMF / ReinsuranceTestTool

Test tool for new reinsurance functionality.
BSD 3-Clause "New" or "Revised" License
3 stars 1 forks source link

Layer logic #41

Closed johcarter closed 5 years ago

johcarter commented 6 years ago

Say there are multiple reinsurance contracts in the info file. Here are some scenarios;

CAT XL

  1. 101 and 102 are layers 1 and 2 in inuring priority 1, 201 is layer 1 in inuring priority 2. ReinsNumber,ReinsLayerNumber,InuringPriority,ReinsType, PlacementPercent, TreatyPercent 1,101,1,CAT XL,1.0,1.0 2,102,1,CAT XL,1.0,1.0 3,201,2,CAT XL,1.0,1.0

  2. 1/101 and 2/101 are layers 1 and 2 in inuring priority 1, 201 is layer 1 in inuring priority 2. It would be modelled identically to the first scenario. Because ReinsLayerInfo is for info, this could happen. ReinsNumber,ReinsLayerNumber,InuringPriority,ReinsType, PlacementPercent, TreatyPercent 1,101,1,CAT XL,1.0,1.0 2,101,1,CAT XL,1.0,1.0 3,201,2,CAT XL,1.0,1.0

  3. 101 is the same layer ceded to two reinsurers. In this version, we would ignore duplicate and have 1 layer for 101 at inuring priority 1. 201 is layer 1 in inuring priority 2. ReinsNumber,ReinsLayerNumber,InuringPriority,ReinsType,PlacementPercent, TreatyPercent 1,101,1,CAT XL,0.9,0.75 1,101,1,CAT XL,0.9,0.25 2,201,2,CAT XL,1.0, 1.0 This could also happen in theory for any treaty, ie Surplus Share, Quota Share, Per risk.

FAC

  1. each record is a grouping to the risk level. 1 layer only, regardless of the number of records. ReinsNumber,ReinsLayerNumber,InuringPriority,ReinsType 1,101,1,FAC 2,101,1,FAC 3,101,1,FAC

  2. should be treated same as 4. Ignore LayerNumber ReinsNumber,ReinsLayerNumber,InuringPriority,ReinsType 1,101,1,FAC 2,102,1,FAC 3,103,1,FAC

Surplus Share

  1. In this scenario you would create a layer for 101 and layer for 102. however the RiskLevel in scope must be consistent between the two layers (the aggregation to risk level must be common to both layers). The Risk filters can be different within a consistent RiskLevel. ReinsNumber,ReinsLayerNumber,InuringPriority,ReinsType 1,101,1,SS 2,102,1,SS

  2. Same as 6 ReinsNumber,ReinsLayerNumber,InuringPriority,ReinsType 1,101,1,SS 2,101,1,SS

Quota Share

  1. 101 and 102 are layers 1 and 2 at inuring priority 1. ReinsNumber,ReinsLayerNumber,InuringPriority,ReinsType 1,101,1,QS 2,102,1,QS

  2. 1/101 and 2/101 are layers 1 and 2 at inuring priority 1. ReinsNumber,ReinsLayerNumber,InuringPriority,ReinsType 1,101,1,QS 2,101,1,QS

Per Risk

  1. 1/101 and 2/101 are layers 1 and 2 at inuring priority 1. ReinsNumber,ReinsLayerNumber,InuringPriority,ReinsType 1,101,1,PR 2,101,1,PR

  2. 101 and 102 are layers 1 and 2 at inuring priority 1. ReinsNumber,ReinsLayerNumber,InuringPriority,ReinsType 1,101,1,PR 2,102,1,PR

It appears that we can't rely on ReinsLayerNumber to determine whether to increment layer_id. We can decide on the basis of the reinsurance number, type and inuring priority. Fac: For multiple distinct Reinsurance numbers with the same inuring priority, do not increment layers. (1 layer) CAT XL, PR, SS, QS: For multiple distinct Reinsurance numbers with the same inuring priority, do increment layers.

The issue is that when we use layers, we must have a consistent RiskLevel in scope between the two treaties, because they must have the same aggregation basis. Imagine you had two quota shares at the same inuring level, and one used RiskLevel Policy and the other Account. We can't model this because the aggregation basis is different. We could only inure one treaty to the benefit of the other in this scenario.

In terms of filtering by account, policy or location (to define what risks each treaty covers) this could still work using layers if they have a consistent RiskLevel. so only use filters on one of account, policy, location.

@mpinkerton-oasis @sambles any thoughts?

mpinkerton-oasis commented 5 years ago

Closing - old