AI agents for travel insurance claims: the flight-delay payout the agent can own, and the adjudication it can't

Two travelers file two claims on the same bad-weather Tuesday. The first had a flight delayed three and a half hours; her policy pays a fixed benefit the moment the delay clears a threshold, verified against a flight-status feed, and the money lands before she’s off the jet bridge. She never filled in a form. The second lost a checked bag; his claim needs the airline’s irregularity report, an itemized list, proof he owned the things, and a human to decide whether the policy covers them and for how much. Three and a half weeks, not three and a half hours.

That contrast is the entire thesis of automating travel claims. One of those claims is parametric (an objective trigger, an objective data source, a pre-agreed payout, no judgment required) and an agent can own it end to end. The other is indemnity (actual loss, documentation, coverage interpretation, a regulated decision) and an agent can do a great deal of the work around it while touching none of the decision. Get that line right and you automate the high-volume, low-value flood that swamps a travel-claims team every weather event; get it wrong and you’ve either left the easy money on the table or handed a coverage decision to a language model. This post is where the line goes, and how to build both sides of it on Salesforce.

We’ve written about the generic insurance-claims agent for P&C, the auto-accident FNOL on Insurance Cloud, and about airline disruption re-accommodation when the schedule itself breaks. Travel insurance is a different animal from both: high-volume, low-value, weather-correlated, and split down the middle by that parametric-versus-indemnity seam that has no P&C-auto analog.

Why travel claims are a distinctive agent problem

Travel claims cluster and they’re small. When a storm system grounds a hub, thousands of delay and baggage claims arrive in the same forty-eight hours, exactly when adjuster capacity is most strained, and many of them are worth less than it costs to adjudicate them by hand. The volume is weather-driven and lumpy; roughly one in four US flights ran late or was canceled across the year to mid-2025, and every one of those is a potential delay or missed-connection claim. Meanwhile the customer who bought “travel protection” as a checkout add-on expects the protection to feel instant, and the industry’s actual cycle time, commonly two to four weeks for a documented claim, is the gap that erodes trust and drives switching.

The economics point straight at automation, and the data says the money is moving. Squaremouth’s analysis of 2024 travel-insurance claims found paid claims rose 18% year over year while the average payout jumped 37%, from about $1,900 to $2,609, and, for the first time in over a decade, emergency medical became both the most frequent and the most-paid benefit, at roughly 27% of all paid claims. Trip cancellation, interruption, and cancel-for-any-reason together still made up over 40% of paid claims, and travel-delay claims rose 15%. That’s a rising volume of mostly-routine work with a fat tail of consequential medical claims, the classic shape where an agent absorbs the routine load so humans can spend their judgment where it matters.

The line that decides everything: parametric vs indemnity

Before any Salesforce object, internalize the split, because it’s the design.

Parametric (fixed-benefit) claims pay a pre-agreed amount when an objective, third-party-verifiable trigger fires, a flight arrival delayed beyond a set number of hours, commonly in the 90-minute-to-two-hour range depending on the product. There’s no proof of loss, no receipts, no coverage interpretation: the delay either cleared the threshold or it didn’t, and a flight-status feed settles it. This is the segment an agent can drive end to end. The canonical early example, AXA’s “Fizzy,” used a smart contract to auto-pay flight-delay benefits back in 2017 (and was discontinued around 2019 for lack of demand); the mechanism has since matured into parametric-as-a-service offerings from vendors like Blink Parametric. The point isn’t the blockchain plumbing. It’s that when the trigger is objective and the data is external, adjudication is just verification, and verification is exactly what an agent does well.

Indemnity claims pay the actual loss and require judgment: trip cancellation and interruption, baggage loss and damage, emergency medical, medical evacuation. These need documentation, coverage interpretation, refund-offset math, and, for any denial, a licensed decision-maker. An agent can take the first notice of loss, capture and read documents, check completeness, look up coverage, and route the file. It cannot decide whether the loss is covered or how much to pay. That decision sits behind the regulated line described below.

The single most useful thing you can do before building is to tag each benefit line in your book as parametric or indemnity, because that tag decides which agent pattern applies. Everything downstream (the workflow, the automation ceiling, the human touchpoints) follows from it.

The parametric path: an agent that pays before you ask

For a covered parametric trigger, the agent is best modeled not as a chatbot at all but as an event-triggered agent, one that acts on a signal, not a customer message:

