Case Study 2: Embedded Insurance — Where the Model Works, and How a Program Goes Wrong

A note on this case. Embedded insurance is real, public, and growing — trip insurance offered at flight checkout, device protection sold with electronics, freight and delivery cover offered inside logistics platforms, small-business cover offered inside the software those businesses already use, and rental-car and ride-share waivers are all everyday examples you have encountered. Because the specific terms and loss results of individual embedded programs are mostly private commercial arrangements, the failure half of this study is presented as a clearly-labeled composite built from real, well-documented industry patterns (program business, class underwriting, and adverse selection), not from any one named program. No statistic is invented; the composite illustrates a mechanism, not a specific company's results.

Background

If Case Study 1 is the cautionary tale of InsurTech's hardest failure — the full-stack bet that technology could repeal the loss ratio — embedded insurance is the complementary story of where the InsurTech idea genuinely worked. Its insight, as the chapter laid out (§34.2), is not about underwriting risk better; it is about distribution. The most expensive, frustrating thing in personal and small-commercial insurance is customer acquisition: finding a person who needs cover at the precise moment they will actually buy it. Embedded insurance solves that by attaching the offer to a purchase that already commands the customer's attention, their decision, and their payment details — the flight, the phone, the freight shipment, the software subscription.

Done well, the model is elegant from every angle. The customer gets relevant cover at the exact moment of need, with no separate shopping trip. The platform (the airline, the retailer, the logistics company) earns a commission and offers its customers a useful feature without becoming an insurer. And the carrier (or its digital MGA) reaches a large, qualified population at a fraction of the usual acquisition cost. Because the technology can deliver the offer through an API (§34.4) inside the platform's checkout, the whole thing happens in the existing purchase flow, in seconds, at scale. This is one of the InsurTech wave's most durable contributions, and it has been adopted by incumbents and InsurTechs alike.

The insurance / underwriting issue

Here is the part that matters to an underwriter, and it is the part the elegance can obscure: embedded insurance does not remove the underwriting; it relocates it upstream into the design of the program, and an error there is an error made automatically across an entire population.

When cover is embedded, there is usually no individual selection — every qualifying customer who buys the phone or the trip gets the same offer at the same price with the same terms. As the chapter put it, this is a return at scale to class underwriting (Chapter 20): you are not pricing the individual, you are pricing the class of everyone who buys through this platform under these terms. The underwriting work — all of it — moves to the one-time negotiation between the carrier and the platform, where four things get decided:

• Who is in the embedded population, and what is their risk? The customers of one platform are not the customers of another. A premium electronics retailer's buyers may handle their devices very differently from a discount marketplace's; a business-travel booking tool's trips differ from a budget-leisure site's. Misjudge the population and you have mispriced the whole class.
• Do the terms invite adverse selection? This is the live danger. If the embedded offer is optional and priced as a flat add-on, the customers who opt in skew toward those who expect to use it (Chapter 1) — exactly the "two applicants, one price" problem from Chapter 1, now running automatically at every checkout. The customer who knows they are hard on their phone, or whose trip is shaky, is likelier to tick the box.
• How is the program monitored? Because there is no per-risk underwriting, the only way to know the program is performing is to watch its aggregate loss ratio as it develops — and to have agreed, up front, on the triggers that reprice or pull the program if the experience deteriorates.
• What is the carrier's exposure to the platform's incentives? The platform earns commission on take-up and wants the offer ticked as often as possible; the carrier bears the losses. That is the same misalignment the chapter flagged in the MGA model (§34.2), and it shapes how aggressively the platform will push the offer and on what terms.

What it shows

The success cases show that InsurTech's real genius was distribution, not risk-bearing — that attaching a sensible, well-priced program to a genuine moment of need is a durable model precisely because it leaves the carrying of insurance risk on a balance sheet built for it and adds technology only to the front door. The failure mode — illustrated by the composite below — shows the flip side: that automating distribution without disciplining the program design is a way to make the same underwriting mistake thousands of times before anyone reads the loss runs.

