Saverio and Livia are announcing Insurteam today. The platform takes a travel insurance claim from first notice of loss to a settlement decision without human intervention on qualifying claims. This post explains the problem that led us here, what the platform does, what it does not do, and where we think this goes.
The problem, as we kept running into it
Saverio spent eight years working in insurance data systems and claims operations before founding Insurteam. Livia spent hers building extraction pipelines for financial-services documents. The problem we kept running into, from different angles, was the same: travel insurers are running a manual claims operation at a scale that manual processing was not designed to handle.
A mid-size travel insurer writing 400,000 policies per year will generate somewhere between 30,000 and 80,000 flight-delay claims in a typical year. Each claim, under current operations, requires a human adjuster to retrieve the policy, read the relevant clauses, pull the flight operational data, verify the delay threshold, apply the benefit schedule, and trigger payment. The adjuster cost is real, and it scales linearly with volume.
The economics worsen at the bottom of the claim size distribution. Average payout for a standard flight-delay claim runs CHF 80 to 300. On the lower end of that range, handling cost as a share of benefit amount is significant. Insurers generally absorb this because travel insurance is a volume business and the alternative was not available. They cross-subsidise the claims operation from higher-margin lines and accept the situation as structural.
What changed is the technology stack. Three things have converged: flight data infrastructure that now provides commercial-grade operational records at the level of completeness needed for automated decisions; language models with document understanding that, properly architected, can extract structured coverage logic from insurance policy documents with sufficient reliability to drive decisions; and orchestration tooling that lets you build reliable pipelines connecting those components. None of these existed at the required maturity level five years ago. The combination now makes a fully automated pipeline technically feasible for standard travel claim types. The question was whether it could be built to production reliability. That is what we spent our time as a team answering.
What Insurteam does
The platform receives a first notice of loss submission from the insurer's intake channel. It calls the relevant flight data feeds to verify the reported event against operational records. It extracts the coverage logic from the policy document using a multi-pass extraction pipeline built specifically for travel insurance policy structures. It evaluates coverage against the extracted clause logic and the verified event data. It produces a structured settlement decision.
For qualifying claims, where the event verification is conclusive and the extraction confidence meets the threshold, the platform can instruct settlement payment without any adjuster interaction. The claim closes before most policyholders have landed home. For claims that fall outside the automated track, because the event is within the confidence window around the threshold, or because the extraction encountered an unusual policy structure, the platform routes the claim to the adjuster queue with a fully pre-populated case file. The adjuster reviews the extraction output and makes a decision in two to three minutes rather than starting from a blank screen.
The current scope covers flight-delay claims, missed-connection claims, and flight-cancellation claims. These are the three highest-volume travel claim types that share the property of being verifiable against external data sources. Trip interruption claims and medical claims are on the roadmap; they require assessment components that we are developing separately and will integrate into the pipeline when they are ready for production use.
What we are and what we are not
Insurteam is claims automation tooling for travel insurers. We are not a licensed carrier, underwriter, or insurer. We do not sell policies, bind coverage, or carry insurance risk of any kind. Every coverage determination our platform produces is an application of the insurer's own policy logic to verified event data. The insurer retains full authority over settlement decisions and full regulatory responsibility for the claims operation. Our role is to do the time-consuming mechanical work that an adjuster would otherwise do, at the point in the workflow where that work is mechanical and rule-bound.
We are also not a generic insurance technology platform trying to serve every line of business from day one. We built specifically for travel claims automation because that is where the technical case is strongest, the economic improvement is clearest, and the feedback loop from production data is fast enough to calibrate and improve the system on a reasonable timeline. Doing one thing to a standard where insurers can trust their claims operations on it is the right foundation before expanding scope.
Who the right early deployment looks like
The platform is designed for travel insurers and their claims teams. The right first deployment is an insurer handling at least 20,000 travel claims per year who has a defined claims SLA they want to improve and an interest in reducing per-claim handling cost. At that volume, the economics are compelling and the operational data from the deployment is rich enough to calibrate the pipeline to the insurer's specific policy product mix.
We are not targeting the largest global carriers first. We are building with insurers where we can work closely enough to get the integration right, understand the policy structures in detail, and move quickly when something needs adjustment. The production data from those deployments is what enables us to expand scope and improve accuracy over time.
What we are publishing next
This blog will track our technical and operational findings as we move from launch into production deployments. We will write about what actually happens when LLM extraction meets real policy documents at scale: where it works well, where it needs improvement, and how the calibration process works. We will write about integration patterns for different core system architectures and what the adjuster experience looks like when the pipeline prepopulates a case file versus when they are starting from scratch.
If you are evaluating claims automation for a travel portfolio, the most useful starting point is a demo. It covers a real flight-delay claim from FNOL intake through to a settled decision in real time, using a sample policy document and flight data. You can see exactly where the extraction runs, what confidence scores are produced, and what the case file looks like when it routes to the adjuster queue.
