Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple FAC example produces wrong results #20

Open
johcarter opened this issue Aug 2, 2018 · 4 comments
Open

Multiple FAC example produces wrong results #20

johcarter opened this issue Aug 2, 2018 · 4 comments
Labels
question Further information is requested

Comments

@johcarter
Copy link
Contributor

Matt Jones:
(Two location level fac contracts (for both locations in policy 1) and then one policy level fac (at the same inuring level and covering the same locations (in account 1, policy 1) as the location level fac. And then a separate account level Fac contract covering account number 2.)

For the Account level Fac the PolicyNumber is set to 1, but it should be NaN (there is no PolicyNumber 1 in Account 2).

I think there is an issue when we have two contracts that are at the same inuring priority (and so do not inure to the benefit of each other) – the location contracts seem to inure to the benefit of the policy fac here despite the inuring level being the same:

I experimented with some changes to see how the fac policies interact at the same inuring level:
• Changed the two location facs to RiskLimit= 99 (RiskAttachment = 0 still) (ie 99 xs 0)
• Changed the RiskAttachment of the policy fac to 190, leaving the RiskLimit = 10 (ie 10 xs 190) .
Given that the two location insured losses are 100 each (200 to the Policy) I would expect a recovery of 99 from each location level fac and a recovery of 10 from the policy level fac. Total recovery = 99+99+10 = 208. However the insured loss is only 200 so the system should prevent an over recovery and show a net loss of zero on locations 1 and 2 when viewing at the policy level (ie the impacts of location and policy level fac).

This isn’t what happens – instead the Policy level fac is not producing any recoveries – it seems to me it is acting like the location level fac inures to the benefit of the policy level fac (even though the inuring priority is the same and so it should not be doing this – rather the Policy level fac should be acting independently of the location level fac with a check that the net losses at policy level are never zero).

I tried experimenting by changing the inuring level of the Pol fac contract to 2, but this caused the script to crash at step 8 (screen shot at end of email)
error

@johcarter johcarter added the bug Something isn't working label Aug 2, 2018
@johcarter johcarter self-assigned this Aug 2, 2018
@sambles
Copy link
Contributor

sambles commented Aug 6, 2018

Did the crash happen on the master branch? it seems to run in dev

@johcarter
Copy link
Contributor Author

Oasis can't handle an independent calculation of two contracts (eg loc and policy fac) covering the same location because of the simple heirarchy constraint in the design. Instead location inures to the benefit of policy which inures to the benefit of account.

@johcarter johcarter removed their assignment Aug 10, 2018
@aiste-kalinauskaite
Copy link

Is this an issue on both of the scenarios or just one of them?

2 policies each have 2 locations: Policy 1 has locations 1 and 2 and policy 2 has locations 3 and 4.

Scenario 1
LOC FAC applies for locations 1 and 2 (two separate fac contracts) with inuring priority 1
POL FAC applies for policy 1 with inuring priority 1

Scenario 2
LOC FAC applies for locations 1 and 2 (two separate fac contracts) with inuring priority 1
POL FAC applies for policy 2 with inuring priority 1

@mpinkerton-oasis mpinkerton-oasis added this to the R1 milestone Aug 13, 2018
@sambles sambles added question Further information is requested and removed bug Something isn't working labels Aug 16, 2018
@sambles sambles removed this from the R1 milestone Aug 16, 2018
@mpinkerton-oasis
Copy link

@johcarter can this be closed? Seems quite old.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants