Platforms are the backbone of insurance technology, there to support systems like claims management, for instance. The only time they attract attention is when something goes wrong. Dane Richards, CTO of JMR Software, says insurance companies usually only consider migrating to a new platform when their existing core platform no longer serves their current needs or the pain points around that platform have reached a point where it’s no longer viable to continue with it from a business perspective.
“During data migrations, we get insight into the challenges a company was experiencing with its existing platform, although it probably suited the company’s needs at the time of implementation. This offers the ideal opportunity to address these.”
He goes on to discuss common pain points experienced by insurance companies during migrations, as well as the challenges they face, as well as how they can plan ahead to mitigate those pain points. He highlights the four main challenges common to the insurance sector during data migration, focusing on the core policy administration side of things.
1. Inflexibility
Common to the insurance sector, this results in difficulty in creating new products – and insurance companies thrive on creating new products. Core platforms offer some flexibility in terms of how you can configure and build new products, but you always reach an upper limit in terms of what one can do within a platform. An ageing technology stack contributes to inflexibility. Richards explains: “In the insurance industry, products tend to last for several years, sometimes even decades. You get to the point where, if you implemented your own platform, your technology stack ages and your staff and availability of that technology starts to dwindle. Legacy environments are more costly to operate and maintain than modern systems. This becomes an inflexibility within your current core platform.”
2. Inaccessibility or accuracy of data
When a business adopts a core platform, at that point in time the reporting was probably adequate for its needs. But these requirements evolve over time, particularly with the advent of Big Data and AI. Limited reporting can be a major pain point for an insurance business, and it ties in well with Richards’s next topic, which is black boxes, especially around ratings models. “All too often software is created around how a particular product must be rated. The developer has to figure out how the calculations need to happen, and he probably won’t document what he’s done to get there. When the business wants to migrate 20 years down the line, they can’t track how a particular product was rated. This makes it difficult to move off the system.”
Restrictive access to underlying data in insurance platforms is a consequence of systems having to be both generic and able to handle complicated things. Sometimes the only way you can understand the system’s data logically is via the app’s front-end. What you see in front of you makes sense, but the way the data is stored in the underlying system isn’t relevant for data reporting purposes.
3. Regulatory changes
Sometimes regulatory changes affect the flexibility within a product. What may seem like a routine regulatory request – such as providing a real-time feed of the policies you have on cover – may not be possible with a current product. This could drive a need to change that product or result in a bolt on, on top of that product, to make the regulatory change available. Coupled with the above, you have various data protection regulations, where you’re required to protect your underlying data against leaks and risks. Is it possible to comply with customer protection regulations like GDPR, POPIA and Rule 13 within your current platform?
4. Security
If the core platform has a lot of manual processes, there’s an inherent security risk. So, for instance, if you have a data capturer recording information on two separate systems, there’s twice the vulnerability to an attack. Attackers are looking for softer, more accessible vectors, such as the data capturer’s having credentials to legitimately access or modify data. That would be easier than attacking the application itself directly. This ties into the next point around legacy application security concerns. If there are concerns around what data access you have within your core platform, the only thing one can do is either amend the code within the current platform or have additional security layers applied on top. This just adds to complexity. Then you also have to consider where the data is stored and whether it’s secured.
Dropping the ball
“When it becomes time to migrate, this is where the business uncovers lapses that occurred when maintaining its existing platforms,” says Richards. The first lesson being that it’s key for insurance companies to have a single source of truth, regardless of whether customer data is stored across multiple systems. Then companies make the mistake of incurring technical debt in the rush to get to market first with a new capability. When a new app goes live without the business fully understanding what the framework should be, the company has basically borrowed money against its code base and at some point it needs to go back and line the product up with the current technical landscape. However, the polar opposite of this also occurs in the form of fear of change. Companies want to upgrade their applications and change the way products are built and maintained, but fear change because not everyone will be on board with the new system, or their software or hardware is too outdated to work with it.
When the insurance company finally bites the bullet and decides to move to a new core insurance platform, there’s even more that can go wrong, says Richards. The foremost of these is fighting the product, which is when the business wants to force the new platform to do relatively trivial things in a certain way and in so doing, causes the product to be less stable than it was at the outset. “You need to pick your battles,” he advises. “Would you rather have a working rating engine or have the first names and surnames appear in a particular order?”
Getting stuck on a fixed migration date is another challenge faced during migration. “You have to be flexible about this as developments happen during the migration that you can’t control. If you remain fixed on a particular date, the people doing the migration will just focus on completing their portion of the work by a certain date, they’ll lose sight of the bigger picture and end up clashing with other teams in the race to the finish line.”
It’s important to set goals and priorities in terms of what you need the app to do now and in the future. “If you don’t lay out those goals early on, you may get to a point where they become pain points in your new application.”
Richards ends off with some basic pieces of advice on where insurance companies should focus their technology strategy to ensure fewer of these pain points.
- Create an open environment when designing your core platform, regardless of whether it’s going to talk to other apps within the environment. Embrace running multiple platforms within your environment.
- Own your own data, don’t rely too heavily on vendors. Know exactly where your data resides, know how to get your data out and what data is available to you.
- Practise failure – at some stage something will go wrong so practise those potential failures.
- Document your processes. Even if you aren’t going to migrate off your product, pretend you’re going to migrate tomorrow. Start asking questions such as where’s my data located, how does one rate this particular product, what is my product configuration. During migration, you’ll need to ask your old system these sort of questions, so you should ask your new system the same questions. This provides you with a full set of documentation for the day you want to migrate.
- Pay back your technical debt. If you put in place a tactical solution, focus on paying the technical debt back, like maintaining technical solutions, keeping them up to date from a security perspective, and aligning them within your product so the new solution has a longer lifespan than originally envisioned.
- Enforce your data master models. Ask yourself where the master is stored for your customer documentation – ie, is it in a core system – and is there a single version of that data.
- Data security. Stay aware of emerging attack models, are they targeting people within the business instead of the app itself? Do regular penetration testing. And only expose customer data if there’s an absolute requirement to do so. With an open platform, you need to decide what information must be available to underlying systems. Only expose the information needed to serve that Big Data or machine learning system.
Share