Automate FNOL Claim Intake & Triage for Insurance with n8n + Claude Step-by-Step Guide

2. System Architecture

Eight components, each replaceable. The orchestration layer is self-hosted n8n inside the carrier’s own VPC so InfoSec and Compliance can audit every external API call that touches PII or PHI. Nothing leaves the perimeter except scrubbed prompts to Claude and signed lookups against the fraud data providers.

The stack

Cost estimate (6,200 FNOL/month)

Roughly $0.51 per FNOL. The intake-clerk labor it replaces is $4–$7 per FNOL fully loaded; the LAE saved by getting reserves right at day 1 dwarfs both. The same orchestration layer slots into our wider AI automation services.

FNOL arrives in whatever shape the claimant or producer chose. The pipeline normalizes three primary channels into a single internal event: the email box monitored by the claims department, the web portal where insureds and agents file directly, and inbound phone calls captured through Twilio with real-time transcription.

Channels and capture method

• Email ([email protected]): n8n IMAP node polls every 30s. ACORD forms, police reports, photos and free-text body extracted as separate attachments. Email body itself becomes a structured note on the claim.
• Portal webhook: the insured/agent portal POSTs a JSON FNOL with claimant info, loss description, optional photos. HMAC-signed.
• Phone (Twilio): dedicated DID for after-hours FNOL. Twilio’s transcription is good enough as raw input — Claude cleans it. Recording stays in S3 for adjuster playback.
• EDI / partner feed: for fleet, commercial auto, mortgagee notices. Daily SFTP pickup parsed into the same internal event shape.

Normalized intake event

Every channel converts to one schema before any downstream node runs. This makes severity, fraud and routing logic channel-agnostic.

{
  "intake_id": "fnol_01HXYZ...",
  "channel": "email" | "portal" | "phone" | "edi",
  "received_at": "2026-05-03T14:22:09Z",
  "raw_source_id": "imap:msgid-...",
  "claimant": {
    "name_provided": "Maria Lopez",
    "phone": "+1-512-555-0188",
    "email": "[email protected]",
    "policy_number_provided": "AUT-3399201",
    "relationship": "insured" | "third_party" | "agent" | "attorney"
  },
  "loss": {
    "date_of_loss_provided": "2026-05-02",
    "type_provided": "auto_collision",
    "narrative": "rear-ended at stoplight on I-35...",
    "location_text": "I-35 N near exit 230, Austin TX"
  },
  "attachments": [
    { "kind": "police_report", "s3": "s3://...", "mime": "application/pdf" },
    { "kind": "photo",         "s3": "s3://...", "mime": "image/jpeg" }
  ],
  "language": "en",
  "signature": "sha256=..."
}

The unstructured payload is where the work is. A police report PDF, a photo of a damaged bumper, a 4-paragraph email — none of that is queryable until it becomes structured fields on the claim. OCR pulls the text layer; Claude turns it into the canonical FNOL extraction object that the rest of the pipeline reads.

OCR cascade

1. Document classifier (Claude Haiku): reads the first page only, returns police_report, acord_2, repair_estimate, medical_bill, photo or unknown.
2. OCR engine selection: Textract Forms+Tables for ACORD, Textract Queries for police reports, Document AI for handwritten supplements, Claude vision for damage photos.
3. PII scrubbing: SSN, full DL number, full DOB, full account numbers replaced with last-4 tokens before any external Claude call. Whitelist of fields that may leave the VPC.
4. Claude extraction: Sonnet reads the OCR text + email body + transcript and emits the canonical FNOL extraction object.
5. Confidence scoring: any field with confidence < 0.85 is flagged for adjuster review and never auto-populates the policy match.

Claude extraction prompt

You are a Property & Casualty FNOL extraction engine. You read the
OCR text of one or more documents plus a free-text claimant narrative
and emit a single JSON object describing the claim.

Rules:
- Never invent fields. If a value is not present in the source, return null.
- Quote the source span verbatim in `evidence` for every populated field.
- Confidence is your honest estimate, 0.0 to 1.0. Below 0.85 means a
  human adjuster MUST verify before the claim is opened.
- Dates as ISO-8601. Money as integer cents.
- Coverage type uses the carrier ontology in `<coverage_taxonomy>`.

Output schema (strict):
{
  "claimant_name": str|null,
  "policy_number": str|null,
  "date_of_loss": str|null,
  "time_of_loss": str|null,
  "loss_location": { "address": str|null, "lat": num|null, "lng": num|null },
  "loss_type": "auto_collision" | "auto_comprehensive" | "property_water" |
               "property_fire" | "property_theft" | "liability_bi" |
               "liability_pd" | "workers_comp" | "other",
  "vehicles": [...],
  "injuries_reported": bool,
  "injury_descriptions": [...],
  "third_parties": [...],
  "police_report_number": str|null,
  "estimated_damage_cents": int|null,
  "narrative_summary": str,    // 2-3 sentences, neutral, no speculation
  "fields": { "<name>": { "value": ..., "confidence": num,
                          "evidence": "verbatim quote" } }
}

Once the claim has a policy number candidate (or a claimant name + DOB + state for a fuzzy match), the workflow hits the policy admin system to confirm the policy was in force at the date of loss, pull the schedule of coverages, and surface deductibles and sublimits. This is the first step where a soft-fail decision matters: if the policy isn’t found, we still write the FNOL — we just route it to a senior adjuster with an “unverified policy” flag.

Lookup hierarchy

1. Exact policy number — direct lookup, validate “in force” status against date_of_loss.
2. Producer + last name + zip — fallback when claimant gave the policy “for a Honda Civic” instead of the number.
3. VIN match (auto) — pulled from photo OCR or police report. Highest specificity for auto.
4. Address + line of business (property) — fuzzy match on insured location, then human review on the top 3 candidates.

PolicyCenter lookup (n8n HTTP Request)

{
  "method": "POST",
  "url": "https://pc.internal.carrier.com/rest/policy/coverage-at-date",
  "headers": {
    "authorization": "Bearer {{ $credentials.policycenter.token }}",
    "x-correlation-id": "{{ $json.intake_id }}"
  },
  "body": {
    "policy_number": "{{ $json.extraction.policy_number }}",
    "as_of_date":    "{{ $json.extraction.date_of_loss }}",
    "include": ["coverages","deductibles","sublimits","named_insureds","drivers","vehicles"]
  }
}

// Response shape (truncated)
{
  "policy_number": "AUT-3399201",
  "in_force": true,
  "effective": "2025-09-12",
  "expires":   "2026-09-12",
  "named_insureds": [{ "name": "Maria Lopez", "dob_last4": "1988" }],
  "coverages": [
    { "code": "BI",  "limit_each_person_cents": 10000000, "limit_occurrence_cents": 30000000 },
    { "code": "PD",  "limit_cents": 5000000 },
    { "code": "COLL","deductible_cents": 50000 },
    { "code": "COMP","deductible_cents": 25000 },
    { "code": "UM",  "limit_each_person_cents": 5000000 }
  ],
  "vehicles": [{ "vin": "1HGCM82633A...", "year": 2019, "make": "Honda", "model": "Civic" }]
}

Severity drives reserve, adjuster level, and supervisor notification within minutes of FNOL. A miscall in either direction is expensive: reserving a fender-bender as a BI ties up loss reserves the carrier can’t redeploy; reserving a catastrophic injury as moderate PD blows the entire loss-development curve and triggers regulatory questions later. Claude reads the extraction object plus the policy and emits a structured severity object.

The 5 severity tiers

Severity classifier system prompt

You are a P&C claims severity classifier. You read a structured FNOL
extraction and the in-force policy schedule, and you assign a severity
tier and a recommended initial reserve range.

You DO NOT make coverage decisions. You DO NOT make payment decisions.
You DO NOT deny anything. A licensed adjuster owns those decisions.

Severity tiers (carrier-tuned):
- tier_1_minor_pd:        PD-only, est < $5k, no injuries
- tier_2_moderate_pd:     PD $5k-$25k, multi-party PD allowed, no injuries
- tier_3_bi_low:          BI reported, ER-only, no hospitalization
- tier_4_bi_high_or_total: hospitalization, surgery, total-loss vehicle
- tier_5_catastrophic:    fatality, brain/spinal injury, mass casualty

Output (strict JSON):
{
  "tier": "tier_1_minor_pd" | ... | "tier_5_catastrophic",
  "tier_confidence": 0.0-1.0,
  "reserve_recommendation": {
    "currency": "USD",
    "low_cents": int, "high_cents": int
  },
  "supervisor_alert_required": bool,
  "reasoning": "2-4 sentences citing the specific FNOL evidence",
  "evidence_spans": ["verbatim quote 1", "verbatim quote 2"]
}

Rules:
- If injuries_reported is true and you cannot verify ER-only, default UP
  one tier (precautionary).
- If a fatality is mentioned anywhere in the source, tier=5, confidence
  may be lower but supervisor_alert_required = true regardless.
- tier_confidence below 0.7 forces human review before reserve is set.

Sample output

