Risk Objects

Risk objects – in the contract also called insured interests – are the items and persons to which the insured risk relates: the vehicle in motor insurance, the building in homeowner’s insurance, the insured person in accident or life insurance. They carry the risk characteristics, i.e. the properties that determine the probability of occurrence and the amount of loss and thus help to determine the premium: the engine power in kW of a vehicle, the type of construction and the living space of a building, the BMI or the occupation of a person.

Risk objects stand next to the instance tree (see Objects and Product Tree and Instance Tree): they exist independently of the individual component, are referenced by the components and are included in validation and calculation.

A common base risk object

All risk objects are derived from an abstract base risk object. It never occurs in a contract itself, just as the product node never occurs in the product tree; but it gives all risk objects a common shape: every risk object has a kind, carries risk characteristics and can be referenced by components. The common kinds:

Kind Typical risk characteristics Typical lines of business

Vehicle

Engine power in kW, list price, extras, first registration, licence plate

Motor liability, casco, passenger accident

Risk address

Location, natural hazard zone; carries buildings and contents

Homeowner’s, household, commercial property

Building

Type of construction, year of construction, living space, use

Homeowner’s, fire, water damage

Household (contents)

Sum insured, living space, security devices

Household

Person

BMI, occupation, smoker status, leisure risks

Accident, life, health

For persons, risk characteristics and personal data are kept apart: the risk object "insured person" carries the characteristics that describe the risk and refers to the personal data – name, date of birth, address – which also occur in other roles, for instance as policyholder (see Persons and Roles).

The common shape and the common kinds belong to the vocabulary of risk objects (risk:) in the foundation layer; what a line of business or a country specifies in addition is added by the vocabularies of those layers (see Vocabulary Layers). The base risk object is risk:RiskObject; the kinds are risk:Vehicle (vehicle, also a schema:Vehicle), risk:RiskAddress, risk:Building, risk:Household and risk:InsuredPerson, whose personal data risk:person gives as a schema:Person.

A shape describes the risk characteristics of a kind, for the vehicle risk:VehicleShape. Where Schema.org has a fitting term, it uses that term, otherwise one of its own from risk::

Characteristic Term Datatype Required

Registration district

atmotor:registrationDistrict

entry of the code list atmotor:RegistrationDistrict

yes (Austria)

Licence plate

risk:licencePlate

text: plate code, hyphen, number

no

Brand

schema:brand

text

no

Model

schema:model

text

no

Year of manufacture

schema:productionDate

year

no

First registration

risk:firstRegistration

date

no

Engine power in kW

risk:enginePower

integer from 1

yes

List price in euro

risk:listPrice

decimal from 0

yes

Extras in euro

risk:extrasPrice

decimal from 0

yes

Every characteristic of the shape carries a name and an order; a client builds its entry form from them. The characteristics of the other kinds are specified by the lines of business that insure them. The name under which a vehicle appears in the draft is given by the insurer as rdfs:label at the object: brand, model and year of manufacture ("Skoda Octavia (2021)"), not the licence plate, because under an interchangeable plate up to three vehicles share the same plate; only without these details does the licence plate name the vehicle.

Registration District and Licence Plate in Austria

In Austria the premium of the motor liability depends on the registration district, whose plate code the licence plate carries ("W" for Vienna, "GU" for Graz-Umgebung). The registration district is therefore a mandatory characteristic of the vehicle; the licence plate itself is not, because it may still be missing when the application is made: the vehicle is registered with the insurance confirmation only after the application. Neither is laid down by risk:VehicleShape but by a supplementary shape of the country-specific layer, atmotor:VehicleShape (Vocabulary Layers): risk: applies throughout Europe, the obligation to name the registration district is national law. The insurer delivers both shapes together; a client builds one form from both.

The registration districts are a code list (atmotor:RegistrationDistrict): per entry the plate code, the name, the federal state (with its ISO 3166-2 code) and the kind – district, statutory city or branch office of a district authority. Dissolved districts stay in the list with their end date and successors, so that existing plates are recognised, but are not offered for selection. The shape names the code list with sh:class and the inquiry at which a client fetches the entries with bc:valuesFrom (GET …/codelists/registration-districts, with ETag for conditional reading); bc:code and bc:groupBy tell it which characteristic carries the short code and how to group the list. If both licence plate and registration district are given, the shape checks that the plate code matches the district; the code of a dissolved district is admissible if the chosen district is its successor.

Vehicle templates of the insurer

The broker does not have to type brand, type, power and list price of a vehicle by hand if the insurer knows common vehicles: it offers vehicle templates (risk:VehicleTemplate), and the client suggests brands and types with power and list price. Choosing a template prefills brand, type, power and list price of the form; power and list price stay editable, and a vehicle that the catalogue does not know is entered as usual. Brand and type remain free text.

The templates are not knowledge of the standard but of the individual insurer: which brands, which types, which prices. The standard only defines how an insurer offers them:

  • A template has the same characteristics as the vehicle – schema:brand, schema:model, risk:enginePower, risk:listPrice – and optionally the price date risk:priceDate. Because the paths agree, a client copies every characteristic of the chosen template into the field with the same sh:path; there is no mapping table.

  • A shape in the insurer’s catalogue that targets risk:Vehicle names at the characteristic schema:model the class of the templates (bc:templateClass) and the characteristic they are grouped by (bc:groupBy with schema:brand). In the answer that names the step createRiskObject, the same place carries bc:templatesFrom with the address of the inquiry.

  • The inquiry (GET …/templates/vehicles, with ETag for conditional reading) delivers all templates of the catalogue; the client filters by brand.

