[Property] MRI new codes

[IPE-Pierre]

Description

MRI is a property LOB in France Residential standing for MultiRisque Immeuble or All Risk "building"

It's for flats, there are 3 covers :

1. Renter covering Contents essentially
2. CoPropropriétaire as CoOwners for Flats covering mainly Building cover (and some contents) but up to a certain amount
3. CoPropriété as Group of Coowners covering mainly Common Areas / Roof and main building structure.

TO DATE WE MAPPED ALL EXPOSURE TO FOLLOWING CODE :

There is a unique Code while there massive heterogeneity of exposure also not covered by crossing Construction.

1. MONO vs MULTI : a contract covering a single block vs a contract covering several blocks sometimes more than 10.

Reasons for change

MULTI are indeed very high SI bringing very high loss

Scope of change

• [X ] Location File

Impact of change

NEW OCCUPANCY CODE FOR MULTI BLOCKS

[MattDonovan82]

@IPE-Pierre to avoid duplication, are you sure your requirements cannot be covered by the current occupancy codes - such as 1057 for "renter" and 1055 for "apartments/condo" and as you mentioned 1058 that you are already using?

Although adding new codes is fine in theory, these are specific to France and we don't want to start adding too many country-specific occupancy codes because of duplication and possible ambiguity.

Thoughts @johcarter @aiste-kalinauskaite @benhayes21 ?

[IPE-Pierre]

All other residential codes are used... It's really for MRI whether they are blocks of buildings or single unit. Not sure it's a french specific...

[MattDonovan82]

so how many new occ codes are you suggesting? @IPE-Pierre

[IPE-Pierre]

I think I could deal with adding one... The current would be maintained as single or small block the new one being for large or medium/large block

[MattDonovan82]

ok. As long as no current codes can support this, it shouldn't be a problem adding one new code.

[MattDonovan82]

any other comments here? @johcarter @benhayes21?

[johcarter]

Yes, could we have a detailed proposal please, with code and description as it should appear in the spec.

[MattDonovan82]

@IPE-Pierre can you please propose the additional field(s) here so we know what to include in the update?

[IPE-Pierre]

Hello That would results in a modifying 1058 as well

id : 1058
name : Single Unit Residential Apartment/Condo Asso, Common Areas
description : Common areas of a Single Unit Apartment/ Condominium that is shared with all the other residents, like the roof, elevator, basement, courtyards or walkways, pools, common gym or event space, parks etc.

id : new ID
name: Large or Multiple Unit Residential Apartment/Condo Asso, Common Areas
description : Common areas of a Large or Multiple Unit Apartment/ Condominium that is shared with all the other residents, like the roof, elevator, basement, courtyards or walkways, pools, common gym or event space, parks etc.

[MattDonovan82]

Hi @IPE-Pierre we are reluctant to modify existing codes as this will result in a 'major' update and be very disruptive. I think even modifying the descriptions would result in some disruption and potentially cause some confusion with other users between codes for similar single occupancy dwellings such as 1051 and 1055. Adding new codes are only 'minor' updates and not disruptive so this would be the preferred option at this stage.

I'm not sure your new suggested code is that different to the current 1058 for 'Residential Apartment/Condo Asso, Common Areas'. The description you propose above is very similar so I still question the need for this new code - are you sure MRI just cant fall within 1058?

Thoughts @johcarter ?

[johcarter]

Just a question for @IPE-Pierre to help me understand the reason for needing another code. I get that the Large/Multi-Unit would have higher TSI and loss, but higher loss would follow from entering a larger TIV in a modelling scenario. This on its own is not a reason for needing another code. Having different vulnerability functions, for example, would be a reason. Is this the case, or another reason why you need to differentiate between single unit and large/multi-unit?

[IPE-Pierre]

Replying all together.

@MattDonovan82 1058 is not a change, it's in a way staying where it's suppose to be ie a single unit common area. It's just clarifying that's it's deemed to single shared unit. No change.

@johcarter new code is for large or multiple buildings. Applying same vulnerability curve results is generating way to large losses because we are applying probability of loss and DR of a simple building on the compounds which can be more than 10 buildings in the same "address" . The new code of multiple large or complex is clearly to adjust with lower vulnerability curves.

[johcarter]

Thanks @IPE-Pierre I agree with both points

• The description update to 1058 is a clarification not a change in meaning
• A difference in vulnerability between single unit common areas and large/shared common areas is a good enough reason to add a new code.

We can implement this in OED v4

[aiste-kalinauskaite]

@IPE-Pierre @johcarter @MattDonovan82
I would like to check if this can't be covered by using NumberOfBuildings (=10) and IsAggregate (=0) columns with 1058 occupancy code to define multi-building cover? Of course, the TIVs would also indicate much larger values.

