Juggling Act – Part 4: Modernising core platforms for life insurers

Juggling Act – Part 4: Modernising core platforms for life insurers

In this series of blog sites, my coworkers and I will look at the insurance coverage sector in Growth Markets, with a specific focus on innovation, digitisation, communities and platforms.
Life and P&C insurance providers share comparable drivers in their requirement to modernise core systems. After all, they face many of the same obstacles, including digitalisation, the rise of platform competitors, changing customer expectations and the requirement for online servicing.
Life insurance providers, though, face special challenges when it concerns modernising core platforms. As an outcome, their choices are more complicated, while the methods in which they can execute the essential modifications likewise vary.
Awash in paper and old code
In big part, differences come from the time aspect: life insurers items cover far longer periods– years for retirement products versus a year for automobile insurance, for example. In addition, items are most likely to be hung on old-fashioned systems. And there are various rules for different products, which complicates any option.
On top of this, even if the insurance provider knows the product guidelines, moving policies to a brand-new system is a complex and dangerous workout. Some of my customers hold 10s of countless policies. Drawing out these from old systems and moving them to a new one that has a very rigid set of information rules is a logistical problem. And unlike for P&C insurance companies, there are really few engaging off-the-shelf software application solutions– though Accentures Life Insurance Platform (ALIP) is an exception to that guideline.
The complexity increases due to the fact that life insurance companies require to deal with information conversion. Thats an obstacle due to the fact that the old systems data guidelines have actually typically been long forgotten, while any experts maintaining them are nearing retirement.
That goes some way to discussing why numerous life insurance companies havent acted. If it were, life insurance companies would have done so years ago.
Lots of life insurance providers, for that reason, remain in a similar position: running many different systems at great expense and with restricted performance. Unable to migrate policies from old systems, theyve just accepted that they require to keep all of them running. One client in France, for example, had 17 separate life systems.
The decoupling lifeline
There are four techniques open to life insurance providers looking to alter their core systems, with the best alternative reliant upon carrier strategy, technology stacks and item types. Lets take a look at the first 3:

In big part, differences stem from the time factor: life insurers products cover far longer periods– decades for retirement products versus a year for vehicle insurance. And unlike for P&C insurance providers, there are very couple of engaging off-the-shelf software application options– though Accentures Life Insurance Platform (ALIP) is an exception to that rule.
That goes some way to describing why numerous life insurers have not acted. Many life insurers, for that reason, are in a similar position: operating various separate systems at fantastic cost and with limited effectiveness. As the diagram reveals, life insurers have a couple of choices when it comes to specifying the ideal decoupling method.

Its at this point that life insurance provider clients typically ask: Well, what can we do?
This includes digitally hollowing the core and decoupling. Ill go into this subject in much higher detail in an upcoming blog series, but briefly this method sees the insurance provider establish a strategy that gradually changes the systems functions and lowers the scope of the applications used.
Click/tap to view larger image.
As the diagram shows, life insurers have a couple of choices when it concerns specifying the best decoupling technique. In both cases, they remove company rules from front-end and back-end systems to prevent duplication, and hollow the core of the legacy system by utilizing APIs and microservices to run procedures. Method B differs by including real-time access to a data lake to ensure immediate updating and processing.
( Its worth specifying that a decoupling method is typically less relevant to P&C insurance providers, since their items have a brief timeline, and they can more easily pick from numerous replacement software application alternatives.).
For life insurance providers dealing with multi-year products and a lack of software alternatives, decoupling is generally the best method– as one of my customers in Asia discovered. This client had several group life systems and extremely complicated policies, and it could not process information in real-time.
We helped the customer to roll out a decoupling strategy progressively across every nation it operates in. Crucially, this implied altering the businesss culture so that it might execute agile development methodologies. This guaranteed that regional operations in each nation could go their own method, yet they still operated under the decoupling template.
Today, this customer has an exceptionally efficient system that establishes brand-new products quickly and updates information for customers and operations in real-time. (The backend system updates on a delayed basis, but that has no effect on what the client sees or on the insurers operations.) With this in location, it can leverage its dexterity and digital architecture in all its markets, putting it far ahead of the competition.
Having a responsive, digital platform locations both life and P&C insurers in an excellent position to look for partners and expand their client base. As well see in my next blog site, partnering brings both challenges and chances.

Change: this usually involves using a cloud-based platform and SaaS, and is finest suited for basic product-types in big geographies. As kept in mind above, one fundamental challenge is converting old policies.
Re-platform: the legacy core platform is ported from mainframes to the cloud, with conversion factories converting, say, COBOL to Java. In practice, an inadequately developed execution in COBOL ends up being a badly established execution in Java, which indicates this does not deliver versatility and the need for a genuinely digital architecture.
Retire: elements of the system are put in run-off mode and core functions are lowered. This typically isnt of excellent use for life insurance companies.

Leave a Reply

Your email address will not be published. Required fields are marked *

error: Content is protected !!