In the heart of the core (forgive the redundancy)

In a time in which adaptability and efficiency are crucial for the success of the companies, the insurance industry faces its own challenge with the need to update its core systems to remain competitive. In this context, and when the decision is to integrate an external solution, modularity is usually an almost “magical” concept that presents itself as a promising lever, offering the possibility of updating and improving individual components without the need to replace whole systems. In this article, I describe the functional modules that may be considered the centre or the heart of an insurance core system, distinguishing them from those that play a more supporting role, and briefly present the strategies to adopt when choosing between integrating a complete solution versus selecting modules, assessing the corresponding advantages and disadvantages.

There is some confusion with regard to the functional scope of a core system for the insurance industry. Over time it has become a system that does everything, and therefore I think it is important not to lose sight of the areas that should naturally be within its scope, and those that are more like satellites that have been created around it (adding value, in some cases). Everyone may define the limits where they deem fit but allow me to contribute with my view.

In the centre: This is where the backbone of operations resides. Thus, here we may include the product configurator and the business rules, underwriting, portfolio management and renewal, claim management and billing. These modules are critical for the daily operations and for the long-term viability of an insurance company, and their robustness and reliability are of the utmost importance.

Auxiliary modules: We move towards the periphery of the core, with features that, even though they are not essential for the main operations, play an important role in the improvement of efficiency and client experience. These modules may include document management systems, BI and reporting, client CRM, intermediary commission settlement, reinsurance, clients/intermediaries’ portals, and BPM solutions. It is common for these areas to have specialised vendors that offer niche solutions.

It is very important to clearly define these limits before initiating a project to update the core insurance system. It is very common to find – within the very long list of functional requirements – a confusing mix of cases that may fall under one or the other scope. This may cause one to lose sight of what is truly relevant when it comes to choosing the most suitable solution, which will be the one that best solves the specific issues of what we have defined as the “centre”.

Now, about the two strategies when it comes to choosing the solution:

• maintaining legacy system modules (that is, product configurator, claims…) and integrating modules of an external solution;
• adopting a complete solution from one vendor.

Strategy a) allows insurance companies to update or change one or more modules without affecting the rest of the system, which contrasts with the traditional monolithic systems in which any change may require a complete revision. Here I am referring more precisely to the perimeter that we have defined as the “centre”.

Strategy b) entails adopting a complete solution from a single vendor, completely abandoning the legacy system.

It is interesting to note that, even though it may sound good (in addition to also pleasing those groups that always exist in insurance companies who are very attached to “their” features, which they have built over time with great care), strategy a) always overlooks something that usually leads to the failure of this type of project: high integration costs, due to a greater complexity of the project, which happens in most cases. Not to mention that it becomes very difficult to manage communication and responsibility when there is not one but many systems at play, each one with its own team.

With strategy b), it may be frightening to leave something so critical as the core system in the hands of an external vendor. Also, it may be difficult to let go of legacy modules that have been working reasonably well so far. To address the first problem, there are many solutions, including contractual ones, which offer enough guarantees. For the second, it may be necessary to objectively analyse if there is any reason to keep those parts of the legacy system, or if it is just aversion to change, fear of losing something to which we are accustomed.

It is crucial that each insurance company makes its own detailed analysis, considering factors such as corporate culture, organisational structure, resources available and global business strategy. However, with the possible exception of Tier 1 companies, which, due to their dimension and complexity, require a very specific approach (combining legacy and external functional parts), for the rest of the market, it is more convenient to adopt a blank slate approach.