Composite: "the optional protection plan that selected against itself" (clearly-labeled composite — illustrative mechanism, not a real company)

A carrier partners through a digital MGA with a large online marketplace to embed an optional protection plan on a popular category of consumer goods. The plan is a flat-price add-on, pre-ticked at checkout with an easy opt-out, and the platform — paid a commission on take-up — promotes it hard. For the first several quarters the program looks wonderful: take-up is high, commission and premium flow, and the immature loss experience looks benign. Then the claims develop. Two things have happened at once. First, because the plan was optional and flat-priced, the customers who actively kept it (rather than opting out) skewed toward those who expected to need it — adverse selection, automated at every checkout. Second, the population itself was harder on the product than the pricing assumed, because the program was priced against a generic class rather than against this platform's customers. The aggregate loss ratio comes in well above plan. Because no individual underwriting ever occurred, there was no per-risk check to catch it; the only signal was the developing book, and the repricing trigger — if one was even negotiated — fires too late to undo a year of mispriced volume.

The fix is entirely upstream and entirely underwriting: price the program against the actual embedded population, design the offer to dampen adverse selection (consider whether flat-price optional cover is the right structure at all), negotiate hard repricing and exit triggers tied to the developed loss ratio, and audit the program's experience continuously. None of that requires slowing the customer's checkout by a millisecond. All of it is the underwriting that the speed of the embedded flow tempted everyone to skip.

Outcome

In the real, well-run version of embedded insurance, the outcome is a stable, mutually profitable program: the carrier prices the class correctly, builds in monitoring and repricing triggers, and the partnership runs for years as a genuine win for customer, platform, and insurer. Embedded distribution has become one of the most-discussed growth areas in the industry for exactly this reason, and it is being pursued by incumbents and InsurTechs together. In the composite failure version, the outcome is a program that is wound down or sharply repriced once the loss experience matures, a strained carrier-platform relationship, and an expensive lesson that the speed and scale of the embedded model amplify whatever underwriting judgment — good or bad — is encoded into the program at the start.

Lesson

The lesson pairs with Case Study 1 to bracket the whole chapter. Case Study 1 taught that you cannot outrun the loss ratio with a low expense ratio; this one teaches that you cannot escape underwriting by automating distribution — you only relocate it, and you raise the stakes of getting it right. Embedded insurance is a real and durable InsurTech success precisely when the underwriting is taken seriously at the program level: the population priced honestly, the structure designed to resist adverse selection, the experience monitored, and the repricing triggers real. The technology makes the distribution fast, cheap, and scalable. It does nothing to make the underwriting easy — and because every decision is made once and applied to thousands, the underwriting at the program level is more consequential, not less. Speed at the front door is a gift; it is not a substitute for the judgment behind the program, and an underwriter who forgets that will discover, at scale and on a delay, that the automated offer was selling against itself the whole time.

Discussion questions

1. Embedded insurance is described as an innovation in distribution, not in risk-bearing. Explain the distinction, and why it makes embedded insurance a more durable model than the full-stack carrier bet of Case Study 1.
2. The chapter says embedded cover turns underwriting into class underwriting (Chapter 20) that "moves upstream." Walk through the four things that get decided in the carrier-platform negotiation, and explain why an error in any of them is an error "made automatically across an entire population."
3. In the composite, an optional, flat-priced, pre-ticked protection plan selected against itself. Trace the adverse-selection mechanism step by step (Chapter 1), and propose two changes to the program's design that would dampen it.
4. The platform earns commission on take-up; the carrier bears the losses. Identify the misalignment of incentive (which earlier chapter named it?), and explain how it shapes the terms a disciplined carrier should insist on before embedding.
5. There is no per-risk underwriting in an embedded program, so the only performance signal is the developing aggregate loss ratio. Why does this make the repricing and exit triggers — and the timing of the loss development — the most important things to negotiate up front?
6. Reconcile the two case studies into a single sentence an underwriting committee would accept about what InsurTech did and did not change. (Hint: distribution versus the loss ratio.)