The Intelligent Quarterly from the publishers of The Insurance Insider

Spring 2012

Search archive

Advanced search

The specialty classes vary in risk structure from one class to the next, which means an integrated risk model that can easily process insurance, reinsurance and retrocession placements is essential and would be the first requirement for any framework.

Given that data structure and volume also vary considerably, the next requirement calls for robust data capture and management. Once data capture and risk structure for each class have been addressed the third requirement is for an internal engine to process events and scale to the needs of each class or multiple classes.

Finally, any framework should be open to user interaction, whether it is for user parameterisation of event sets or to integrate within existing processing streams.

Two main coverage types dominate the specialty classes - physical damage and pure liability.

The physical damage specialty classes are easy to identify as there is an actual object around which the (re)insurance is placed, with various combinations of property damage, first party liability and third party liability coverage. Examples include aviation, marine, cargo, energy and specialty property; with the subject of each being the airline, vessel, shipment, rig and building, respectively.

For each subject a number of risk characteristics can be captured, usually a combination of third party data and proprietary data, either for segmentation or reporting purposes or for use when creating event tables. For an enterprise solution the software does not need to know the nature of the subject, only that it exists and may have risk transfer agreements attached to the various parties that have an interest in it.

The pure liability classes are less easy to identify as there is an entity around which the (re)insurance is placed, with various types of legal liability that the entity may be responsible for. Examples include professional indemnity, crime, directors' and officers' and general liability. By market convention, these are often classified according to the entity they attach to, such as financial institutions, pharmaceuticals and small and medium sized enterprises.

Although more difficult to define, once the subjects have been established the (re)insurance relationships are generally easier to model as each entity has a 100 percent insurable interest in itself, unlike the physical damage classes where the situation is not always that simple.

Any risk model needs to recognise the similarities and differences encountered between these two main coverage types and support the way each coverage type is applied in practice to a class of business. This suggests that the risk model must be rule-based so that appropriate logic can be applied to specific coverage type and class of business combinations.

One further complication is that the risk model also needs to support the method of placement for all risks that have been underwritten, whether on a direct, reinsurance or retrocession basis. Finally, the risk model needs to support the differences in data content and relationships between classes.

To ensure full support for the specialty classes the risk model must integrate all the underlying complexity discussed above.

Robust data capture
At the heart of good risk management is good data quality. Inevitably in the specialty classes, data quality will vary with the quality of data structure and volume in each class. Moreover, organisations have traditionally tended not to invest in electronic data validation, capture and management.

In my view it essential to invest in tools that ensure robust data capture and management, as this is the initial step to improved data quality, and therefore good risk management. Such tools should be template driven, have rules to handle data quality and include fuzzy matching capabilities to manage naming conventions.

Having established that robust data capture is essential, what data needs to be captured? To answer this, I would like to introduce four categories of data - reference, market, underlying and portfolio data, the content of which will vary across the specialty classes.
Reference data is all to do with coverage criteria, event definitions, geographic regions and analytical assumptions such as target loss ratio.

Market data captures currencies, rates of exchange, losses, the definition of the risk being insured or monitored - also known as subjects - and the companies that have a trading relationship with you.

Underlying data is industry exposure data that is normally supplied by third parties and defines the risk within a class in its raw form. For example, the details of an aircraft, satellite, ship, oil rig or financial institution and the relationship of that risk to the policy placement.

Portfolio data is defined as the collection of risks that have been underwritten over time, regardless of whether they are insurance, reinsurance or retrocession placements and the reinsurance programmes purchased to protect the portfolio.

Internal and scalable
To ensure consistent and timely analysis it is essential that the framework has an internal engine that can consistently process events regardless of the size and complexity of a portfolio. By analysis, I mean a pre-defined algorithm that serves a user request according to a particular collection of mathematical processes, which can be deterministic or stochastic.

Such an engine would see any analysis as a collection of events that need to be processed according to the pre-defined algorithm. It would also need to be database-driven to differentiate event processing that can be done in computer memory from database processing, which is done on computer disks.

A feature of the specialty classes is data volumes, which vary tremendously, requiring the framework's engine to scale with the demand placed on it. This is achievable as long as the engine is multi-threaded, that is to say that it utilises as many CPUs that are available on the computer (scale-up) or as many computers (scale-out) as possible.

Indeed, a multi-threaded engine would be ideally suited to the generation of a stochastic event set for both deals and portfolio pricing, as processing occurs in parallel rather than sequentially.

The net effect of this is that more complexity can be processed for a given time period than would be the case without, ensuring the time and therefore the cost of performing an analysis is optimised.

Open to user interaction
Given the variety and complexity inherent within the specialty classes, an open architecture would be more beneficial for flexible analytics than a closed architecture. Users would have the flexibility of being able to construct their own event sets and use the framework to process such events.
Furthermore, openness would promote more flexible pricing data, enable easy integration with existing application and processing streams, while also facilitating improved audit capabilities as the data can easily be accessed and interpreted.

In a competitive marketplace, using well-constructed architecture guards against commoditised pricing, as underwriter assumptions and corresponding event sets will differ. It allows companies to tailor their risk management process to their needs and to their understanding of the risk environments they operate in, ultimately improving their underwriting results and giving them a competitive advantage over their peers.

Suki Basi is managing director at risk management software and service company Russell Group