Wählen Sie eine Sprache
Many insurance companies are taking steps to use application programming interfaces (APIs). Building upon internal APIs for backend communications that have been in place for a while, but now the focus is on opening up APIs to the outside world to offer better services to policyholders. Call it connected insurance, Open Insurance, or open APIs - whatever the name, it all relates back to finding a common approach to securely share data that drives value.
As is the case with many industries, the emphasis today is on improving the customer experience. Clients’ expectations are growing: for example, life insurance policyholders haven’t forgotten how important it is to ensure that their loved ones will be taken care of if something happens to them, but they also want something more than a death benefit for the premiums they’re paying. They want to realize everyday value – and if they can’t get it from their current insurance provider, they’ll find one that’s more accommodating.
One way for big-brand insurers to deliver on this demand is to provide incentives that hit home with policyholders – for example, a discount on their life insurance premiums if they go to the gym three times a week for six months. Without open APIs, though, it can be difficult to track and verify a customers’ adherence to the deal. That problem might be solved by connecting their clients’ fitness apps to their legacy systems via an open API - which is any API that an organization makes accessible to third parties.
Traditional insurers are tied to the open API economy as much as any other industry - and if they don't get it right, they won't be able to keep pace with the insurers that do. Ten years ago, insurers feared the insurtech disruption, and now they are seen as potential partners and a way to incubate new ideas. More and more insuretechs are given access to insurers' open APIs, scrubbed clean of policyholder data, to develop innovative apps that can help differentiate the incumbents in the market. This approach relieves some of the app development burden that’s placed on big insurers’, and it positions the startup to have a stronger partnership with the vendor, and even perhaps position itself for a potential acquisition.
Another issue that may occur when big insurers don’t embrace open APIs is the inability to pair with other digital innovations boosting customer value in other ways. Consider the insurer who uses an open API to industry-specific aggregated real estate listings to deliver home insurance quotes. These quotes created in tandem for online real estate listings can facilitate securing new business through that channel. In another instance, using open APIs integrating its secure and protected customer databases with car dealerships’ financial systems, so that customers can purchase auto coverage on the spot.
Adoption of open APIs
Open platforms are essential for creating an effective open API ecosystem. Insurers need to consider key elements such as:
In addition, there is now a greater push toward industry-standard interfaces and integration between layers of the stack to simplify interoperability between applications, APIs, and systems of record.
Insurers may choose to modernize their legacy systems as well, to maximize their transformation, electing to build a more modular open insurance platform. The cloud adds value here, as it provides the environment to introduce container platforms and use microservices for faster and more flexible development. Some insurers have been hesitant to move their core functions, like claims systems, to the cloud, but they can’t ignore this capability for much longer based on potential efficiency gains, especially when paired with private/hybrid cloud options.
As always, and especially in light of these considerations, insurers maintain the need to implement API management and address API security. The claims process is a good example. It can be characterized by a precise interplay of systems and calls, and thereby many APIs to be facilitated, orchestrated, and managed - and while seeing to security in every step of the process.
Containers can simplify application and API deployment and portability across platforms that are behind the firewall or in the public cloud. This eliminates the need to refactor services to launch them on different infrastructure and makes your operational platform more efficient.
As an enterprise-grade container application platform, Red Hat OpenShift runs containerized workloads and their underlying associated components. It includes built-in security features for container-based applications — including role-based access controls (RBAC), SELinux-enabled isolation, and checks throughout the container build process — helping to safeguard your overall API environment.
In this standardized platform, insurers gain the ability to deliver Linux containers at scale to build high-performance apps in a packaged, secure, and automated way. Red Hat 3scale API Management offers API traffic control, security and policy enforcement. In addition, Red Hat Fuse, can also be deployed to integrate application components and microservices across the enterprise, while Red Hat OpenShift Application Runtimes provides portability across multiple cloud infrastructures.
Learn more about how an open API strategy can help insurers develop, deploy, and maintain innovative applications in Open API technology strategy for insurance companies. The brief not only describes how open APIs enable insurers to be more responsive and quickly build applications, and deliver new products and services, but also helps them integrate with insurtechs and startups so they can provide developer portals and better client connectivity.
About the author
Jeff Picozzi is a Principal Product Marketing Manager specializing in the financial services industry for Red Hat. He has more than 20 years of experience in the industry. After working for a global insurer and wealth management institutions and surviving Dodd-Frank, Solvency II, and the Basel Accords he began working for technology partners supporting the industry.