Three Key Considerations When Purchasing a Platform
By Mitchell Wasserman,  Chief Product Officer, Insurity

Gartner and Celent have both labelled 2018 as “the year of the Insurance Platform. Gartner also boldly predicted that platforms will comprise 100% of the core systems purchased by the end of 2019. But while insurers rush to select the technology that will power their businesses for years to come, it’s important to identify what’s needed in order to build a platform that won’t become obsolete in just a few years. 

Continue from eInterpreter

“Future-proofing” has become a common phrase in the marketing materials presented by insurance platform providers, and refers to a platform’s ability to sustain its usefulness over the long term as technology changes occur more and more frequently. Below are three elements that insurers should consider when deciding the validity of a “future-proof” claim. 


Application programming interfaces (APIs) define the contract and process by which software applications can interact with each other. In simple terms, APIs are the plumbing of a platform strategy, allowing each application to share its information and processing capabilities. APIs are also the means by which information is collected by applications; for instance, as drone data becomes more commonly used in claims, the information that they collect will be submitted to platforms via APIs. Complexity arises as different applications use different language formats for their API’s (eg. SOAP, REST, GraphQL), implement those languages differently and have different access security methods. Some API’s provide only a monolithic ability to process an entire transaction while more flexible API’s offer more lightweight, granular capabilities such as the ability to calculate taxes, fees or premium for a specific coverage. Furthermore, documentation and support of API’s also varies widely between application providers.  Some offer easy cloud-based access to test environments, detailed documentation and code samples whereas others have only basic implementation guides. In evaluating a platform provider, it’s important to understand their current capabilities as well as their long-term commitment to API’s which should be documented on a clear roadmap. 


In today’s insurance environment, nearly every employee may have some sort of input into their actual workflows. Most of them, however, have limited-to-zero ability to program. To empower those employees, it’s imperative that flexible platforms allow them to easily configure the screens they see and that those screens work on both computer monitors and mobile devices. We refer to this as codeless programming - the ability to create custom workflows and user experiences in a platform and implement in near real-time without having to go through a typical software development lifecycle.  

To properly test for this characteristic as part of a demo, insurers should ask platform providers to show how their configurability can be used in a carrier-specific business context. In other words, rather than accepting a vendor’s demo of the configuration they offer, their ‘best case’, insurers should ask their prospective platform providers to demonstrate a couple of common and non-trivial changes. By way of example, a script may ask for the configurer to add a new data element, driven from a drop-down that appears only when a specific coverage is selected, have it drive a new rating factor that is retrieved from a second table using a lookup key that includes 2 other data elements. This is future-proofing for workflows. 

Regulatory Support

The insurance industry is among the world’s most regulated, with state-by-state requirements adding friction to operations, marketing, and nearly every other step of the policy lifecycle. As such, true future-proofing requires a platform that can evaluate new regulatory changes as they arise and allow insurers to easily decide whether to adopt them or deviate and file those changes. A platform needs to separate an insurer’s custom deviations from the core bureau changes to facilitate this process, and this process must be baked-in. Insurers should ask their prospective platform provider to document the length of time it takes for new regulations to be incorporated into its knowledge base, what advance notice is given to its clients, and what ability clients have to accept/reject individual bureau changes. 

As messaging around platforms has gained steam, there has been a tremendous amount of hype and conjecture about what can be accomplished. Using the guidelines above, insurers can separate out fact from fiction, and ultimately make the purchasing decision that best fits their platform needs. 

Mitchell Wasserman
Chief Product Officer