Straight-through processing has been a goal in insurance operations for over two decades. The term appears in strategy documents, vendor pitches, and analyst reports with impressive regularity. In practice, most implementations that claim STP for travel claims have automated some steps and left human touchpoints in others. That is useful, but it is not straight-through. Understanding the precise technical and organisational conditions required for genuine STP, and why 2025 is a materially different moment than 2015 for meeting those conditions, is the foundation for any serious programme aimed at achieving it.
What straight-through actually means
The operationally meaningful definition of STP is exact: a claim travels from first notice of loss to settled status with zero human intervention on qualifying claims. Not "mostly automated." Not "decision-assisted." Zero human touchpoints on the claims that go through the automated track. Any process with a required human step at any point in the pipeline, even a single approval click, is not STP by this definition.
This is a higher bar than most insurance operations use when they describe their claims process as "automated." The common pattern is adjuster-assisted automation: the system gathers data, checks flight records, and populates a case file; the adjuster makes the coverage decision. That pattern substantially reduces adjuster time per claim and is a valuable improvement. But it does not deliver the same economics or the same customer experience as genuine STP, and conflating the two produces unrealistic expectations about what automation projects will achieve.
The three components STP requires in sequence
For a standard flight-delay claim, genuine STP requires three components working in unbroken sequence. First, automated event detection and validation: the pipeline must establish independently that the qualifying event occurred, using externally verifiable data, without requiring the policyholder to submit documentation or an adjuster to investigate. This is the component where 2025 differs from 2015: commercial flight data infrastructure has matured considerably. Real-time flight operational data, IATA delay codes, and historical departure records are available via commercial APIs with the reliability and completeness needed to drive automated decisions rather than just inform human ones.
Second, automated coverage determination: the pipeline must read the policy document, apply the coverage logic, and produce a definitive coverage decision without human review of the decision itself. This is the component that policy extraction systems address. It requires an extraction architecture that handles endorsement overrides, defined-term cross-references, and benefit schedule lookups with confidence high enough to support automated decisions on standard claim patterns.
Third, automated settlement instruction: the pipeline must instruct a payment to the policyholder without a human approving the individual payment. This is the component where most partial STP implementations stall. The event detection and coverage determination are automated, but the payment still routes through a human approval step in the financial system. This approval step was designed when all payments were initiated by a person and is often governed by financial controls that were never designed with automated payment volume in mind. Removing it requires coordination with the finance function that is organisational as much as technical.
The rate-determining step is usually the third one
Consider a mid-size Swiss travel insurer that automated their FNOL intake in 2021 and their flight data verification in 2023. By their internal reporting they have "80% automation" for flight-delay claims. In practice, every claim in that portfolio still routes through a payment authorisation queue where a finance controller approves batches of payments twice daily. The settlement is triggered in under 24 hours, which is a significant improvement over a week-long queue, but the claim did not process straight through. A policyholder whose flight was delayed five hours lands home before their claim is settled, which was the original customer experience goal, but only because of the same human bottleneck that existed before, just faster.
Resolving the payment authorisation question requires the claims director and finance director to agree on an automated payment authorisation framework with appropriate controls: claim value limits below which automated settlement is pre-authorised, fraud signal thresholds that route high-risk settlements to review regardless of claim type, and audit trail requirements that satisfy the finance function's control obligations. That is a policy and governance project, and it is the project that most STP programmes underestimate when scoping the technical work.
What drives the human review queue
Even in a pipeline designed for genuine STP, a fraction of claims will always route to human review. The important question is which fraction and why. Routing to review is correct when the claim genuinely requires human judgment. It is a system failure when the claim routes to review because of a data quality problem, a confidence threshold set too conservatively, or a pipeline component that does not handle a known edge case.
The cases that should route to human review: delay measurement that falls within a narrow confidence window around the policy threshold; conflicting data from multiple flight data sources for the same flight; an exclusion clause that applies and requires interpretive judgment; a policy document structure that reduces extraction confidence below the threshold required for automated decisions; and a payment instruction that encounters a verification failure on the insurer's payment side.
Each of these is a genuine edge case that warrants human judgment. The goal is not to eliminate the human review queue. It is to ensure that only claims in these categories reach it, that those claims arrive fully pre-populated with the relevant data and the extraction output, and that the handler can complete the review in under five minutes rather than 20.
STP rate and accuracy are in tension
There is a real and important trade-off between maximising the STP rate and maintaining coverage decision accuracy. A pipeline can be tuned to route fewer claims to human review by lowering confidence thresholds. The STP rate goes up. So does the error rate on automated decisions.
The right STP rate for any operation is not the maximum achievable. It is the maximum achievable at the accuracy standard the operation requires. Setting confidence thresholds conservatively means a lower STP rate than the maximum, but automated decisions that perform well against the ground truth of what an experienced adjuster would decide on the same case. Increasing the STP rate by accepting lower accuracy is not an operational improvement; it moves errors from the manual review queue to the automated output, where they are harder to detect and more likely to generate complaints or regulatory scrutiny.
The right frame is: what is the minimum accuracy standard we need to maintain, and what STP rate can we achieve within that standard? That question has a specific answer for each insurer's regulatory environment, customer complaint tolerance, and product economics. It is not a question that has one correct answer across all operations.
