Exposure Schema

The foundational concept of the RDOS data model is the contract, which is a binding agreement between the insurance provider and insured customer. The RDOS allows contract expression through the Contract Definition Language (CDL). The ContractCDL table stores the CDL string. For more information about CDL, see Contract Definition Language Semantics and Detailed Contract Model Examples.

Tables to represent insurance contracts:

• Contract_Insurance—Extended from Contract to create the insurance contract record. For reinsurance contracts, use the Contract_Treaty table. The subject of a contract is a riskId or a scheduleId.
• InsuranceContractLayer and InsuranceContractTerm—Define the contract if you do not use CDL. For more information about the lossTypeCode and causeOfLossCodes in both of these tables, see Causes of Loss and Loss Types.
  • Contract Layers—Layers define the promise of payment.
  • Contract Terms—Contracts include two types of terms—deductible and sublimit—which reduce subject losses. Terms of a contract define their scope through a subject constraint (for example, contents losses to a certain location by hurricane, losses to a certain subschedule of locations by earthquake). Terms also typically have an amount (e.g., 10k USD, 2% RCV Covered) and perhaps some modifiers to their behavior (e.g., franchise deductible, aggregate sublimit). A contract can have as many deductibles and as many sublimits as needed.

Tables to represent treaties:

• Contract_Facultative and FacultativeCession—Define facultative contracts.
• PerRiskTreatySubject—Defines the portfolios that are the subjects of per risk treaties.
• Contract_Treaty—Creates the reinsurance contract record.
• TreatyLayer and TreatyReinstatements—Define the treaty if you do not use CDL.

Table applicable to all contracts:

• ContractDeclaration—Defines declarations for all contracts if you do not use CDL. Stores declarations per contract and per contract layer. Identifies each contract using the contractId field. Declarations act as metadata to aid search and filter, such as contractCedantCode, underwriterShortName, producerShortName, branchShortName, brokerShortName, and multiple legacyUserId and legacyUserTxt fields for free-form entry.

Contracts cover one or more risks, captured in the Risk table.

Each risk contains one or more risk items, which can be of multiple types, such as real property, contained property, time element, and population. Each of the sub-types is a separate risk item and together, a collection of risk items represent the risk associated with the contract.

When you have information about a group of buildings in aggregate, but do not have individual building level information, use the Risk.numberOfUnits field to indicate the number of individual risks that are represented by the aggregate risk.

Tables to represent risks and risk items:

• Address—Captures data about a real property risk item's geographic location, such as:
  • streetAddress—The building number and street
  • postalCode—The predominant postal code, such as 5-digit ZIP Code in the U.S.
  • cityName—City name
  • admin1—Administrative divisions are geographic divisions that vary by country. Admin1 represents large geographic divisions, such as states and provinces, such as state in the U.S.
  • countryCode and countryScheme—Store the code and scheme used for the code, such as ISO2N for US.
  • many more
• Population and PopulationShift—Capture data about human populations, such as for workers compensation analysis.
• RiskItem_ContainedProperty—Captures contents exposure.
• RiskItem_RealProperty—Captures building exposure and acts as a parent risk item for any RiskItem_ContainedProperty and RiskItem_TimeElement. Stores the following attributes that are often used to adjust the vulnerability of exposure for peril model analyses:
  • constructionSchemeName and constructionCode
  • occupancyschemeName and occupancyCode
  • floorArea
  • numberOfStories
  • yearBuilt
• RiskItem_TimeElement—Captures business interruption exposure.
• RealPropertyCharacteristics—Captures additional modifiers associated with a real property risk item. Refer to the documentation for specific peril models to know which modifiers are considered. The RiskItem tables in the Reference schema store the available modifier options.

The level of risk associated with risk items is the risk exposure, captured in the RiskExposure tabled. The insurableInterest field indicates to what extent the risk items are covered by the insuring party for different coverage types.

When multiple risks are associated with a contract, they are combined into a schedule, which allows the contract to apply the same terms and conditions to all the risks collectively, rather than listing each one individually. Schedules are captured in the Schedule table. The ScheduleRiskMap table maps risks to the schedules with which they are associated.

Like schedules, subschedules define a named collection of risks. They are an optional subset of the risks in a schedule that is covered by a contract. Use them in a contract to replace a list of risks when you want to define constraints on sublimits, deductibles, and covers. The SubscheduleRiskMap table maps risks to the subschedules with which they are associated.

A grouping of contracts is a portfolio, and portfolio records are captured in the Portfolio table. Contracts that comprise a portfolio are stored in the PortfolioMembership table. The portfolio may be based on geographical region, business unit, or some other criteria that makes sense within an organization.

For aggregate portfolios, the AggregatePortfolioMembership table captures aggregate geographic and financial information.

Define the metadata tags you want to use for portfolios in the PortfolioTag table.

Finance and accounting use the concept of positions to express how a result should be calculated and how it belongs to an organization. A structure is a container for these positions. RDOS expresses the position framework and captures the loss flow using Structure Definition Language (SDL).

Portfolios and SDLStructures are both structures. Structures contain positions. Portfolios implicitly define the positions they contain, such as Gross and Net Loss Pre-Cat. SDLStructures explicitly define the positions they contain, some of which can be cat treaties. SDLStructure positions can depend on Portfolio positions.

The SDLStructure table stores the SDL string. The StructurePositions table allows you to define structures without using SDL.

If you want to group primary contracts and associated portfolios, risks, and risk items, you can define an exposure set, stored in the ExposureSet table.

Geocoding is the process of translating an address to an exact location. It’s the foundation of catastrophe analytics, and its importance cannot be understated. Small differences in exposure location can mean large changes in loss, which impacts underwriting, capital management, and reinsurance purchasing.

RDOS provides numerous fields in the Address table that can be populated by geocoding engines. These fields capture detailed information about the geocoding process and about the exposure and its location.

The RDOS uses the following Address table fields to support two standards used to describe the geocoding resolution of a specific address:

• geoModelResolutionCode—Stores the 0-14 match levels used by many geocoding vendors to represent a range of geocoding resolutions, from high-resolution (parcel, building, street) to postal code, neighborhood, and district.

• ACORDResolutionCode—Stores the 99 match levels developed by the Association for Cooperative Operations Research and Development (ACORD).

The RDOS uses the following fields to provide a measure of geocoding accuracy and confidence:

• geocodingMatchConfidence—Stores the percentage confidence that applies to the achieved geocoding match. Different geocoding vendors use different approaches for determining confidence thresholds. Uncertainty and uncertaintyBuffer fields are also available.
• geocodingLocationCode—Provides additional accuracy measure for U.S. high-resolution geocoding.
• geocodingMatchCode—Stores codes from the geocoder to indicate portions of the input address that matched, did not match, or were modified during the geocoding process.

The following fields provide information about the geocoding data and vintage and an audit trail:

• geocodingDataSourceId—Identifies the source of the geocoding data.
• geoProductVersion—Identifies the data vintage and software version.
• isSubmittedAddress—Can provide an audit trail by indicating whether the address has been modified by the geocoder or whether the original submitted address is unchanged.
• geoCodedDate—Records the date the location was geocoded.

The Address table provides many detailed geography fields for user input or geocoder input, including:

• Globally unique GeoId fields for all address components
• CRESTA Zones 1-5
• Administrative divisions, levels 1-5, which are geographic divisions that vary by country. E.g., Admin1 represents State in the U.S. and Province in Canada.
• Building and parcel identifiers
• Points of interest

• Quadkey—Quadkeys uniquely identify map tiles at a particular level of detail. Map tiles optimize the performance of map retrieval and display.