(Image credit: NASA.)
The core system question has largely been answered in the property/casualty insurance industry sector, but life insurance lags behind, in significant part because life insurance policies don’t renew annually. However, life insurers still face the same changing expectations of insurance customers and need to make decisions about how they will transcend the limitations of their legacy systems in order to meet those expectations. We took the opportunity of a recent conversation with Martijn Moerbeek, Director of Digital Strategy & Innovation, at Legal & General (London)— British multinational life insurer and financial services company founded in 1836—to explore the question.
Insurance Innovation Reporter: Where do life insurers stand with regard to core system modernization, and what strategies are they undertaking to stay competitive?
Martijn Moerbeek, L&G: I would totally agree that life insurance is way behind other financial services sectors. I would argue that insurance as a whole is perhaps two or three years behind, and insurance life is some years behind general insurance. So, we have a lot of catching up to do, and L&G is no different compared to competitors in that regard.
There are two ways to look at legacy core systems. One is the approach of re-platforming onto completely new platforms. However, those initiatives are costly in both funding and time, and they carry significant risk. Typically, a life insurance company’s legacy systems have grown additional functionality—so you have to re-platform not just the systems but everything integrated into them as well. That makes the business case hard to justify. Even if it can be justified, insurers are not always ready to take the plunge because if the initiative goes wrong, there’s significant exposure—it could impact operations, customer experience, regulatory compliance, etc.
The other way to think about it is to ask, “Is legacy such a bad thing?” These systems are cost-effective for what they do well, they are scalable, they have high degree of up time—they hum along in the background. At L&G we talk about our legacy and heritage as an institution, but legacy technology has become a bad thing. We think it can be a good thing, but the liability is that it’s not easy to build new functionality on top of it.
What insurers can do—and we are increasingly doing—is to let legacy hum in the corner. But while doing that, we’re getting started decoupling ourselves, reducing our reliance on legacy over time. One way to do that is creating a APIs that open to the legacy systems.
IIR: Is the idea to externalize the rules of the legacy system?
MM: Not at first. The API opens up the legacy system. They were quite monolithic, closed box, not easy to integrate. Integration on system to system level. If you create an API that opens up your legacy, then all the new innovation can plug directly into that API.
IIR: So, you let the administration system do what it needs to, but you can integrate new functionality with it, for example, a new customer service app to change the address. The point is that APIs create a new, more efficient way of integrating?
MM: Right. The second way is thinking of the lifeline of innovation, which today is data. Can we scoop out the data and mirror that in a cloud-based data lake while the legacy system sits there and does what it does? What you can then do is use API or data lake and build innovation on top of that or other functionality that slowly starts moving away from reliance on your legacy system.
IIR: So rather than complete re-platforming at once, you break of pieces of functionality?
MM: Correct. If you create an API or shift data in data lake you can build a new piece of functionality that mimics new version of quote and buy journey, and you can eventually kill it off in the legacy system. If you do that often enough, then the legacy system at some point becomes of such a scale that it makes sense to re-platform it.
Therefore, rather than doing a wholesale re-platform of a monolith system in one-go, over time, you slowly deprive it of ‘oxygen’ and re-platform when it’s been so much scaled back that risks and costs have become acceptable.