Commercial insurance submission intake for underwriting (broker submissions, SOV, loss runs)

Commercial underwriters receive far more broker submissions than they can quote, and each arrives as an unstructured packet: an email, a few forms, a spreadsheet of locations and several loss runs in different layouts. AI assembles the packet, maps columns semantically, extracts and reconciles the facts, flags what is missing, checks appetite and hands a clean case to the underwriter. The underwriter decides; the machine does the data entry and first triage.

Problem & value

• Today: underwriting assistants re-key data from emails and attachments into the workbench, chase brokers for missing items, and triage by gut feeling. Quotable business competes with out-of-appetite submissions for the same scarce underwriter time; slow responses lose to faster carriers.
• AI value: faster first response to brokers, more submissions triaged per underwriter, consistent capture of data that feeds pricing, and an audit trail linking each value to its source page.
• Benefit figures: vendor-reported results (time saved, hit-ratio gains) exist but were not independently verified for this file; measure your own baseline (see KPIs) rather than relying on them.

Variants

• Property / SOV-heavy: hundreds or thousands of locations, COPE data (construction, occupancy, protection, exposure), geocoding and cat-model preparation.
• Casualty / liability, cyber, marine, D&O: questionnaires and financials rather than SOVs.
• MGA / delegated authority: intake at the coverholder, bordereaux reconciliation.
• Reinsurance: cedant data submissions and treaty slips, similar normalisation.
• Broker side: brokers use the same technology to assemble clean submissions up front.
• Private use: none; personal lines are DOC-003 / claims-side AGENT-014.

How it works

1. broker email / portal / API
2. packet assembly (split, classify and link attachments; thread context)
3. parsing (OCR, layout, table detection; Excel via structure-aware reader)
4. semantic field mapping (SOV columns
5. target schema; loss-run tables
6. claim records)
7. extraction + cross-document reconciliation (conflicts, duplicates, currency, date ranges)
8. enrichment (geocoding, hazard/peril data, company registries, prior-claims data)
9. gap check & broker follow-up draft
10. appetite / eligibility triage against guidelines
11. case creation in workbench / policy admin; underwriter review and decision

• Semantic mapping: an LLM proposes the mapping of arbitrary spreadsheet headers to the schema (and unit/currency normalisation); deterministic code applies it and validates totals.
• Large spreadsheets: never feed 5,000 SOV rows to a prompt; use the model to write/choose a mapping, then run it in code. Check sum insured totals against the stated total.
• Triage: rules plus LLM reasoning over appetite documents; every verdict cites the clause used.
• Human-in-the-loop: underwriter confirms extracted key fields, accepts or edits the triage and owns quote, decline and referral decisions. Declines are never sent by AI alone.

Data preparation

Needed data: broker e-mails and attachments, applications and questionnaires, statements of values (SOV) in Excel, loss runs, financial statements, survey reports, plus the carrier's underwriting guidelines, appetite rules and historic quotes. They live in shared underwriting mailboxes, the policy-admin system, a DMS and on file shares; some come as scans.

Typical gaps: every broker uses a different layout, spreadsheets with merged cells and hidden sheets, scanned loss runs, duplicate submissions and renewals mixed with new business, missing outcome labels (bound, declined, lost), and underwriting rules that are only implicit.

Preparation steps: connect the mailbox and export historic submissions (PREP-005, PREP-007); define the data model of a submission with the underwriters (PREP-019, PREP-012); restructure typical SOV templates into tidy tables (PREP-011); digitise scanned loss runs (PREP-006); harvest outcomes from the policy system as labels (PREP-020); write the underwriting guidelines in retrieval-ready form (PREP-014); build an evaluation set of 100 to 200 reviewed submissions (PREP-018); and pseudonymise test data (PREP-022). Extraction building blocks come from DOC-014.

Data preparation is a medium share, roughly 25 to 35 percent. See GUIDE-003.

Implementation paths

Which path for whom

• enterprise: Path B, because underwriting intake is core to the insurer's competitiveness, must fit the own policy-admin and rating systems and appetite rules, and volumes make an own pipeline worthwhile; Path A suits carriers with a vendor already embedded in their stack.
• developer: Path B, because insurtech vendors and integrators build submission-intake pipelines on EU-hosted APIs and connect them to carrier systems.

Path A — Buy (off-the-shelf)

• Dedicated submission-intake / underwriting-AI vendors: Cytora (UK; acquired by Applied Systems in 2025, verify product status), Sixfold, FurtherAI, IntellectAI (named in the research sweep); also Kalepa and Federato (underwriting platforms with ingestion). Check: EU/UK data residency, ACORD support, SOV handling at scale, citation of sources, connector to your policy system, whether data is used for vendor model training.
• Core-system suites: Guidewire, Duck Creek and Insurity add intake and document capabilities to policy admin; strongest when you already run them.
• Generic IDP engines (ABBYY, Hyperscience, Rossum, Indico) work for forms and loss runs but lack SOV mapping and appetite logic out of the box.
• Choose A when: you want value within months and your policy system has an integration.

Path B — Build on cloud APIs

• Parsing: Azure AI Document Intelligence (EU regions), Google Document AI (EU location), AWS Textract, Mistral OCR (EU provider).
• Reasoning/extraction: frontier multimodal LLMs with structured outputs via EU-region endpoints (Azure OpenAI, Vertex AI, Bedrock, Mistral). Use schema-constrained output and per-field citations.
• Orchestration: agent framework or workflow engine (n8n, Camunda, Temporal), Excel handling in Python (pandas/openpyxl) driven by LLM-generated mappings.
• Choose B when: you need proprietary appetite logic or deep integration, and have a platform team.

Path C — Self-host (open source)

