An AI claims assistant handles the high-volume, document-heavy phases of claims processing so adjusters can focus on judgment-intensive decisions. The system does not replace adjusters - it does the intake, evidence gathering, and pre-screening work that currently consumes most of their time before a real decision is even made.

What Goes In

Each claim submitted to the assistant carries four input types:

  • Claim form - the structured or semi-structured initial submission, whether filed via web form, PDF, or email
  • Policy document - the active policy associated with the claimant, used to verify coverage and applicable limits
  • Photos and supporting media - damage photographs, scene images, or supporting attachments
  • Repair or medical estimates - third-party assessments of damage or treatment costs

The system accepts all of these through a single intake endpoint. Documents are stored in S3 and a claim record is created immediately so the claimant receives confirmation of receipt regardless of processing status.

Processing Steps

Intake normalization - The claim form is parsed and converted into a structured data record. Required fields are checked against the claim type. Missing fields are identified immediately and a data-gathering request is issued to the claimant before any processing continues.

Policy matching and coverage check - The policy document is matched against the claim type and the reported loss date. Coverage gaps, exclusions, or limit constraints are flagged at this stage - before the adjuster touches the file.

Document extraction - Textract processes photos and estimates to extract structured information: damage categories, line-item costs, location data from image metadata. Bedrock post-processes the extracted text to resolve ambiguities and normalize against claim categories.

Fraud signal detection - Rule-based checks run first: claim amount relative to policy age, estimate amounts relative to historical averages for the reported damage type, claimant contact details cross-referenced against known patterns. ML-based anomaly scoring runs in parallel. Any triggered signal generates a flag with the specific signal described - not just a score.

Evidence bundle assembly - All extracted data, documents, flags, and coverage notes are assembled into a single structured evidence bundle. The adjuster receives this rather than a folder of raw files.

Payout recommendation - Based on extracted costs, coverage limits, and completeness of documentation, the system generates a recommended settlement range with the basis for that range stated explicitly.

What Comes Out

  • Claim summary - structured one-page overview of the claim, claimant, coverage status, and key facts
  • Evidence bundle - organized set of extracted data from all submitted documents, with confidence scores where relevant
  • Payout recommendation - a settlement range with supporting rationale, not a final decision

Human Adjuster Sign-Off

The payout recommendation is advisory. The adjuster reviews the summary, checks the evidence bundle, and either accepts, modifies, or overrides the recommendation. The final authorization is always a human action. For complex or high-value claims, the system routes directly to a senior adjuster queue with the fraud flags prominently surfaced.

This design satisfies regulatory requirements in most jurisdictions - automated screening and recommendation is permitted, but automated approval of payment is not. Audit logs from Step Functions capture every state transition and decision for the required retention period.

Typical Results

Claims processed through an intake assistant typically show 40-60% reduction in time from FNOL to adjuster review, primarily because document chasing and manual data entry are eliminated. Fraud flag precision varies by domain but typically surfaces 2-5x more potential anomalies than manual review alone, at lower false-positive rates when the signal rules are properly calibrated.