Detect the trigger. A flight-status feed (Cirium’s FlightStats data, or a competitor like VariFlight) reports the actual arrival delay for an insured itinerary. The event, not a customer, wakes the agent.
Verify against the policy. The agent confirms the itinerary is insured, the trigger threshold is met, and the benefit hasn’t already been paid, the deterministic checks that keep a payout clean.
Pay within the pre-approved threshold. For a fixed benefit below a set amount, the agent initiates the payment and notifies the traveler, often before they’ve registered the problem themselves.

That’s a autonomous loop, and it’s safe because it’s bounded: an objective trigger, an authoritative external source, a fixed amount, a ceiling above which it escalates. The honest caveat is basis risk, the parametric trigger may not match the traveler’s real experience (the delay cleared two hours but they still made their connection, or missed it by minutes under the threshold). That’s a product-design limitation, not something the agent can fix, and it’s why parametric sits alongside indemnity cover rather than replacing it.

The indemnity path: intake everything, decide nothing

For everything else, the agent runs the front of the claim and stops at the decision. The workflow, and who acts at each step:

Take the FNOL. The agent opens the claim, identifies the policy, confirms coverage is in force on the loss date, and captures the structured facts for the claim type, the same first-notice-of-loss job the P&C agent does, adapted to travel’s benefit lines.
Collect and read the documents. Each benefit line needs specific evidence (the table below). The agent requests exactly what’s required, ingests uploads, and extracts fields with document reading so a human isn’t re-keying a hotel receipt.
Run completeness and coverage look-ups. The agent checks the file is complete, surfaces the relevant policy terms and limits, and computes what it can deterministically, including the travel-specific refund offset.
Route with the case built. Complete, in-policy, low-value claims within pre-approved rules can be fast-tracked; anything high-value, ambiguous, or flagged goes to a human with the file already assembled, not a blank screen.

Note what’s missing from that list: approve, deny, set the reserve. Those aren’t in the agent’s lane.

Claim types and the documentation the agent must collect

Claim type	Trigger	Core documentation the agent captures
Trip cancellation	Covered reason before departure	Itinerary; proof of prepaid non-refundable costs; supplier cancellation confirmations; proof of refunds already received; reason evidence (e.g., medical note)
Trip interruption	Covered reason after departure	As cancellation, plus unused-portion proof and extra return-transport receipts
Travel delay	Delay ≥ policy threshold	Written delay confirmation from the carrier stating the reason; itinerary; meal/lodging/transport receipts
Missed connection	Missed onward leg from a covered delay	Delay/cause documentation; new ticket and boarding pass
Baggage delay	Bag delayed by carrier	Carrier delay report / PIR; receipts for essential replacements
Baggage loss / damage	Bag lost or damaged	PIR; itemized list; proof of ownership; valuations
Emergency medical	Illness/injury on trip	Itemized medical bills and records; completed claim form; authorization to release information
Medical evacuation	Medically necessary transport	Pre-authorization from the assistance company; medical reports; transport invoices

The travel-specific detail a generic claims agent gets wrong

Three things separate a travel-claims agent from a repurposed P&C one, and skipping them produces subtle, expensive errors:

The PIR is non-negotiable for baggage. A Property Irregularity Report, the number the airline’s baggage desk issues into the WorldTracer tracing system, is the formal record a baggage claim stands on. No PIR, and the airline (and downstream, the insurer) can reject the claim for lack of a formal report. The agent’s job on any baggage claim is to confirm the PIR exists and capture its number first; everything else is secondary.
The supplier-refund offset. Travel insurance covers the net non-refundable loss. If the airline already refunded part of the fare or the hotel waived a night, the payout is reduced accordingly, an adjudication step with no analog in P&C auto. An agent that captures “trip cost” without capturing “refunds already received” sets up an overpayment on every cancellation claim. This offset is exactly the kind of deterministic math the agent should compute and surface, so a human isn’t doing arithmetic the system can do.
Assistance is not a claim. The 24/7 assistance desk that arranges a medical referral or coordinates an evacuation is a service, distinct from the reimbursement claim, and arranging a service doesn’t guarantee the cost is covered. Critically, medical evacuation typically requires pre-authorization by the assistance company; a traveler who pays out of pocket without that approval often forfeits the claim. An agent working these cases has to know the difference between coordinating help now and adjudicating reimbursement later, and never imply the second because it did the first.

