When we built SanctionsCheck, we had a simple design principle: the check has to happen inside other people's workflows. Not in a separate tab. Not in a portal someone logs into once a week. Not as a manual step that gets done when someone remembers to do it. Inside the workflow, at the moment the need arises, with the result returned immediately and the audit trail created automatically.

That principle led us to an API-first architecture from day one. You call an endpoint. You pass in a name and a jurisdiction. You get back a result, a risk score, and a reference you can attach to the record. The whole thing takes less than a second.

We built it this way for compliance reasons, largely. AML sanctions checks under Australian and Lloyd's obligations are not optional events that can be batched and reviewed later. They need to happen before a risk is bound. The only way to reliably ensure that happens is to make the check so frictionless that doing it requires less effort than skipping it. An API achieves that. A portal does not.

What we did not fully anticipate, in 2022 when we were designing this, was that we were also building for a distribution landscape that did not yet exist.

The AI agent uses your API, not your portal

In February 2026, Tuio and Insurify launched the first insurer-built applications inside ChatGPT's app directory. Aviva followed weeks later. These apps allow users to receive a rated, real-time insurance quote — and in some cases complete a purchase — without leaving a conversation interface. For the first time, AI agents could access live insurance product data, rather than drawing on static web content.

The technical precondition for all of these launches was the same: a real-time API capable of delivering a quote in response to a structured query. Tuio could put its product inside ChatGPT because its entire rating engine was exposed through an API. If the quote flow had required a human underwriter to review a submission, or a portal login, or a form submission and email response, the app would not have been possible.

This is the specific implication of building API-first that most insurance businesses have not yet fully internalised. APIs are not just an integration convenience. They are a distribution surface. When a new channel emerges — a ChatGPT app, an AI agent acting on behalf of a buyer, an embedded insurance partner, an automated procurement system — the businesses whose products are accessible via real-time API can participate. The ones who require human intervention at the quote stage cannot.

WaniWani, the AI distribution infrastructure provider behind Tuio's ChatGPT app, reported that AI was driving close to 20 per cent of new business for leading digital insurers before native apps existed. ChatGPT alone was accounting for around 15 per cent of website traffic among surveyed visitors. That is a meaningful distribution channel that was operating through an AI layer before anyone had explicitly built for it. The businesses capturing that traffic were doing so because their products were reachable via API.

What most insurance APIs actually are

There is a difference between having an API and being API-ready for AI distribution.

The 2024 Insurance API Index found that 86 carriers were already offering API-enabled products, and by mid-2025 more than 75 per cent of insurance firms had embedded APIs into their digital operations. Those numbers suggest the industry is well ahead of the problem. The reality is more complicated.

Most insurance APIs are integration points — connections between internal systems, or between a carrier and a specific partner who has been onboarded and credentialed for a specific purpose. They are not open distribution endpoints. They require pre-negotiated access, custom authentication flows, and often bespoke data mapping that takes months to implement for each new partner.

That kind of API is useful. It is not the same as an API that an AI agent can call on behalf of a buyer in real time, without pre-negotiation, at the moment the need arises.

The comparison I find useful is banking. Open Banking in Australia, now embedded in the Consumer Data Right framework, created the obligation for banks to expose customer data through standardised, consented APIs — not just internal integration points. The same standardisation pressure is coming to insurance, and it is being accelerated by AI distribution. An insurer whose product is accessible only through a proprietary, bespoke integration is increasingly invisible to the channels where buying decisions are being made.

What SanctionsCheck taught us about making compliance frictionless

The sanctions screening problem is instructive for insurance product design more broadly, because it is a microcosm of the same dynamic.

Before purpose-built sanctions APIs existed, the workflow at most insurance businesses looked like this: underwriter receives submission, underwriter opens a browser tab, underwriter searches the DFAT Consolidated List or OFAC database, underwriter documents the result somewhere, underwriter proceeds. Or — more often in practice — underwriter proceeds, and the documentation happens later, or not at all.

The problem was not that people did not understand their obligations. Under Australian sanctions law and Lloyd's MS11, sanctions screening is mandatory. The problem was that the workflow was friction-heavy enough that it competed with the actual underwriting work that the business was paying for.

An API removes that competition. The check happens automatically, at the right moment in the workflow, and the result is attached to the record without any additional effort. The audit trail is complete. The compliance obligation is met. And the underwriter's attention is not diverted.

The same logic applies to any insurance workflow that involves a repeatable, rules-based task: quote generation, eligibility checking, document analysis, claims first response. Making these tasks accessible via API does not just improve efficiency. It changes what is possible. An AI agent can call an API. It cannot fill in a form.

The infrastructure investment that pays twice

There is a reasonable objection to the API-first argument: the upfront investment is significant. Building and maintaining production-grade APIs requires engineering effort, security architecture, documentation, and ongoing support. For a small-to-medium insurer or MGA, that is not a trivial commitment.

The counterargument is that the investment pays twice.

The first payoff is internal. Clean API architecture forces the kind of data discipline that makes AI useful inside your own operations. If your product data is structured well enough to be exposed through an API, it is structured well enough for AI to operate on it in underwriting, claims, and compliance workflows. BCG's January 2026 analysis of P&C insurers found that AI-assisted intake and pre-fill can cut time-to-quote by 30 to 40 per cent — but only for organisations whose data is clean and accessible enough for AI to act on it.

The second payoff is distribution. Every new channel that emerges over the next five years — AI agents, embedded insurance partnerships, automated procurement, agentic customer journeys — will require real-time API access. Building that capability once means being ready for each new channel as it arrives, without a separate integration project for each one.

Softtek's 2026 insurance technology analysis described this transition succinctly: "the composable approach" — externalising key capabilities like pricing, eligibility, and fraud into accessible services while keeping the policy system as the system of record — is what allows AI to be introduced into insurance workflows without breaking existing operations. The API layer is the bridge.

The practical question

For any insurance business reading this, the test is simple: can your systems deliver a rated quote to a third-party platform, in real time, today?

If the answer is yes, you are ahead of most of the market and the question becomes how to make that capability discoverable to AI distribution channels.

If the answer is no — if a quote requires a human in the loop, or a pre-negotiated integration, or a form submission — then the infrastructure gap is the priority. Not because AI distribution is destroying your business tomorrow, but because each new distribution surface that appears will require this capability, and building it takes time.

We built SanctionsCheck's API architecture because it was the right way to solve a compliance problem. It turned out to also be the right architecture for a world where AI agents are the next generation of distribution infrastructure. We got lucky on the timing. Most businesses will not have that luxury.

The API is not a technical detail. It is a distribution strategy. Build it accordingly.

Sources: WaniWani distribution data (Feb 2026), FinTech Global / Tuio launch (Feb 2026), Insurance API Index (2024), BCG AI-First P&C Insurer (Jan 2026), Softtek Insurance 2026 Analysis (Jan 2026), DFAT sanctions obligations, Lloyd's MS11