- Data Analytics
How Insurers can get started with high-performance pricing
Top 3 tips for Insurers to set up high performance pricing
How the aggregator makes rating expertise a must-have
Establishing proximity to potential new customers on high-reach portals has long been a complicated, complex undertaking - and has become an optimization discipline in its own right. Let's call it high performance pricing. It's high time for insurers to fully tap into this discipline - from concept to implementation. Our experts Johannes Gronewald and Ali Rahimi outline what is important here.
Use platform concepts
Platform aggregators that screen market offers, identify the best price, and ideally build a bridge to the original policy provider have long been state of the art in the insurance business. In the course of digital transformation, end-to-end integrated platforms and marketplaces have long since made inroads into insurers. This means that companies gain access and leads via Check24, Verivox and similar portals - but only if they: a) play by the platform providers' rules. b) offer transparent offers and policies at a competitive price. Conversely, this means that offers are: c) ranked according to the algorithms of the platform operators and insurance providers. d) no longer extremely challenged only with standard products.
Insurance industry in transition: Why insurance companies cannot avoid High Performance Pricing
Increasing market transparency through digital transformation is driving the young discipline of high performance pricing. Aggregator platforms are increasing competitive pressure. Standard insurance products can be compared one-to-one in terms of price and performance via portals such as Check24, Verivox and others. Insurers whose rating engines respond more quickly to inquiries via these portals typically see their own offers listed prominently. Additionally, in return for advertising spends, their organic ranking can be further improved. Finally, comparison portals also offer services for performance analysis and setting up shadow rate books later used to optimize premium calculations.
Fast means, at least for end users, delivering answers to customer platforms within fractions of a second - similar to stock exchange high-frequency trading platforms. Product and service innovations are indirectly rewarded in the offer ranking vis-à-vis end customers. In the case of insurance in the areas of private liability, motor vehicles or household goods, product innovations are marginally realized. Shortened cancellation periods, exclusive coverage, telematics, etc. have long since ceased to be unique selling points. Price in combination with speed, on the other hand, produces better results. What is difficult, however, is access to diverse target groups. Against this background, the key technical question is:
How do insurers succeed in establishing and safely expanding the corresponding rating instances?
Small organizations can operate well in greenfield markets. Large insurers are typically a step ahead in terms of set-up. However, they also face more complex requirements because the necessary rating instances are usually based on older software. In order to make their existing rating engines future-proof for high-performance pricing, they are migrating their core systems to newer software (from Guidewire, for example). Then the real challenge is to find a brownfield market approach that meets the requisite performance and scalability factors. In this case, the approach uses existing legacy rating engines (i.e., Infrastructure as Code (IaC), Virtualization and Dockerization). Alternatively, insurance companies can either start with a brand new rating system or go integrated with a new core system (for example: Guidewire, Faktor10).
Large insurers in particular are aiming for an approach that connects the core system with an external rating server. Or one that keeps the rating instance smart and secure on premise or outsourced to the cloud (see table):
Location of the rating
Not all industries/divisions have the same performance requirements
What requirements insurers face as a result of high performance pricing
In order for insurers to continuously improve and expand their competitiveness, they must keep an eye on the entire customer lifecycle: from initial contact to pricing to the final contract. In this way, they can always track the customer's motives and circumstances. In most cases, an analysis of the individual customer groups is carried out directly. On this basis, market offers can be sensibly placed and, if necessary, sharpened: the downstream rating analyses generate factors that modify the rating a few days or weeks later. Resourceful insurers use this to create considerable potential for differentiating themselves from competition.
The price of a particular insurance policy is the decisive purchase criterion for many customers. This is because many benefits are comparable, for example in the case of motor vehicle insurance, down to individual parts or component protection.
Customer ratings, shopping cart abandonment and cancellation rates will increasingly influence the rating
The selected framework package, which is sensibly covered directly when a policy is taken out, continues to play an important role. For example, if an insurer is reluctant to provide helpful support to the policyholder in the event of a traffic accident, general customer satisfaction suffers as a result. In the long term, this is reflected in the customer rating results with aggregators. Other rating factors, in addition to price, such as target group benefit and customer satisfaction affect the cancellation rate. In time, shopping cart abandonment will also have more important influence on the rating. Insurance companies would therefore do well to make the application process more attractive. Keywords for this are customer attractiveness, service quality, convenience, and ultimately customer loyalty, which can be measured on the basis of cancellation and recommendation rates.
Solution design for a scalable rating module: How insurance companies should conduct analyses - an example
Suppose an insurance company uses a modern Insurance Suite such as Guidewire as its core system and has determined not to use Policy Center's high-volume quoting (HVQ) mechanism: As a result, the pricing calculation - the rating - must be modularly accessible to the entire system landscape: If the core system needs price information, it is not determined directly in the Policy Center. Instead, the aggregator sends it to the external rating module. The recipient is a special rating engine optimized for performance (for example, tailor made solutions developed by IKOR). External price requests from aggregators, brokers and possibly end customers are also sent to this external rating module.
To ensure that product adjustments in the core system are also accessible to the rating module, there must be a connection between the rating server and the core system. Otherwise the insurer operates the rating server independently of the core system. However, the effort required to manually transfer every product change to the rating module is very high with this configuration.
For example, a product adjustment in the area of motor vehicle insurance could be coverage of a new tariff - such as supplementary insurance for autonomous driving. Such an operation must be reconciled with the external rating module in the first step. The following step in turn determines how the insurer should handle access to the required rating-relevant data: direct access from memory (cache) or retrieval of the required data from an internal or external data source (database, datalake, etc.).
Insurance companies should define rating routines dynamically for this purpose. These routines regulate the sequence in which calculation steps are carried out in order to calculate a specific premium (for example, a liability base premium). In this way, they ensure a high level of reusability. In addition, they should evaluate whether they want to calculate a single price request variation or several at a time. Parameters such as payment frequency (monthly, semi-annually, annually) can be entered in an array, for example. Via the array, the rating instance outputs each requested price variation based on this parameter.
Insurers use this approach to directly display multiple precalculated price characteristics on a quote page. To be prepared for future use cases, every performance consideration should be carefully considered.
Insurers enable high-performance pricing with these 3 tips
Getting insurance companies started in high-performance pricing requires ideas, concepts and realizations. These three tips pave the way for organizations:
1. How to lay the strategic foundation for high performance pricing
Insurers must first clarify what they actually want to use their rating server for: Which user group do they want to serve and what volume can they expect? If the focus is on price queries from aggregators, brokers and end customers, fast response times are essential and correspondingly whether response times need to vary between different user groups. While aggregators usually demand the shortest response time (under 1 second), price requests from brokers and end customers can also be handled with a longer delay. This is at least true if there are no special requirements. In addition to examining which groups of people are strategically relevant for the respective insurer, insurance companies should also examine which products they want to offer via Check24 or Verivox portals, for example. The use of different rate books for aggregators is common here. In this way, channel-specific price characteristics come into play. In addition, insurers need clarity about their inquiry volume. One example: In the year-end business for motor vehicles, the number of price inquiries - across all channels - can run into the millions per minute. The strategy of first entering a sub-segment of the market on these platforms and then analyzing, evaluating, improving functionality and responses in smaller stages is considered a safer approach. Background: Comparison portals evaluate - despite large rate variations - the actual performance characteristics between all providers quite accurately - a huge learning environment for insurance companies. This enables them to show and improve their ranking based on the cumulative total offering and to proliferate that knowledge to other lines of business. For this reason, insurers should analyze whether they generate a better service offering in certain categories, such as telematics tariffs, in order to achieve a higher ranking.
2. Align behavior between the core system and rating instance: How to plan your system architecture
Make your conceptual decision on how the core system (policy system) and rating module will work together in the future: Insurers should, however, avoid extensive embedding of the rating in the policy system if possible. Otherwise, the risk of external attacks on sensitive customer data (policy information, customer data) increases. Instead, organizations should agree on the rights and privileges with which their rating server is allowed to communicate with the core system. The most valid configuration is to seal off the rating instance completely from the core system.
Whatever the decision, product information should be synchronizable between the core system and the rating module. This avoids additional implementation effort within the rating module. Product changes or product adjustments must then either be made via an automatic data import or - depending on requirements - manual entry. But beware: poor implementation quickly leads to duplicated workload.
In order to deliver consistently excellent performance in price calculation, insurers should keep all required rating-relevant data in the memory (cache) of the respective server instance. The best way to start up the rating module is to load all required data such as ratebooks, rating factors and other rating-relevant data into the cache. This improves the initial access time to this data and it allows very good average times to be achieved for calculating a premium. On the other hand, performance decreases when additional data has to be retrieved from internal or external database tables. The performance requirements are decisive for the margin of a price request.
The decision on how to host the rating module is also a predictor of performance. If an insurer wants to run its application itself, "on premise," it must consider seasonal effects throughout the year. This includes, for example, periods when users make more price requests for a better rate in the following year - peak load seasonality. Whereas an on-premise construct usually uses a static server setup that has to deliver peak performance at all times, cloud solutions enable dynamic scaling. Load peaks can thus be anticipated and well cushioned. The same applies to self-hosted cloud solutions. They also enable comprehensive scaling of computing resources as needed.
3. Plan for continuity: How to balance effort and security for maintenance and support
Once the rating server has been set up, it must be continuously maintained and expanded. To do this, insurance companies need a concept for importing new or modified products into the system. In most cases, new ratebooks with new tariff versions are imported several times a year. This enables companies to provide the market with new insurance options or simplified price compositions.
A daily pricing function, for example, helps companies to react to price changes in the market on a daily or even hourly basis. However, the actual tariff versions remain untouched. Instead, in the simplest case, companies add a specific discount or increase to the total price.
The hosting of rating engines in the simple version runs on premise. Nevertheless, it is recommended that insurance companies opt for a hybrid version - a mixture of on site plus a cloud solution at peak times - for optimal scalability. So-called hyperscalers such as AWS or Microsoft Azure work even faster. The fastest way for insurance companies to achieve serverless computing is to connect aggregators directly to a lambda function at the hyperscaler. Then a lot is possible in terms of AI usage at optimal speed.