Fraud, and why thresholds and humans stay in the loop

Travel is a soft target for claims fraud, and the reason is structural: there’s no shared cross-insurer claims database, so the same loss can be filed with multiple carriers and caught only through shared contact, payment, and device metadata. Baggage is the most-abused line: inflated contents, added items, pre-existing damage, sometimes fed by websites selling fake receipts. Industry bodies describe fabricated claims and value-inflation as widespread; UK figures from ITIJ reported detected fraudulent travel claims nearly doubling between 2023 and 2024, with an average fraudulent claim around £3,000: figures worth citing as the industry estimates they are, not universal facts, but directionally clear.

The control that makes automation safe is the auto-approval threshold: pay small, objective, complete claims fast; route anything high-value, anomalous, or matching a duplicate signal to a human. The agent is a superb first-pass filter (it can run duplicate and identity checks, flag date inconsistencies (a policy bought after the loss), and score completeness) but the judgment call on a suspicious claim belongs to an investigator. Speed on the clean claims funds the scrutiny on the dirty ones; it doesn’t replace it.

The line the agent never crosses

Travel insurance is regulated insurance, and coverage decisions carry legal weight. The NAIC’s Unfair Claims Settlement Practices Act, adopted in most states, enumerates prohibited practices like failing to investigate reasonably, failing to acknowledge and act promptly, and failing to affirm or deny coverage within a reasonable time, all enforced by state insurance commissioners. Claims adjusting is state-licensed work. So the boundary is bright:

The agent may: capture FNOL, gather and read documents, verify coverage-in-force, compute the refund offset, run fraud and duplicate checks, auto-pay purely parametric triggers within pre-approved thresholds, and keep the customer informed on time.
The agent may not: interpret ambiguous coverage, deny a claim, or set a reserve. Any denial or coverage determination must be made, or explicitly approved, by a licensed decision-maker, with the prompt acknowledgement and timely affirm/deny that unfair-claims rules require.

This is the human-in-the-loop discipline in a regulated setting: decide which decisions require a person, when they enter, and what they see. (One nuance worth flagging to compliance: parametric products sit awkwardly in insurance regulation written for indemnity cover, and treatment varies by jurisdiction. Worth confirming state by state rather than assuming the parametric path is unregulated.)

Where Salesforce fits

Built on Salesforce, the pieces map cleanly, with one honest caveat up front: there is no shipped “travel FNOL” template. Salesforce’s first-notice-of-loss capability ships in Auto and Property variants; a travel build configures the same underlying claims model, it doesn’t install a travel template.

The data model. Financial Services Cloud’s insurance model provides the objects:InsurancePolicy, InsurancePolicyCoverage, InsurancePolicyParticipant, and the Claim record that holds the claim number, report date, claim type, and status, with related claim-coverage and participant objects. Your benefit lines and the parametric/indemnity tag live here.
Guided intake. OmniStudio (OmniScript for the guided, validated FNOL flow, Integration Procedures for the server-side orchestration, FlexCards for the status and settlement UI) is the declarative layer for the intake experience across channels.
The agent. Agentforce hosts the service agent (Salesforce’s own insurance use case is the “Insurance Service Assistant”), with Flow and Apex invocable actions for the deterministic work: coverage checks, claim creation, the offset calculation. The parametric loop runs as a triggered agent off the flight-status event.
Grounding. Data 360 (renamed from Data Cloud in 2025) unifies the policy, the customer, and, via integration, the flight-status feed into the record the agent reasons over, so it grounds on real coverage terms rather than inventing a policy limit.
Documents. Einstein OCR / Intelligent Document Automation extracts fields from the receipts, PIRs, and medical bills travelers upload; for unstructured policy documents, Intelligent Context is the grounding path that reads them without hallucinating the terms.

The division of labor is the same one that makes any regulated agent trustworthy: the flight feed and the policy are the sources of truth; Data 360 grounds the context; Agentforce intakes, verifies, computes, and, for parametric only, pays; and a licensed human owns every coverage decision on the indemnity side. This is Financial Services work where the boundary is the product.

The failure modes that decide it

