Lemonade’s acquisition of Metromile has been in the news for some time, but recently we learned that the Metromile Enterprise Business Solutions unit has been sold off to EIS.
I can’t comment on the specifics of the Lemonade or EIS acquisitions, but this is interesting from an industry perspective when it comes to the sale and support of nontraditional insurance products. By nontraditional, I mean on-demand products, pay-per-mile auto, gig worker policies, or other continuously underwritten or data-driven policies.
What follows is a series of questions (and answers!) about this space:
What is the Metromile Enterprise Business Solutions unit?
Metromile distinguished itself in 2011 by selling pay-per-mile auto insurance using automotive telematics technology. Metromile Enterprise Business Solutions was a separate group that repackaged and licensed the core technology in use by Metromile to other insurers. The Metromile Enterprise Business Solutions unit supports insurers who sell both traditional and nontraditional products, though this blog post will focus on the on-demand insurance product space.
Is licensing technology to other insurers a common thing for insurers to do?
There are definitely core system vendors that started out as a single insurer’s homegrown product before spinning out, though this was more common a couple of decades ago. Metromile is not the only startup carrier that has augmented its income by licensing its technology. A somewhat recent example is Arity, the telematics data company, that started out as an internal Allstate unit before becoming an independent entity.
The key here is that insurers are usually more comfortable licensing technology from a pure vendor than one of their competitors. There was pushback about the Lemonade acquisition from insurers using the Metromile technology.
Why were insurers okay with licensing technology from Metromile but not from Lemonade? Aren’t they both competitive insurers?
Great question! One difference is that Metromile was primarily focused on selling pay-per-mile auto insurance, which is a distinct product from what most auto insurers sell. Other insurers may have felt less directly competitive because of that. Lemonade talks about leveraging emerging and AI-based technologies for its process and automation, but, unlike Metromile, it sells traditional products which compete more directly with other insurers.
Why can’t insurers just use their existing core systems to sell nontraditional/continuous underwriting products?
An on-demand product requires rethinking most of the enterprise value chain and technology support. A pay-per-mile auto insurance product, for example, might mean ingestion of a continuous data feed (the driving miles) into the policy admin system, a billing system that supports variable bills based on that data, and a claims system that can validate miles were being tracked and covered during the time of an accident. It also means new rate models, creating and filing new policy documents, and other legal/business changes outside of the technology itself.
Any insurer wanting to enter this nontraditional, on-demand product space can take one of three technology approaches (with variations):
- Configure/customize its existing system(s) to support the new on-demand product.
- Buy/build a new system to run side-by-side with its existing system to support the new on-demand product.
- Buy/build a new system that will support both its traditional product(s) and its new on-demand product.
How come “traditional” core system vendors aren’t doing more to support on-demand insurance products? Why do insurers have to get this tech from startups?
Core system vendors are doing a lot to support on-demand insurance products! (EIS’s acquisition of Metromile Enterprise Business Solutions is just one example.) Support for on-demand is clearly part of the roadmap for many core system vendors, and the expectation is that in the future this will be a more standard set of capabilities in the space. The good news is that one day soon, most insurers will be able to go with the third option above.
However, it’s not easy. For all the same reasons insurers can’t just use a legacy platform to support on-demand insurance, core system vendors have to put in real work to build out these capabilities.
Is this something insurers even care about?
This is the toughest question to answer. On-demand insurance represents a very, very small percentage of all insurance policies, at least in North America. Even when looking at digital/startup insurers, very few of them are doing true product innovation. Metromile, the grandfather of startup carriers and a flag bearer for on-demand insurance, is no longer an independent entity.
In order to answer, “Is this this something insurers even care about,” we have to ask several other questions. Do existing core systems not support on-demand products because insurers don’t care about them? Or do insurers not sell more on-demand insurance products because their current core systems don’t support them? Or do insurers not sell—and vendors not support—these products because insurance buyers don’t want them?
Regardless of why, the answer today is that, no, on-demand insurance is still very niche and has low overall penetration (with a few specialty product exceptions). Most insurers are focused on enhancing their technology to support traditional products using better data, AI, and automation rather than overhauling their technology to sell different types of products entirely.
That doesn’t mean on-demand products won’t grow in the marketplace over time, getting more and more penetration with insurance buyers. Vendors who are investing in support for on-demand and nontraditional products may be targeting limited insurer interest, but this is an investment for future growth. And when insurers buy a new core system, they are looking for a partner for the coming decades and want a vendor who not only supports their current business but also potential future business needs.
To discuss on-demand insurance strategy further, please reach out to me at [email protected].