Juggling Act – Half 4: Modernising core platforms for all times insurers

0

In this series of blogs, my colleagues and I will look at the insurance sector in emerging markets with a particular focus on technology, digitization, platforms and ecosystems.

Life and P&C insurers share similar drivers in their need to modernize core systems. After all, they face many of the same challenges, including digitization, the rise of platform competitors, changing customer expectations, and the need for online service.

However, life insurers face unique challenges when it comes to modernizing core platforms. As a result, their decisions are more complex, and the ways in which they can implement the changes they need are also different.

Flooded in paper and old code

The differences are largely due to the time factor: The products of the life insurers cover much longer periods of time – for example, decades for old-age provision products compared to a year for motor insurance. In addition, products are more likely to be kept on outdated systems. And there are different rules for different products, which complicates each solution.

Even if the insurer knows the product rules, migrating policies to a new system is a complex and risky task. Some of my customers have tens of millions of policies. Extracting these from old systems and moving them to a new system with very strict data rules is a logistical nightmare. And unlike P&C insurers, there are very few convincing off-the-shelf software solutions – although Accenture’s life insurance platform (ALIP) is an exception to this rule.

Complexity increases as life insurers have to resolve the data conversion. This is a challenge as the data rules of the old systems have usually long been forgotten, while experts who keep them are on the verge of retirement.

That explains, in a way, why many life insurers have not acted. It’s not that they don’t want to; After all, no CIO wants to be responsible for a dozen inefficient systems that are expensive, perform badly, and are written in a language few people can maintain. That’s because it’s not easy to take action. If it were, life insurers would have done it years ago.

Many life insurers are therefore in a similar position: they operate numerous separate systems at high cost and with limited efficiency. They can’t migrate policies from old systems and have simply accepted that they need to keep them all running. For example, a customer in France had 17 separate life systems.

The decoupling lifeline

Life insurers looking to change their core systems have four strategies, with the best option depending on the carrier strategy, technology stacks and product types. Let’s look at the first three:

  • Replace: This usually involves using a cloud-based platform and SaaS and is best for standard product types in large regions. As mentioned above, implementing old guidelines is a fundamental challenge.
  • Re-platform: The older core platform is ported from mainframes to the cloud, with conversion factories converting COBOL to Java, for example. In practice, however, a poorly designed execution in COBOL becomes a poorly developed execution in Java, which means that it offers no flexibility and the need for a truly digital architecture.
  • Go into retirement: Aspects of the system are put into run mode and core functions are reduced. This is usually not of much use to life insurers.

At this point, life insurance clients often ask, Well what can we do?

The answer is to architect. This involves digitally decoupling and hollowing out the core. I’ll cover this topic in more detail in an upcoming series of blogs. With this approach, however, the insurer briefly develops a strategy that gradually replaces the system functions and reduces the scope of the applications used. This brings flexibility, shorter time to market, and better travel for digital distributors and customers.

Click / tap to view a larger image.

As the diagram shows, life insurers have several options for defining the right decoupling strategy. Either way, they remove business rules from the front-end and back-end systems to avoid duplication, and hollow out the core of the legacy system by using APIs and microservices to run processes. Strategy B differs in the integration of real-time access to a data lake to ensure immediate updating and processing.

(It’s worth noting that a decoupling approach is usually less applicable for P&C insurers because their products are short-lived and they can more easily choose from numerous options for replacement software.)

For life insurers who deal with multi-year products and the lack of software alternatives, decoupling is usually the best approach – as one of my clients in Asia discovered. This client had multiple group life systems and highly complex policies and could not process information in real time.

We have helped the client gradually introduce a decoupling strategy in each country in which they operate. Crucial was that the corporate culture was changed to implement agile development methods. This ensured that the local operations in each country could go their own way, but still operate under the decoupling template.

Today this customer has an extremely efficient system that quickly develops new products and updates information for customers and operations in real time. (The backend system is updated with a delay, but this has no effect on what the customer sees or on the business of the insurer.) With this function, it can use its agility and digital architecture in all markets and thus be far ahead of the market Competition.

With a responsive, digital platform, both life and P&C insurers are in a great position to find partners and expand their customer base. As we’ll see in my next blog, the partnership brings both opportunities and challenges.

You might also like

Leave A Reply

Your email address will not be published.