• Parsing: Docling, MinerU, PaddleOCR; Excel via pandas/openpyxl.
• Models: open-weight 30–120B class LLMs and VLMs (e.g. Qwen, Mistral, gpt-oss families) on vLLM; strict JSON decoding. Required when submissions contain sensitive client data and policy forbids cloud.
• Hardware: HW3 for reliable packet-level reasoning; HW2 suffices for form/loss-run extraction only.
• Effort: you build the schema mapping, evaluation set and connectors yourself.

Path D — Custom training

Rarely worthwhile at first. Fine-tune a small extractor for your highest-volume loss-run formats or your internal SOV schema once you have a few thousand underwriter-corrected cases; the correction log from review is the training data. Appetite triage is better handled by retrieval plus rules.

State of the art (2026)

• Agentic pipelines that split a packet, route documents to specialised extractors and reconcile conflicts across documents are the standard product architecture; underwriter-facing UIs show each value next to its source snippet.
• Vendor emphasis has moved from extraction accuracy to decision support: summaries, appetite checks and next-best-question for the broker.
• Limits: loss runs vary widely (multi-column tables, claims split across pages, currency and valuation-date differences); SOVs have merged cells, hidden sheets and inconsistent units; scanned documents and handwritten notes degrade accuracy; LLMs may fill gaps plausibly. Mitigate with arithmetic cross-checks, mandatory source citations and a "not found" option.
• Public benchmarks for this exact task are scarce; build your own labelled test set from past submissions.

Shared resources & combinations

• Same stack (ocr-docparse + vlm + llm-general): DOC-003 (forms), DOC-008 (mailroom classification and routing of the broker inbox), DOC-014 (table extraction), DOC-012 (financial statements for corporate risks), DOC-016 (rule checks against guidelines).
• Downstream: PRED-010 (pricing and underwriting models consume the structured data), ANOM-003 (fraud signals), PRED-037 (loss and reserving), AGENT-014 (claims side; same document stack).
• Knowledge: KNOW-001-style retrieval over underwriting guidelines and manuals.
• Hardware: one HW3 GPU server can serve intake, mailroom and claims document workloads.

Effort, cost & KPIs

• Path A: 2–6 months incl. workbench integration and appetite configuration; per-submission or platform licence.
• Path B: 4–9 months; costs are model calls per packet plus platform engineering.
• Path C: 6–12 months; GPU server plus MLOps.
• KPIs: time from receipt to first broker response, share of submissions triaged automatically, field-level accuracy on SOV/loss-run data against a gold set, quote and hit ratio, underwriter hours per bound policy, share of cases needing broker follow-up, rework rate.

People & change

Involve management and the head of underwriting first, since appetite and referral rules are theirs. Bring underwriters and underwriting assistants in as co-designers from the start; add IT and IT security for mailbox access and integration, and the data protection officer for the legal basis and AVV, because submissions contain personal data of insureds and sometimes health or claims data (GUIDE-005). Brokers are affected as partners; tell them how submissions are processed and what format helps.

Works council: depends. Intake automation as such does not monitor staff, but logs, productivity figures per underwriter or triage statistics by person would fall under §87(1) no. 6 BetrVG (objective suitability suffices). Inform it under §90(1) no. 3 as work processes change, and agree that the data is not used for individual performance control (GUIDE-004).

AI literacy: AI Act Art. 4 requires measures that support AI literacy (GUIDE-006). Train underwriters to read extractions with source citations and to recognise typical errors. Run a pilot with one line of business and a small group, in shadow mode against manual intake, and decide go/no-go on accuracy and cycle time (GUIDE-009). Typical concerns are loss of underwriting judgement and fair treatment of applicants. Address them by keeping the underwriting decision, pricing and declinature with humans, and by regular sampling for bias (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: commercial-lines intake for business customers is generally not Annex III. Annex III point 5(c) covers risk assessment and pricing for natural persons in life and health insurance, so such lines, or sole-trader and personal-data-heavy cases feeding individual risk assessment, must be assessed separately (classification: minimal here; depends if it scores individuals). AI literacy (Art. 4) applies.
• GDPR: loss runs and applications can contain personal data (injured parties, owners, drivers, health details in workers' compensation and accident lines). Data processing agreements, EU hosting, retention limits and no vendor training on your data.
• Sector: Solvency II governance, EIOPA expectations on AI governance and explainability, DORA for ICT third-party risk (register of vendors, exit plans), German VAG/BaFin requirements (MaRisk VA).
• Risks: hallucinated values flowing into pricing, prompt injection through email attachments, broker-data confidentiality. Mitigate with citations, validation rules, sandboxing of attachments, and underwriter sign-off.

Getting started

1. Collect 200–300 historical submissions (including bad ones) and label key fields; this is your test set.
2. Define the target schema (SOV, loss history, applicant) and the appetite rules in writing.
3. Run 2–3 vendors (Path A) or a prototype (Path B) on the test set; compare field accuracy and time saved.
4. Pilot with one line of business and a few underwriters; log every correction.
5. Add broker follow-up drafting and workbench integration once accuracy is stable.

Sources

Note: live web research was unavailable when this file was written (tool budget exhausted); the links below are primary reference pages named from background knowledge and are to be re-verified. 1. Regulation (EU) 2024/1689 (AI Act), Annex III 5(c) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj 2. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj 3. Regulation (EU) 2022/2554 (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554/oj 4. ACORD standards and forms — https://www.acord.org 5. Docling project — https://github.com/docling-project/docling 6. Microsoft — Azure AI Document Intelligence — https://learn.microsoft.com/azure/ai-services/document-intelligence/ 7. EIOPA — Artificial intelligence — https://www.eiopa.europa.eu 8. Vendor sites (Cytora, Sixfold, FurtherAI) — https://www.cytora.com , https://www.sixfold.ai , https://www.furtherai.com