Embedded Insurance APIs: Governing the Distribution You No Longer Directly Control

When you sell insurance through someone else’s checkout, the sale happens on their screen, in their flow, under their brand — but the conduct obligation is still yours.

Embedded insurance is the arrangement where a travel site, a retailer, a car marketplace or a fintech app offers cover at the point of buying something else, and the underlying policy is placed with — or manufactured by — a regulated insurer over an API. The insurer, or the intermediary standing behind the product, remains the manufacturer and often the distributor of record. The platform is the surface the customer touches. That split is the whole problem: the regulatory duties attach to the product and its distribution, not to the domain name in the address bar.

What the API actually distributes

An embedded-insurance API is usually described as a quoting and binding interface — send risk attributes, receive a price, post a purchase, get a policy. Read it as a distribution channel and a different picture emerges. Every field the partner renders, every screen they build around your JSON, and every default they set is an act of insurance distribution under Directive (EU) 2016/97, the Insurance Distribution Directive, which has applied across the EU since 1 October 2018. The IDD does not care that the code runs on the partner’s server. It cares that a customer was sold a policy, and that the sale met the standard in Article 17 — acting honestly, fairly and professionally in accordance with the customer’s best interests.

Two concrete duties travel with that sale. Article 20 requires a demands-and-needs assessment and, for non-life products, that the customer receives an Insurance Product Information Document — the IPID, whose standardised format is fixed by Commission Implementing Regulation (EU) 2017/1469 — before the contract concludes. Article 24 governs cross-selling: where the cover is bundled with the flight or the phone, the customer must be told the components can be bought separately and shown the costs. If your API returns a price and a bind token but no structured way to deliver the IPID, run the demands-and-needs logic, or surface the cross-selling disclosure, you have shipped the revenue and left the obligation on the customer’s side of an integration you do not monitor.

The exemption that is not an escape hatch

Many embedded programmes are built on the assumption that the platform is an ancillary insurance intermediary and therefore out of scope. The exemption in Article 1(3) is real but narrow. It applies only where the cover is genuinely complementary to the good or service, and where the premium does not exceed EUR 600 on a pro-rata annual basis, or EUR 200 per person where the underlying service lasts three months or less. Cross those thresholds — and annualised subscriptions and richer behavioural add-ons cross them easily — and the platform needs registration and the fuller conduct regime engages.

Even inside the exemption, Article 1(4) keeps a floor in place. The insurer or the intermediary behind the product must still ensure the customer is told who they are dealing with and how to complain, that a demands-and-needs check happens, and that the IPID is provided before conclusion. There is no configuration of embedded insurance in which the disclosure and suitability duties simply vanish. The exemption changes who registers; it does not delete the obligations. It merely makes it more likely that the party responsible for them — you — is not the party controlling the screen where they are meant to be discharged.

Put the control model in the contract and the payload

The governing instinct is to write the obligations into a distribution agreement and consider them handled. That is necessary and not sufficient. A clause that says the partner “shall comply with applicable insurance distribution law” is unenforceable in any operational sense, because you cannot see whether the flow they built actually delivered the IPID or ran the demands-and-needs test. The control has to be expressed where it can be observed: in the API contract itself.

That means the integration specification — not the legal annex — carries the requirements. The bind endpoint should refuse to issue a policy unless the payload confirms the IPID was presented and the demands-and-needs response captured; disclosure text and its version should be fields the partner must echo back, not assets they render at their discretion. This is where designing the interface deliberately pays off, and it is an argument for treating the contract as a first-class artefact — the discipline behind spec-first API development — rather than something reverse-engineered from working code. The same product-oversight logic that Article 25 and Commission Delegated Regulation (EU) 2017/2358 demand of manufacturers — defining the target market and the distribution strategy, and drawing information back from distributors — has a technical expression: the API is where the target market and the distribution strategy are enforced, and where the return flow of distribution data begins. Turning product oversight and governance into a product-data control rather than a committee minute is exactly the move embedded distribution demands.

Monitor what the partner actually does

The last gap is behavioural. A partner can pass every field on day one and quietly change their checkout six months later — reorder screens, pre-tick the cover, drop the separately-purchasable disclosure to lift conversion. Nothing in your systems breaks; the bind calls keep arriving. From a supervisor’s point of view the distribution has degraded, and you own it. Governing an embedded channel therefore includes sampling live journeys, watching the metrics that reveal pressure selling — attach-rate spikes, cancellation windows never exercised — and holding a contractual and technical right to suspend the integration when the numbers say the flow has drifted. The data these partners feed back, including any behavioural or telematics signals used to price, carries its own control burden; governing that sensor pipeline is a related discipline, not an afterthought.

There is a data dimension underneath all of this. The customer’s details flow across the boundary in both directions, which makes the controller-and-processor mapping a live question rather than a boilerplate one. If the platform decides what data to collect and how the offer is shaped, joint controllership is on the table, and the transparency and rights obligations follow the data across the API just as the conduct duties follow the sale. A distribution deal that never resolves who is controller for which processing has left a GDPR gap sitting in the same place as the IDD one.

Who this is for

• Insurers and MGAs building embedded programmes who remain the manufacturer or distributor of record while a platform owns the point of sale.
• Product and engineering leads designing quote-and-bind APIs that need to carry conduct obligations, not just pricing.
• Compliance owners who hold the IDD liability but do not control the partner’s checkout.

The uncomfortable truth of embedded insurance is that you have outsourced the moment of sale to a partner optimising for their conversion rate while keeping the regulatory liability for how that sale is made. The only defensible answer is to make the control model something the API enforces and you can watch, because a duty you cannot observe being met is a duty you are already failing.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.