Treating an indemnity claim like a parametric one. The fastest way to a regulatory problem is an agent that “auto-approves” a documented claim it should only have intaked. The parametric/indemnity tag has to gate the automation ceiling, hard.
Missing the offset or the PIR. Both are silent errors: the claim looks complete and pays wrong. Build them in as required steps, not optional fields.
Stale or wrong flight data. The whole parametric path rests on the feed. A bad or delayed status read either pays a claim that isn’t owed or denies one that is; the trigger check has to read authoritative data at the moment of payment.
Over-promising instant payouts. Parametric feels instant; indemnity doesn’t, and shouldn’t. An agent that implies a documented medical claim will pay like a delay claim sets an expectation the process can’t meet, worse than setting none.

The takeaway

Travel claims are one of the clearest agent opportunities in insurance precisely because they split so cleanly. The parametric slice, flight-delay benefits triggered by objective data, is auto-payable, and an agent modeled as an event-triggered loop can own it inside pre-approved thresholds. Everything else is indemnity, where the agent intakes the FNOL, collects and reads the documents, verifies coverage, computes the supplier-refund offset, runs the fraud checks, and routes a complete file to a human who makes the coverage call, never the agent. Get the travel-specific details right (the PIR, the offset, the assistance-versus-claims line, the evacuation pre-auth), keep the licensed-adjuster boundary bright, and ground the whole thing on real policy and flight data in Data 360. Do that and the delayed traveler gets paid before she lands, the lost-bag claimant gets a fast, fair, human-checked answer, and the fraudulent one gets the scrutiny that speed on the honest claims paid for.

Understanding the basics

Can an AI agent process travel insurance claims automatically?

Partly, and the split is sharp. Parametric (fixed-benefit) claims, typically flight-delay cover that pays a set amount once a delay crosses a threshold verified by a flight-status feed, can be fully automated: no form, no adjuster, just an objective trigger, a coverage check, and a payment within a pre-approved ceiling. Indemnity claims (trip cancellation, baggage, medical, evacuation) cannot be auto-decided; they require documentation, coverage interpretation, and a licensed decision-maker for any denial. There, an agent can take the first notice of loss, collect and read documents, verify coverage, compute the refund offset, and route a complete file to a human, but it doesn’t approve, deny, or set the reserve.

What makes travel claims different from a normal insurance claim?

Three things a generic claims process misses. First, the parametric/indemnity split, a large slice of travel claims (flight delay) pays on an objective trigger with no adjudication. Second, travel-specific evidence and math: baggage claims stand on a Property Irregularity Report (PIR) from the airline’s WorldTracer system, and payouts are net of any supplier refunds already received (the refund offset). Third, the assistance-versus-claims distinction: the 24/7 desk that coordinates a medical evacuation is a service, usually requiring pre-authorization, and separate from the reimbursement claim. A repurposed P&C-auto agent gets all three wrong.

How do you stop an AI agent from paying fraudulent travel claims?

With auto-approval thresholds and human review, not full autonomy. Travel is exposed to fraud because there’s no shared cross-insurer claims database, so duplicate claims across carriers are caught only through shared metadata. The pattern that works: let the agent pay small, objective, complete claims fast while it runs duplicate and identity checks, flags date inconsistencies (a policy bought after the loss), and scores completeness, and route anything high-value, anomalous, or matching a fraud signal to a human investigator. Baggage claims, the most-abused line, warrant particular scrutiny. Speed on the clean claims funds the scrutiny on the suspicious ones.

What Salesforce products build a travel-claims agent?

Financial Services Cloud’s insurance data model (InsurancePolicy, coverage and participant objects, and the Claim record) holds the policies and claims; OmniStudio (OmniScript, Integration Procedures, FlexCards) builds the guided FNOL intake; Agentforce hosts the service agent and the parametric triggered-agent loop, with Flow and Apex actions for coverage checks and the offset calculation; Data 360 grounds the agent on unified policy and flight-status data; and Einstein OCR / Intelligent Document Automation reads the receipts, PIRs, and medical bills. Note there’s no out-of-the-box travel FNOL template. Salesforce ships Auto and Property variants, so a travel build configures the same claims model rather than installing a ready-made template.

Building the travel-claims agent: the parametric loop that pays on an objective trigger, the indemnity intake that stops at the licensed-adjuster line, grounded on real policy and flight data? Talk to us. Drawing that boundary cleanly, and getting the PIR, the refund offset, and the fraud controls right, is exactly the work that makes an agent fast and safe rather than just fast. We do this kind of build across financial services.