{
  "tier": "tier_4_bi_high_or_total",
  "tier_confidence": 0.91,
  "reserve_recommendation": {
    "currency": "USD",
    "low_cents":  1500000,
    "high_cents": 4500000
  },
  "supervisor_alert_required": true,
  "reasoning": "Claimant reports two-vehicle collision with airbag deployment and transport by ambulance to St. David's. Police report cites suspected fracture. Vehicle photos show A-pillar deformation consistent with possible total-loss assessment.",
  "evidence_spans": [
    "transported by ambulance to St. David's",
    "vehicle towed from scene, frame appears bent",
    "officer notes possible left tibia fracture"
  ]
}

Fraud scoring at FNOL is a referral signal, not a denial decision. The system surfaces patterns — staged-loss indicators, claim-frequency anomalies, suspicious narrative phrasing — and either (a) writes a flagged note for the adjuster, or (b) generates a soft SIU referral. Nothing is auto-denied. Ever. The model output never reaches the claimant; only the adjuster’s eventual decision does.

Two-stage scoring

1. Deterministic rules layer — runs first, in n8n. ISO ClaimSearch hit on same VIN within 24 months, claimant has >3 prior claims in 36 months, loss reported >14 days late, loss in claimant’s home zip with no police report. Each rule is a labeled signal, not a verdict.
2. Claude reasoning layer — reads the narrative + LexisNexis enrichment + rules-layer signals, produces a structured fraud signal score with explicit reasoning over the specific text.

Fraud signal output schema

{
  "fraud_signal_score": 0-100,
  "band": "low" | "elevated" | "high",
  "siu_referral_recommended": bool,
  "rules_hits": [
    { "rule_id": "ISO_HIT_24M", "weight": 0.25,
      "evidence": "matching VIN in ISO ClaimSearch, prior claim 2024-11" },
    { "rule_id": "LATE_REPORT_GT_14D", "weight": 0.10,
      "evidence": "date_of_loss 2026-04-15, FNOL received 2026-05-02" }
  ],
  "narrative_signals": [
    {
      "signal": "passive voice on key facts",
      "evidence": ""the vehicle was caused to leave the roadway""
    }
  ],
  "reasoning": "Late-report combined with prior ISO hit on same VIN and a single-vehicle nighttime loss in claimant's home zip. Recommend SIU referral; do not delay adjuster assignment.",
  "do_not_communicate_to_claimant": true,
  "model_version": "fnol-fraud-v3.2"
}

Routing thresholds

The right adjuster on the file at hour zero matters more than almost any later step. Routing is a weighted decision over line of business, severity tier, claimant state (adjusters are licensed by state), current open-file count, and language preference. The output is a single adjuster_id plus a fallback list in case the primary is OOO.

Routing matrix (auto + property carrier)

Routing query

-- Pick the lowest-loaded eligible adjuster for this LOB + severity + state.
-- Open-file count is refreshed every 5 minutes from ClaimCenter.

SELECT a.adjuster_id,
       a.full_name,
       a.open_files,
       a.languages
FROM   adjusters a
JOIN   adjuster_licenses al  ON al.adjuster_id = a.adjuster_id
WHERE  a.line_of_business = $1     -- 'auto' | 'property' | 'gl'
  AND  a.tier_max         >= $2   -- numeric tier value 1-5
  AND  a.status           = 'active'
  AND  al.state_code      = $3     -- claimant state, e.g. 'TX'
  AND  al.expires_on      > now()
  AND  ($4 = ANY(a.languages))     -- claimant preferred language
ORDER  BY a.open_files ASC,
          a.last_assigned_at ASC
LIMIT  3;

If the top result is OOO (calendar integration), the workflow walks the LIMIT 3 list. If all three are OOO, the file routes to the supervisor queue with a flag. The supervisor never sees a tier_1 fast-track unless every fast-track adjuster in the state is unavailable — which is the right escalation, not a fallback into a slower queue.

Once severity, fraud, and routing are decided, the workflow opens the claim file in Guidewire ClaimCenter, attaches every document and photo, sets the suggested reserve range, posts the AI notes (clearly labelled as model output), and assigns to the chosen adjuster. The claimant gets an acknowledgement SMS and email with the claim number, the assigned adjuster’s name, and the SLA for their first contact.

ClaimCenter create payload

