Insurance underwriting domain knowledge for building automated submission processing systems. Covers submission-to-bind lifecycle, document extraction patterns, compliance gates (sanctions, licensing, clearance), human-in-the-loop design for regulated financial services, confidence calibration for extracted fields, operating mode progression (manual to automated), and evidence traceability requirements. Use when designing or implementing underwriting pipelines, extraction agents, compliance workflows, HITL review systems, or decision package assembly for insurance or MGA operations.
This skill provides domain knowledge for building automated underwriting systems in insurance. It covers the business logic, decision criteria, and regulatory patterns that engineering teams need to implement correctly.
Every insurance submission follows a pipeline from initial receipt to policy issuance. The stages are sequential with gates between them.
Ingestion → Triage → Assessment → Quoting → Binding → Issuance
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
Classification Wave 1 Manual Manual Manual
& routing + Wave 2 UW review confirm issue
Ingestion — Receive submission (email, portal, API), parse documents, deduplicate, create case record, upload attachments to object storage.
Triage — Classify submission type (new business, MTA/endorsement, claim, renewal, other). Route based on classification confidence.
Assessment — Two-phase design (see "Cheap Gates First" below):
Quoting — Assemble underwriting decision package, compute confidence and thoroughness scores, apply desk quote gate, present to underwriter.
Binding — Underwriter makes firm order decision, terms confirmed with broker, binding authority exercised.
Issuance — Policy documents generated, premium invoiced, regulatory filings completed.
Structure pipelines to minimise cost-to-decline. Run inexpensive checks (API lookups, business rules) before costly ones (LLM extraction, external enrichment, compliance screening). Target cost breakdown:
| Stage | Target Cost | Primary Cost Drivers |
|---|---|---|
| Triage | < $0.05 | Fast-tier LLM classification |
| Wave 1 | < $0.10 | API lookups, minimal LLM |
| Wave 2 | $1-5 | LLM extraction, external APIs, sanctions |
See references/submission-lifecycle.md for detailed stage specifications.
Use a hierarchical case model for tracking work through the pipeline:
Case (top-level submission record)
├── Stage (lifecycle phase: triage, assessment, quoting)
├── Step (atomic processing unit within a stage)
└── Task (work item assigned to human or agent)
Insurance submissions contain multiple document types. Each type has different extraction requirements and field criticality.
| Document Type | Key Fields to Extract | Complexity |
|---|---|---|
| Proposal form | Insured name, address, business description, sums insured, requested coverage, deductibles | Medium |
| Schedule of values | Locations, building details, construction type, occupancy, values per location | High (tabular) |
| Loss runs / claims history | Prior claims, dates, amounts, causes, reserves | High (multi-year) |
| Slip / binder | Coverage terms, limits, conditions, exclusions, endorsements | Very High (legal language) |
| Broker cover note | Summary terms, premium indication, expiring terms | Medium |
| Financial statements | Revenue, assets, employee count | Medium |
Every extracted field has a criticality tier that determines its confidence threshold and HITL routing:
| Criticality | Threshold | Examples | HITL Policy |
|---|---|---|---|
critical | >= 0.95 | Coverage amount, named insured, effective/expiry dates, deductible | Always HITL if below threshold |
important | >= 0.85 | Address, occupation, construction type, building age | Junior reviewer if below threshold |
standard | >= 0.75 | Broker reference, submission notes, secondary contacts | Flagged for batch review |
Non-negotiable HITL fields (always require human review regardless of confidence): financial-impact fields above a configurable monetary threshold, exclusion/endorsement language, contract-critical dates, sanctions fuzzy matches.
Define field-level extraction and HITL policies as configuration (not code), grouped by LoB via policy packs:
field_catalog:
sum_insured:
criticality: critical
confidence_threshold: 0.95
hitl_policy: always_hitl_above_1m
insured_name:
criticality: critical
confidence_threshold: 0.95
hitl_policy: always_hitl
broker_reference:
criticality: standard
confidence_threshold: 0.75
hitl_policy: batch_review
This format drives HITL routing, confidence thresholds, and reviewer assignment for each extracted field. Override per LoB as needed.
Every AI-extracted field must link to its source via evidence coordinates:
{
"field": "sum_insured",
"value": 5000000,
"confidence": 0.92,
"evidence": {
"document_id": "DOC-001",
"page": 3,
"segment_id": "SEG-001-3-2",
"bounding_box": {"x": 120, "y": 340, "w": 280, "h": 45}
}
}
This is not optional. Regulatory audit requirements (PRA, FCA, Lloyd's) demand that every AI-produced output be traceable to its source document. Evidence coordinates enable:
Regulated underwriting requires multiple compliance checkpoints. These are blocking — submissions cannot proceed until compliance clears.
Use a tiered escalation pattern to optimise cost:
Screen all entities: insured company, key persons, asset locations, beneficial owners. Re-screen in Wave 2 with full extracted data even if Wave 1 cleared (Wave 1 used limited data).
Assemble a unified compliance view across all checks:
all_clear — all checks passed, no conditionsconditionally_clear — passed with conditions (e.g., licensing restrictions)review_pending — unresolved HITL tasksnot_quotable — hard fail on complianceSee references/compliance-and-hitl.md for detailed compliance patterns.
HITL is not a fallback — it is a first-class design element in underwriting automation. Three patterns, each for different scenarios:
Agent creates a review task, continues other work or pauses. Human completes the task within an SLA window. Agent resumes with human input.
Agent halts completely until human explicitly clears. No progress on any downstream step until the gate is resolved.
Agent proceeds with a provisional decision. Human reviews a batch of decisions during a scheduled review window.
Raw LLM confidence is unreliable. Use a two-stage hybrid approach:
Apply deterministic rules to classify outputs into confidence tiers:
For Medium Confidence outputs, run the extraction N times (default 5) at temperature > 0 and measure agreement:
| Agreement | Confidence | Routing |
|---|---|---|
| >= 80% | High | Auto-proceed + audit sample |
| 60-79% | Medium | Junior reviewer queue |
| 40-59% | Low | Senior reviewer queue |
| < 40% | Very Low | Specialist review |
Track whether confidence predictions match actual accuracy. A system predicting 80% confidence should be correct ~80% of the time. Alert when ECE exceeds 0.08 (warning) or 0.10 (critical). Auto-tighten thresholds on critical ECE breach.
Introduce automation gradually through five operating modes, managed per workflow type (not globally):
| Mode | HITL Rate | Behaviour |
|---|---|---|
| Manual | 100% | Humans do all work. AI captures data for training. |
| Shadow | 100% (comparison) | AI runs in parallel. Results compared but not used. |
| Assisted | 15-30% | AI pre-fills. Human approves before any write. |
| Selective | 5-15% | AI handles routine cases. Exceptions route to human. |
| Automated | < 5% | Full automation. Human involvement only for policy-gated exceptions. |
The culmination of automated processing is a structured decision package that synthesises all upstream outputs for the underwriter:
Different LoB have different extraction requirements, compliance rules, and confidence thresholds. Design systems to be LoB-configurable:
| LoB | Key Extraction Challenges | Compliance Focus |
|---|---|---|
| Property | Location schedules, building details, values | Sanctions (location-based), licensing |
| Casualty / Liability | Policy wording, exclusions, limits towers | Professional licensing, claims history |
| Cyber | Technology stack, security posture, revenue | Data privacy regulations, incident history |
| Marine | Vessel details, routes, cargo | Sanctions (route-based), flag state |
| Terrorism | High-value assets, location risk | Enhanced sanctions, government pools |
references/submission-lifecycle.md — Detailed stage-by-stage pipeline design
with decision logic, event patterns, and cost targetsreferences/compliance-and-hitl.md — Sanctions screening escalation, HITL gate
inventory, confidence calibration details, automation bias safeguards