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

RI Scope file filters #1454

Closed
benhayes21 opened this issue Feb 27, 2024 · 4 comments · Fixed by #1505
Closed

RI Scope file filters #1454

benhayes21 opened this issue Feb 27, 2024 · 4 comments · Fixed by #1505
Assignees
Labels
enhancement New feature or request production
Milestone

Comments

@benhayes21
Copy link
Contributor

Issue Description

Enhancement - add functionality to support LOB, Country and Cedent filtering in RI Scope file

Currently oasis only allows filtering on Port, Acc and Loc Number for RI terms (and loc group?), but there is a requirement to include all filters in the RI Scope file.

  • LOB should map to LOB in Acc file
  • CountryCode should map to CountryCode in Loc file
  • CedentName should map to CedentName in Acc file

Open questions:

  • Additional fields in RI Scope to be discussed.
  • Are these fields used in isolation, or in combination with Port, Acc, etc?
  • Do we need to support combinations (e.g. LOB and Country) which could span two input files?
@johcarter
Copy link
Contributor

More detail copied from #148

Implemented filters:
PortNumber
PortNumber, AccNumber
PortNumber, AccNumber, PolNumber
PortNumber, AccNumber, LocNumber

To do:
LocGroup
ReinsTag
CountryCode
CedantName
ProducerName
LOB

The above fields are used to 'scope' treaties, which means to specify which subset of locations in the location file the reinsurance contract should apply to, with reference to the matching fields and values found in oed location and account.

LocGroup, ReinsTag and CountryCode are found in the location file and filtering is applied to locations, whereas CedantName, ProducerName, LOB are found in the account file and filtering is applied to accounts (and all locations under the account meeting the criteria will be in scope of the treaty).

The 'to do' filter fields above may all be used individually as filters, independently of PortNumber, AccNumber, LocNumber, PolNumber. LocGroup may be specified without reference to a PortNumber and AccNumber. (This is different to LocNumber which must also have PortNumber and AccNumber specified because LocNumber is not unique to a Portfolio and Account. LocGroup is assumed to be unique across portfolios and accounts)

All scope filter fields may be used in combination.

The use of multiple scope fields within a row in ri scope are interpreted as AND logical statements

Example: say LocGroup and PortNumber were both specified in one row for ReinsNumber=1, then only the locations with both the LocGroup specified value and the PortNumber specified value would be in scope of the treaty. A location must meet all conditions to be in scope.
The use of multiple scope fields across multiple rows in ri scope for the same ReinsNumber are interpreted as OR logical statements to define treaty scope.

Example: say LocGroup was specified in the first row for ReinsNumber=1, and PortNumber and CountryCode was specified in the second row for ReinsNumber=1, then all locations meeting either the LocGroup criteria OR the PortNumber AND CountryCode criteria are under the scope of the treaty. A location must meet the conditions of at least one row to be in scope.

Final note

How a treaty is scoped may be unrelated to the RiskLevel specified for the treaty. For example, a Per Risk treaty with RiskLevel = LOC does not have to have each LocNumber listed in scope on separate rows. The RiskLevel only indicates how risk attachment/limits will be applied to the losses in scope. (The exception is ReinsType=SS where each risk ,as defined by RiskLevel, must have a PercentCeded specified in the scope file with one 'Risk' on each row.)

@johcarter
Copy link
Contributor

@benhayes21 benhayes21 assigned benhayes21 and unassigned johcarter Feb 28, 2024
@aiste-kalinauskaite
Copy link

What Joh's specified is well defined, but I would like to clarify this point: "LocGroup is assumed to be unique across portfolios and accounts", as when I read it I find it can be ambiguous. LocGroup values would be repeated, i.e. the same value, say 'LocGroup1! would appear on multiple rows in loc file. Also, some rows can be blank in LocGroup field. It's just another field to group multiple locations in a group and allowing to filter the data in the easiest way possible. If several locations are tagged with the same LocGroup, say "LocGroup1", then it does not matter if they come from the same account or even the same portfolio, they all should be filtered for the reinsurance scope purposes.

Any filtering field (LocGroup, ReinsTag, CountryCode, CedantName, ProducerName, LOB) can have blanks on some rows in acc or loc file, so the logic should be able to handle this.

Any of the fields can be used in conjunction with one another, whether the field sits in acc or loc file. So you can easily get reinsurance scope specified as, say CedantName AND CountryCode or any other combination.

There is no limit in how many filtering fields are selected on one row, so in theory, you can end up with something like PortNumber AND LocGroup AND ReinsTag AND CountryCode AND CedantName AND ProducerName AND LOB. It's quite unlikely, but do not limit the logic in how many fields can be used.

@aiste-kalinauskaite
Copy link

Comments on the input files:

  • add combinations of several fields in order to test.
  • currently most fields has a unique value per row, which in reality would not be the case. In reality, most will behave like LOB is specified, i.e. the same value will occur multiple times.
  • add blanks for each field on some rows

@benhayes21 benhayes21 assigned sstruzik and unassigned benhayes21 Mar 20, 2024
@sstruzik sstruzik linked a pull request May 16, 2024 that will close this issue
@awsbuild awsbuild added this to the 2.3.5 milestone May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request production
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

5 participants