{
  "policy_number":   "AUT-3399201",
  "loss_date":       "2026-05-02",
  "reported_date":   "2026-05-03T14:22:09Z",
  "loss_type":       "auto_collision",
  "loss_location":   { "address": "I-35 N exit 230, Austin TX" },
  "claimant": {
    "name":  "Maria Lopez",
    "phone": "+1-512-555-0188",
    "email": "[email protected]",
    "preferred_language": "en"
  },
  "ai_metadata": {
    "intake_id":          "fnol_01HXYZ...",
    "severity_tier":      "tier_4_bi_high_or_total",
    "severity_confidence":0.91,
    "reserve_low_cents":  1500000,
    "reserve_high_cents": 4500000,
    "fraud_band":         "elevated",
    "siu_referral":       false,
    "human_review_required": false,
    "model_versions": {
      "extractor":  "fnol-extract-v4.1",
      "severity":   "fnol-severity-v3.0",
      "fraud":      "fnol-fraud-v3.2"
    }
  },
  "assigned_adjuster_id": "ADJ-1188",
  "documents":  [...],
  "ai_notes":   "Auto-generated by intake workflow — see ai_metadata. Adjuster review required before any coverage decision or payment."
}

Claimant acknowledgement (SMS + email)

The acknowledgement is written by Claude using a tightly constrained template. It never quotes the model’s severity or fraud output to the claimant. It states the claim number, the adjuster’s name, the contact SLA, and what to send next.

{
  "to":   "+15125550188",
  "from": "+18335550100",
  "body": "Hi Maria — your claim CLM-2026-118334 has been opened. Sara Patel ([email protected]) is your adjuster and will call you within 1 hour. Reply STOP to opt out of claim updates."
}

Compliance: TPA Audit, State DOI, NAIC Model Conduct

Insurance is regulated at the state level by every state’s Department of Insurance, with model laws coordinated through the NAIC. AI in claims is now explicitly addressed in NAIC Model Bulletin on the Use of AI Systems by Insurers (2024) and adopted in some form by most states. Treat compliance as the design spine, not a bolt-on.

Hard rules that drive the architecture

• No automated denial. The model output never produces a coverage decision, denial letter, or payment. A licensed adjuster signs off on every adverse action.
• No automated fraud accusation. SIU referral is internal. The claimant never sees a “we suspect fraud” message generated by the model.
• Acknowledgement clock. Most state UCPA require 10–15 days for written acknowledgement; the workflow’s sub-90-second ack massively exceeds the standard. Log the timestamp in the audit ledger.
• Adjuster of record. Every state requires a licensed adjuster on every claim. The assigned_adjuster_id is the regulator’s accountable human, regardless of how the routing was decided.
• Model card. NAIC Bulletin expects an internal model governance document covering training data, intended use, known limitations, and human-oversight points. The severity classifier ships with one; updates require formal version bumps.

TPA-grade audit log

The audit log is the document the carrier hands to a TPA, an external auditor, or a state DOI investigator. It must be immutable, complete, and queryable by claim and by adjuster. AWS QLDB or any WORM-storage equivalent works; the schema below is what we ship.

{
  "audit_id":      "aud_01HXYZ...",
  "claim_number":  "CLM-2026-118334",
  "intake_id":     "fnol_01HXYZ...",
  "step":          "severity_classification",
  "actor":         "system:claude-sonnet-4-5",
  "actor_version": "fnol-severity-v3.0",
  "input_hash":    "sha256:b41d...",
  "output_hash":   "sha256:c0a9...",
  "input_summary": "extraction object + policy schedule (PII redacted)",
  "output":        "tier_4_bi_high_or_total, conf 0.91",
  "human_override": null,
  "occurred_at":   "2026-05-03T14:22:31Z",
  "correlation_id":"req_01HXYZ...",
  "prev_audit_id": "aud_01HXYW...",
  "ledger_hash":   "sha256:..."
}

Model card (severity classifier excerpt)

• Intended use: rank-and-route triage signal at FNOL. Reserve recommendation only.
• Out of scope: coverage determinations, denial letters, settlement amounts, subrogation strategy.
• Calibration set: 24 months of carrier-internal closed claims, stratified by tier.
• Known limitations: tends to under-tier when injury narrative is sparse on portal submissions; mitigated by the precautionary upgrade rule when injuries_reported is true.
• Bias review: quarterly tier-distribution audit by claimant zip and language. Any drift >5% triggers a prompt review.
• Human oversight: tier_5 is supervisor-paged; tier_confidence < 0.7 forces human review pre-reserve; every adverse outcome is human-decided.

Measured Results — 90 Days In

Numbers from a regional carrier deployment (~6,200 FNOL/month, 38 staff adjusters, 3-person SIU, 1 supervisor on-call) after the first full quarter. Claim volume held steady — every gain comes from speed, severity accuracy, and labor reallocation.

The metric the chief claims officer cared about most: severity miscalls caught at adjuster reassignment dropped from 14% to 4%. That is the number that lets the actuarial team trust the day-1 reserve enough to release prior-year IBNR with confidence — the downstream financial leverage of getting tier right at FNOL is much larger than the obvious labor saving.

Implementation Timeline & Cost

FAQ