Case Study - Agentic Claims Processing: Deterministic First, AI Second

Why deterministic checks must run before any AI evaluation

When a Swiss car insurance provider asked us to automate their claims pipeline, we started with a principle that shaped the entire architecture: deterministic logic runs first, and AI only enters the picture when rules alone cannot decide.

Four reasons drove this decision.

Auditability. Swiss regulators (FINMA) require that every automated decision can be traced to specific rules and data points. A rule engine produces a clear, inspectable decision path. An LLM does not.

Cost. LLM inference is expensive at scale. By resolving 70% of claims through deterministic stages, we cut API costs dramatically and kept the system economically viable for thousands of monthly claims.

Reliability. A rule that checks whether a policy is active will return the same answer every time it runs. LLMs do not offer that guarantee, and in insurance, consistency is not optional.

Speed. Rule evaluation completes in milliseconds. LLM inference takes seconds. For straightforward claims, there is no reason to make a policyholder wait.

Stage 1: Policy validation and document verification

Every incoming claim enters a validation gate. Before anything else, the system checks three things: Is the policy active on the date of the incident? Does the coverage type match the claim category? Are all required documents attached?

interface ValidationResult {
  isValid: boolean
  errors: string[]
  missingDocuments: string[]
}

function validateClaim(claim: IncomingClaim, policy: Policy): ValidationResult {
  const errors: string[] = []
  const missingDocs: string[] = []

  if (
    claim.incidentDate < policy.startDate ||
    claim.incidentDate > policy.endDate
  ) {
    errors.push(`Policy not active on incident date ${claim.incidentDate}`)
  }

  if (!policy.coverageTypes.includes(claim.claimCategory)) {
    errors.push(`Coverage type "${claim.claimCategory}" not included in policy`)
  }

  const required = REQUIRED_DOCS[claim.claimCategory]
  for (const doc of required) {
    if (!claim.attachments.some((a) => a.type === doc)) {
      missingDocs.push(doc)
    }
  }

  return {
    isValid: errors.length === 0 && missingDocs.length === 0,
    errors,
    missingDocuments: missingDocs,
  }
}

Invalid claims are returned immediately with a specific list of what is missing or incorrect. No human adjuster needs to review them, and no AI model is invoked. In production, roughly 15% of incoming claims are caught at this stage, most commonly due to missing police reports or expired policies.

Stage 2: Data enrichment from external sources

Claims that pass validation enter the enrichment stage. The system pulls data from multiple external sources to build a complete picture of the claim, all through deterministic API calls.

Vehicle history: VIN lookup returns ownership history, previous damage records, and current market valuation. If the claimed vehicle was written off six months ago in another canton, that fact surfaces here.

Weather data: For the reported accident date and location, the system retrieves historical weather conditions. A claim describing icy road conditions on a day when temperatures were 22°C raises a flag automatically.

Repair cost estimates: Industry databases provide expected repair costs for the reported damage type and vehicle model. A CHF 12,000 repair estimate for a bumper scratch on a 2019 Golf does not require AI to identify as suspicious.

Stage 3: Rule-based fraud detection

With enriched data in hand, a rule engine evaluates known fraud patterns. Every rule produces a scored, auditable output that explains exactly why a claim was flagged or cleared.

The rules cross reference multiple dimensions:

Geographic anomalies. The same VIN appearing in active claims across multiple regions within a short timeframe is a strong fraud indicator.

Value ratio analysis. When the claimed repair cost exceeds a configurable percentage of the vehicle's current market value, the claim is flagged. This threshold varies by damage category and vehicle age.

Timing patterns. Claims filed within days of policy activation, or clusters of claims from the same policyholder in a short window, trigger additional scrutiny.

Network detection. Known fraud rings often involve the same repair shops, witnesses, or legal representatives. The rule engine maintains a graph of associations and flags matches.

Each rule contributes a weighted score to an overall fraud risk assessment. The weights were calibrated using historical claims data, but the evaluation itself is purely deterministic.

Stage 4: LLM evaluation with structured output

Only claims that survive all three deterministic stages and still require nuanced judgment are routed to the LLM. At this point, the model receives the full enriched context: policy details, external data, fraud scores, and the claimant's free text description.

The critical design choice here is structured output. The LLM does not return free text recommendations. It returns a typed JSON object that downstream systems can process programmatically.

{
  "claimId": "CLM-2026-48291",
  "recommendation": "APPROVE",
  "confidence": 0.91,
  "reasoning": {
    "liability": "Clear single-party accident, consistent with weather conditions and location",
    "damageAssessment": "Repair estimate aligns with industry benchmarks for reported damage",
    "fraudIndicators": "No anomalies detected in enriched data"
  },
  "suggestedPayout": 4850.0,
  "escalationRequired": false,
  "humanReviewReason": null
}

By enforcing a schema, we ensure that every LLM output is machine readable and can be logged, audited, and compared across claims. The confidence score is particularly important because it directly feeds into the escalation logic.

How we handle edge cases and human escalation

Not every claim can be fully automated, and the system is designed to recognize its own limits. Three conditions trigger mandatory human escalation:

Low confidence. When the LLM's confidence score falls below 0.75, the claim is routed to a human adjuster with the full enriched context and the model's preliminary assessment. The adjuster does not start from scratch; they review and either confirm or override.

High value claims. Claims exceeding a configurable amount (set by the insurer's risk policy) always require human sign off, regardless of how clear cut the automated assessment is.

Borderline fraud scores. When the rule engine's fraud score lands in the "uncertain" band, neither clearly clean nor clearly fraudulent, a specialist reviews the case. This avoids both false accusations and missed fraud.

Results and what we learned

The system transformed claims processing from a multi day bottleneck into a pipeline that resolves most claims within hours. Policyholders receive faster payouts, adjusters focus on genuinely complex cases, and the compliance team has a complete audit trail for every decision.

The most important lesson: in regulated industries, the architecture matters more than the model. A well designed deterministic pipeline with AI at the edges outperforms an "AI first" approach in cost, reliability, and regulatory acceptance. The LLM is powerful, but it earns its place by handling the 30% of cases where rules cannot decide, not by processing everything.

If you are building claims automation or any regulated AI pipeline, we would like to hear about your challenge.

What we did