EIS leader speaks about company's cloud insurtech strategies

Published August 15, 2022 6:22 AM

Updated August 15, 2022 6:22 AM

1 Min Read

EIS corporate headquarters in San Francisco.

Digital Insurance spoke with Alec Miloslavsky, founder and CEO of EIS, the digital insurance platform provider founded in 2008, which recently acquired Metromile's Enterprise Business Solutions (EBS) SaaS claims automation and fraud detection service from Lemonade. EIS technology addresses data integrity, product testing and launches, automation, workflows and customer service. In 2014, the company began moving off what Miloslavsky calls "modern legacy" technology, toward cloud-based services.

How was EIS’s cloud data platform originally designed?

We had a more or less traditional technology stack. We adapted that to the cloud. By then we had a lot of experience running Agile development and continuous integration, continuous development mode. We productized that. That was a novel concept then.

We started to automate manufacturing around our platform as the first step. We took a lot of lessons from larger cloud-native platforms such as Amazon, Facebook and Netflix. Sometime around 2017, we went about on a fairly drastic redesign of our platform to become cloud native, and be able to take advantage of all of the services that exist within various clouds while maintaining a cloud agnostic stance and heavily leaning on open source.

We made sure the new design had all we learned from implementing solutions across insurance verticals. We made sure it's all event-driven and that the platform can function as transactional and analytical. This constrains how the system is designed, because a modern system isn't just walled off as a transaction system. You constantly have to integrate. You constantly have to process the data, sometimes in near real time.

How do the customer service or streaming capabilities of Amazon, Facebook and Netflix apply to what EIS has been able to do with the cloud?

There are a couple of things that are very similar and desirable. The user experience is at the center of what these companies do. This has not traditionally been the strength for an insurance company. If an insurance company wants to operate more like Amazon, with multiple products on the shelf, whether yours or third parties', and wants to sell or service multiple needs – health, wealth and risk – they have to be able to adapt the user experience accordingly. These companies contributed that to open source and we're a happy recipient of that.

All of these companies are operating a service. They're SaaS companies. As insurance companies are moving towards the SaaS model, they are meeting the same challenges that they have to solve. Adapting the approach or some of the technology that these companies are using is another example for operating infrastructure.

For connectivity and APIs, platforms have to interface with a number of different partners, distribution channels, third-party supplier channels and alternative channels. That's a universal problem for a SaaS company or for a SaaS implementation. There are a lot of similarities when you're talking about a large enterprise footprint that you have to run in the cloud.

Today, most of our customers are migrating to the cloud. The majority of our pipeline, our forward-looking opportunities and implementations are all SaaS. We're actively rolling out a new cloud-native version across all of the verticals we participate in -- both P&C and non-P&C. We are probably somewhere in the middle of that transition. We have a separate internal managed services organization that didn't exist three or four years ago. That organization operates our customer solutions and supports upgrades, which makes us a SaaS company. That's where we are today.

How may EIS's products and services continue to develop?

If I were to step back and say, what is the vector of the whole company, I would say our main enemy that we're fighting is time. It's time to implement the system. It's time to upgrade the system. It's time to modify. Also, most importantly, it's time, for our customers, the carriers, that they're spending in running their operations. All of that amounts to removing labor from various aspects of deploying and owning the system -- enabling decision-making on operating the system by the business users. The latest acquisition [Metromile EBS] is in line with that. It's both a claims front-end, but also it's a fraud detection AI/ML solution. It optimizes claims operations just around the claims that need to be examined and streamlines handling of legitimate claims.

I see our customers being able to come to us, get on the system, have a multiplicity of products that they can pull up and configure to sell to their intended customer base – at a fraction of the time that it happens today, and have various solutions built into the system that remove the labor and cycle time from actually operating the solution itself.

That breaks down into software features and solutions, and now into data science solutions, which are different than software. For instance, claims. Fraud [detection] is not a software solution. It's a data science solution. It feeds the results of its processing back to the system. It's about detecting and processing the data in a very smart way.

How does the acquisition of Metromile EBS compliment what you've been doing on a SaaS basis? How is adding EBS useful for EIS?

EBS has a very advanced, packaged claims front-end – claims processing system. We have a claims back-end. So fundamentally, it's a complimentary component. Their installed base is on top of our competitors' claim systems. It immediately accelerates our product roadmap for claims. Secondly, it gives us an ability to transact with customers, even though they are not our customers, on our core tech platform.

We plan that to be both standalone and integrated with our solutions, to have the two options. The teams will be kept separate with their own roadmaps for that reason. The third and probably the most strategic and long-term direction is to develop as a complement to our software solution, a line of data science solutions, fraud detection for personal auto and home and renters. We are not just in P&C. We're also in life and annuities benefits, and prospectively life and health. Those lines of business are also very target rich environments for fraud detection. We hope to apply this capability and this good team to similar problems in adjacent lines of business.

The second direction is to look for opportunities for data science solutions other than fraud, underwriting and pricing. The insurance business lives on data. We're a core systems provider. So whenever we transact, we end up processing that data. It's a very natural fit to come with our current and prospective customers with the credibility and a focused team to develop adjacent data science applications. That's a more long-term strategy that complements our existing software core tech offering, SaaS.

What other factors play into whether you build something internally or buy -- in effect acquire a company for a function?

We would not be inventing basic technology. It's available but it's a chicken-and-egg problem for a software vendor. Coming to a customer with an empty cart and without a talented team that's focused on this, it's very difficult to gain traction. With the EBS acquisition, we gain credibility and an install base that can attest to the solution and its effectiveness. We have data that shows the benefits, which are quite substantial. There's a team solely focused on us. It's an asset that we can now deploy where we both have credibility, execution capability, focus, and references. That made it an extremely attractive move. This is the first acquisition EIS has made. Acquisitions are not our strategy.

Some of our competitors explicitly use acquisitions as a business strategy to grow the business. It's legitimate. It's just not our strategy. EBS was a very specific opportunity that fit the mold, and accelerated our entry somewhere to where I saw it as strategic to be in the first place. It didn't require substantial integration because it's complementary to what we do today. We didn't have to decommission any technology or go through a very difficult integration cycle. That made it a very easy decision.

	About Michael
mailto	michael.shashoua@arizent.com
linkedin	michaelshashoua