[johcarter]

I have given this some thought @aiste-kalinauskaite , and it sounds like there is a need to differentiate between vulnerability of large and small single-unit communal areas, not just multi-unit, which your suggestion wouldn't address.

I think there is a distinction also between multi-building sites represented by IsAggregate=0, and a multi-unit single building as in the new case, which I think means that it may not be appropriate to force a disaggregation by NumberOfBuildings as a way of dealing with it.

[stephenhutchingsjba]

This feels like a disruptive change, as it proposes adjusting 1058 to a new meaning and implementing a new code.

The current implementation is:
id: 1058
name: Residential Apartment/Condo Asso, Common Areas
description: Common areas of the Apartment/ Condominium that is shared with all the other residents, like the roof, elevator, basement, courtyards or walkways, pools, common gym or event space, parks etc.

We aren't convinced the proposed description for 1058 makes sense given the new intended use (shared areas within an apartment unit). It would also mean that all our models would need to be updated to use the new code not the 1058 code before they would support this ODS version.

It may have been that the intention was for 1058 to represent specifically single-unit common areas, but that hasn't previously been our understanding. We would prefer it if the single unit variation could adopt the new code and 1058 could remain for use as a general or multi-unit shared space, as we've already coded vulnerabilities with this understanding.

[IPE-Pierre]

Hello Stephen,

just to clarify things, 1058 is deemed to remain unchanged as multi-unit shared space.

Though it would be used for regular 1 Single Building.

The new code is to address multi buildings, blocks or huge building. New code is deemed for large / multi blocks multi-unit shared space.

[stephenhutchingsjba]

Hello Stephen,

just to clarify things, 1058 is deemed to remain unchanged as multi-unit shared space.

Though it would be used for regular 1 Single Building.

The new code is to address multi buildings, blocks or huge building. New code is deemed for large / multi blocks multi-unit shared space.

Pierre, thanks for the clarification, which I'll pass on and will reply back here if appropriate.

[aiste-kalinauskaite]

FYI @johcarter

I am pleased to see that this item has been removed from the OED v4 release, as it requires further discussion.

I am having difficulty understanding the necessity for an additional occupancy code. Specifically, why would a single building with multiple condos/apartments have a different vulnerability curve depending on whether it stands alone (MONO) or is part of a site with multiple such buildings (MULTI)? My understanding is that the vulnerability per building would remain the same in both scenarios.

As I mentioned previously, OED already includes fields, such as NumberOfBuildings and IsAggregate, to indicate more aggregate types of exposures. Wouldn't this be part of the disaggregation process employed by a model vendor to ensure that the same MULTI occupancy code (using the same vulnerability curve for MONO and for MULTI scenario) is handled correctly?

[philipoldham]

I'm following up from @stephenhutchingsjba post. @aiste-kalinauskaite what you mention is how we (JBA) already handle these cases. For example we use ranges of values from NumberOfStoreys in combination with OccupancyCode=1058 to split into vulnerability functions for low/mid/high rise blocks. The same can be done for NumberOfBuildings to indicate that there's multiple blocks.

Maybe is the problem that not all Oasis models can use vulnerability lookups in that way?

[aiste-kalinauskaite]

Many thanks for the extra detail @philipoldham . Your implementation is what I would think any model vendor would use.

My only follow up on your question would also be why would it be the case? Why would there be an issue for some Oasis models to use vulnerabilities in the way that you do? Certainly would be interesting to see what comes out of such discussion.

[IPE-Pierre]

Hello,

I think there are some misunderstanding here so I will start over :

The code 1058 is common area of regular building like this kind of structure :

For this matter it's ok and the vulnerability is coded as one per unit.

The problem arise from these kinda of structure taking like 10 units in one (a) :

or these kind of block structure of blocks :

why would a single building with multiple condos/apartments have a different vulnerability curve depending on whether it stands alone (MONO) or is part of a site with multiple such buildings (MULTI)? My understanding is that the vulnerability per building would remain the same in both scenarios.

=> indeed you are right though there are not correlated at all but independant in vulnerability for case (b). For case (a) it's clearly not the same vulnerability.

As I mentioned previously, OED already includes fields, such as NumberOfBuildings and IsAggregate, to indicate more aggregate types of exposures. Wouldn't this be part of the disaggregation process employed by a model vendor to ensure that the same MULTI occupancy code (using the same vulnerability curve for MONO and for MULTI scenario) is handled correctly?

=> case of B is tricky as they are insured altogether through a master policy usually covering several blocks and the problem lies in the fact that exposure wise, you know it's blocks but not exactly NumberofBuildings per block and it's not an aggregate per say as buildings have the same address. They are all located at the same address.