The vehicle does not refer to the template. The template is a suggestion; after copying, the value belongs to the vehicle, and it is checked against the shapes like any other. An insurer without templates names no class, and its form stays as it is.

List of risk objects and references from the components

An instance – a calculation, an application, a contract – keeps the list of its risk objects. The components of the instance tree refer to entries of this list; the reference is directed and starts at the component. A component can have no, one or several references; typically a component refers only to risk objects of one kind. The same risk object can be referenced by several components, for instance a vehicle by the liability and by the casco.

risk-objects-list-and-references

The list makes visible what is insured, even when several components concern the same object; every object is captured once and validated once. In the instance, i:hasRiskObject keeps the list, and i:riskObject is the reference of an instance node – the root included – to an entry of the list or to a part of an entry.

Applying along the tree

A component without a reference of its own relates to the risk objects of its nearest ancestor that has a reference. In the figure above, both vehicles of the root apply to the liability and the passenger accident, vehicle 2 of the full casco applies to the basic cover. Validation and calculation read these effective risk objects; a reference of its own is only needed where a component relates to fewer or other objects than its parent component.

Nested risk objects

Risk objects can themselves contain risk objects. A risk address, for instance, carries several buildings, a building its contents. Depending on the cover, a component refers to the whole address or only to a sub-object: the property owner’s liability to the address, the fire insurance to a building, the household insurance to the contents of a flat.

risk-objects-nested

Risk object or attributes at the component

If an insured interest is referenced by only one component, the cardinalities would not require an object of its own: the characteristics could also be attributes of the component. Nevertheless a risk object is often used in this case too, because a fixed definition across products already exists for the interest – for the insured person as well as for the vehicle. The broker then captures a vehicle with the same characteristics in every product, and the insurer validates it by the same rules.

Rules for the references

The foundation layer specifies that a component can refer to risk objects of the instance and deliberately leaves open which components do so, to which kinds and how many. These rules depend on line of business, country and product and cannot be stated generally for all of them. They therefore belong to the vocabularies of the lines of business and countries and to the product knowledge of the insurer, which a client receives at runtime.

An example from Austria, motor: a contract contains at most three vehicles (interchangeable licence plates). Every component can relate to one of these vehicles. Sub-components usually have no reference of their own; then what is specified at the parent component applies.

Risk object rule at the product node

The product knowledge specifies the references per product node with a risk object rule (p:riskObjectRule):

Item Meaning

Kind (p:riskObjectClass)

To which kind of risk objects the components of this product node refer, e.g. risk:Vehicle.

Minimum and maximum (p:minRiskObjects, p:maxRiskObjects)

How many references of its own a component has to objects of this kind.

Among the objects of the parent component (p:withinParentRiskObjects)

The targets must be among the effective risk objects of the parent component: the component chooses from what applies to its parent component.

A product node without a risk object rule has no references of its own; the objects of the parent component apply to its components. The validation rules of the standard report a component with too few or too many references, a reference to an object of the wrong kind, outside the list or outside the objects of the parent component, and a reference of its own without a risk object rule. Whatever a rule requires beyond that, the insurer validates with shapes of its own for its catalogue.

The motor products of the example insurers and of the sample catalogue of the standard follow this pattern:

Product node Kind Number Target

Product (root)

vehicle

1 to 3

from the list

Full casco, partial casco

vehicle

exactly 1

one of the vehicles of the root

Liability, passenger accident, legal expenses, assistance and all sub-components

–

–

the vehicles of the parent component apply

In addition, every motor catalogue validates with a shape of its own that every vehicle has at most one casco component – full casco or partial casco, not both and not twice. The limit of three vehicles is a rule of the product here; as a specification for Austria it belongs to the country vocabulary of the line of business.

Validation and calculation

Risk objects are part of the product configuration. The insurer validates their characteristics – datatype, required, range of values – and the references: if a component lacks a risk object it needs, the validation report says so at the component, and the business object is incomplete. The premium calculation reads the risk characteristics of the objects the components refer to.

A client without prior knowledge learns from the insurer’s response which components expect a risk object of which kind and which characteristics a risk object of this kind has, and builds its data entry from that – just as it builds the input fields of the attributes from their permitted values (see Solution Approach).

Editing risk objects in the draft

If the insurer keeps the calculation as a draft ("draft at the server"), a client edits the risk objects with three operations:

  • createRiskObject creates a risk object with kind and characteristics in the list. The insurer assigns its identifier and assigns it automatically: to every component whose risk object rule names the kind and still has room, the root first; a component with p:withinParentRiskObjects gets it only if it applies to its parent component and no sibling component of the same kind has it already. A newly included component likewise gets an object that is still free.

  • assignRiskObject replaces the references of its own of a component by the chosen objects; this is how the user changes any automatic assignment. Without chosen objects the parent component applies again. If a vehicle leaves the root, the casco component that referred to it loses it as well.

  • removeRiskObject removes a risk object with its parts and all references to it; the components concerned are reported as incomplete afterwards.

Besides the draft, every response contains the list of risk objects with their characteristics; at every component with a risk object rule the rule with the number of its own references and the objects that can be chosen now; at every component without a reference of its own the effective objects and the ancestor they apply from; and for every kind that can still be created the shape with all characteristics. An incomplete reference – "Fahrzeug fehlt" (vehicle missing) at the root or at the full casco – is a state of the draft: it is stored and reported, and "calculate" is not a next step until then.