Insurance · Playbook 08

Underwriting submission review

Every broker submission read, its risk data extracted and checked against appetite on the day it arrives, with gaps flagged and a referral note drafted. The underwriter decides, prices and speaks to the broker.

  • Document AI
  • Retrieval (RAG)
  • Agents with tools
  • Human in the loop
  • PRA
  • FCA Consumer Duty
  • Insurance Act 2015
  • Lloyd's / LMG Core Data Record
  • OFSI
  • UK GDPR

At a glance

The problem
Submissions arrive as emails with slips, spreadsheets and scanned loss runs, and are re-keyed before an underwriter looks
Typical volume
Around 1,500 broker submissions a month across property, casualty and SME package business
Who's involved
Class underwriters, underwriting assistants, underwriting management, exposure management, compliance, IT, the broker channel
Pilot
8–10 weeks on one class of business, after a 3-week discovery
Platforms
AWS, Azure, or a sovereign or on-prem stack

An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.

The business problem

Brokers send submissions in whatever shape they have. A typical property risk arrives as an email with a draft slip, a schedule of values in the broker's own spreadsheet layout, five years of loss runs scanned from previous insurers, a survey report and a covering note. Some business comes through the market's electronic placing platforms with structured data, but most still starts in an inbox. Before an underwriter looks, an underwriting assistant re-keys the insured's details, the locations, values and loss history into the underwriting workbench and the rating tools.

That delay costs business. Brokers send the same risk to several markets, and a submission that sits for three days is often placed elsewhere. Underwriters spend time on risks that were never in appetite, guidelines are applied a little differently by each person, and gaps such as missing construction details or an incomplete loss history are found late, after the broker has moved on. Referrals to senior underwriters are written in free text, so the reasons and the evidence vary from note to note.

The pressure is rising. The PRA's 2026 insurance priorities point to a softening underwriting cycle, including in parts of the London market, and ask firms to keep underwriting discipline as rates fall. The London market's modernisation is now moving step by step rather than through one central platform. Work on the Core Data Record carries on, but for years to come insurers will still need to turn broker emails into clean, structured risk data themselves.

What AI changes

  • Every submission is read on arrival, and the risk data is extracted into a structured record mapped to Core Data Record and ACORD-aligned fields. Each value links back to the page or spreadsheet cell it came from.
  • Schedules of values are normalised: columns mapped to your fields, units checked, totals reconciled to the slip, and addresses cleaned for exposure and catastrophe modelling.
  • The risk is checked against the line guide, appetite statements and the underwriter's written authority. Each result shows the rule it used and the evidence it found.
  • Gaps are flagged, such as missing construction details, loss runs that stop short or values that don't add up, with a draft information request for the underwriter to send.
  • The underwriter gets a one-page summary and, where the risk needs referral, a draft referral note in the house format.
  • The underwriter decides whether to quote, on what terms and at what price. The AI never quotes, declines, binds or writes to the broker.

How success is measured

Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.

Time to first underwriter look

How long a submission waits before an underwriter sees it.

ExampleFrom 3 days to the same day

Re-keying time

Underwriting assistant time spent copying data from submissions into systems.

ExampleDown by 60–70%

Extraction accuracy

Key fields (insured, locations, values, loss totals) checked against what the underwriter confirms, sampled weekly by class.

ExampleAbove 95% on key fields

Appetite check agreement

How often underwriters agree with the in or out of appetite result. Very low means it isn't helping; near 100% can mean nobody is checking.

ExampleStable, and reviewed weekly

Referral turnaround

Time from referral to a decision by the referral authority, with complete notes.

ExampleDown by half

Guideline breaches in peer review

Bound risks found outside guidelines or authority in the regular peer review.

ExampleFalling, measured against last year

UK regulation and controls

Cross-sector rules are on the UK regulation map.

  • PRAInsurance supervision: 2026 priorities (15 January 2026)

    The PRA highlights a softening underwriting cycle and closer scrutiny of underwriting discipline and delegated underwriting, and sees AI through the lens of prudential risk and operational resilience. The design applies the written guidelines the same way every time, keeps authority limits as hard rules owned by underwriting management, and gives the board management information on referrals and breaches.

  • PRA and FCAOperational resilience (SS1/21, SYSC 15A) and outsourcing and third-party risk (SS2/21)

    Firms, including Lloyd's managing agents, have had to stay within impact tolerances for their important business services since 31 March 2025. The AI is kept off the critical path: if it is switched off, submissions go to underwriting assistants as before. Cloud and model providers are assessed and recorded as material third parties where they qualify.

  • FCAConsumer Duty (PRIN 2A) and PROD 4, where SME customers are in scope

    Since PS25/21 (9 December 2025), contracts for larger commercial customers and specialist risks are outside PROD 4 and the Consumer Duty, but micro enterprises and small businesses are still retail customers. Each submission is tagged by customer type, and for retail customers the appetite rules and outcomes are monitored so no group is turned away without a reason.

  • UK lawInsurance Act 2015: fair presentation and the insurer's knowledge

    The broker must make a fair presentation, and the insurer is expected to ask questions where it should. Under section 5, the insurer can be treated as knowing information it holds that is readily available to the underwriter. So nothing extracted is silently dropped: the summary links to every source document, and possible material facts are shown to the underwriter, not hidden in an attachment.

  • Lloyd's and the London Market GroupCore Data Record (CDR) and ACORD standards

    The CDR is the market's agreed set of placing data, aligned with ACORD's GRLC standards, and now reaches into treaty reinsurance and claims. Extracted data uses CDR field definitions where they exist, so it can be shared with brokers, Lloyd's and market services without a second mapping.

  • HM Treasury (OFSI)UK financial sanctions

    The insured, its owners and the territories involved are screened by your existing sanctions tool, called by the agent. A possible match always goes to compliance. The AI never clears a match or decides it is a false positive.

  • ICOUK GDPR, the Data Protection Act 2018 and automated decisions

    Submissions hold personal data on directors, sole traders, employees and claimants named in loss runs, and sometimes health or criminal conviction details. That means a DPIA, processing in UK regions, retention tied to the policy record, and a contract that stops providers training on your data. The AI never declines on its own, so no significant decision about a sole trader is solely automated.

The solution

Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.

Underwriting submission review: reference architecture
  1. 01Channels

    • Broker email
    • Electronic placing platforms
    • Broker portal and API
  2. 02Intake

    • Amazon SESLogic Apps email connectorYour existing mail serverInbound email
    • API GatewayAPI ManagementKong, or your existing API gatewayAPI for platforms and portals
    • Amazon S3Blob StorageCeph, or IONOS S3 Object StorageSubmission store
  3. 03Intelligence

    • Amazon TextractContent Understanding (Document Intelligence)Docling plus an open-weight vision modelRead slips, SOVs and loss runs
    • Bedrock Knowledge BasesFoundry IQ (Azure AI Search)OpenSearch, or PostgreSQL with pgvectorLine guides and guidelines
    • Agent
      Bedrock AgentCoreFoundry Agent ServiceLangGraph on Kubernetes, with open-weight models via vLLMSubmission review agent
  4. 04Orchestration

    • Step FunctionsLogic Apps / Durable FunctionsTemporalSubmission workflow
    • EventBridge + SQSEvent Grid + Service BusApache Kafka or RabbitMQEvents and queues
  5. 05Systems of record

    • Underwriting workbench and policy admin
    • Rating, exposure and cat modelling
    • Sanctions screening and broker CRM
  6. 06People

    • Person
      Underwriting assistant: checks the data
    • Person
      Underwriter: decides and prices
    • Person
      Referral authority: approves referrals
  • Cloud or platform service (AWSAzuresovereign / on-prem)
  • AI agent
  • A person decides
  • Your existing systems
  • Outside your organisation

Components, side by side

Underwriting submission review: components on AWS, Azure and a sovereign or on-prem stack
LayerAWSAzureSovereign / on-prem
Intake: email, platforms, filesKeep the original email and every attachment unchanged, as the record of what the broker presented.Amazon SES, API Gateway, S3Logic Apps connectors, API Management, Blob StorageYour mail server, Kong, Ceph or IONOS S3 Object Storage
Reading documentsTest on real loss runs from many previous insurers, including poor scans, not the tidy examples in a demo.Amazon TextractAzure Content Understanding (includes Document Intelligence)Open-source parsing (e.g. Docling) plus an open-weight vision model
Spreadsheets and schedules of valuesThe model suggests how a broker's columns map to your fields. Plain code does the conversion, checks units and reconciles totals. A new broker layout is confirmed by a person once, then reused.AWS Lambda or containers, with a Bedrock model proposing column mappingsAzure Functions or containers, with a Foundry model proposing column mappingsContainers on Kubernetes, with an open-weight model proposing column mappings
Address clean-up and geocodingMany firms already geocode in their exposure management or catastrophe modelling platform. Use that if you have it.Amazon Location ServiceAzure MapsYour existing geocoder, or the one in your exposure management platform
Reasoning and summariesAWS and Azure both offer a choice of models, including Claude. On-prem and sovereign options run open-weight models.Amazon BedrockMicrosoft FoundryOpen-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub
Guidelines and appetite (retrieval)Only the current, approved line guides, appetite statements and referral rules. Each check cites the document and version.Bedrock Knowledge BasesFoundry IQ, built on Azure AI SearchOpenSearch, or PostgreSQL with pgvector
Authority limitsWritten authority limits are hard rules held as data and code, not left to a model's reading of a document.Rules in code, called by the agentRules in code, called by the agentRules in code, called by the agent
Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore.Amazon Bedrock AgentCoreFoundry Agent ServiceAn open-source agent framework (e.g. LangGraph) on Kubernetes
WorkflowAWS Step FunctionsLogic Apps or Durable FunctionsTemporal, or n8n
Middleware and eventsAmazon EventBridge, SQSEvent Grid, Service BusApache Kafka or RabbitMQ
Link to the underwriting workbenchReuse the integration layer you have. Many workbenches are vendor products, so agree early what their APIs allow.API Gateway, plus your existing integration platform if you have oneAPI Management, plus your existing integration platform if you have oneKong or your existing API gateway, plus your existing integration platform if you have one
Human reviewUnderwriters review where they already work, not in a new screen.In the underwriters' existing workbenchIn the underwriters' existing workbenchIn the underwriters' existing workbench
GuardrailsStops drafts from quoting a price, offering terms or stating cover.Bedrock GuardrailsFoundry guardrails (Azure AI Content Safety)Open-source guardrails (e.g. NeMo Guardrails, Llama Guard)
Identity, keys, data protectionIAM Identity Center, KMS, MacieEntra ID, Key Vault, PurviewKeycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM
Monitoring and auditLog every extraction, every check and its source, and every underwriter decision with the reason.CloudWatch, CloudTrailAzure Monitor, Log AnalyticsPrometheus, Grafana, OpenTelemetry
UK data residencyIONOS AI Model Hub runs in German data centres: EU, not UK, residency.eu-west-2 (London)UK South / UK WestYour own UK data centre, or a UK or EU provider

On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →

Hybrid and on-prem

Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.

Stays on-prem

The underwriting workbench, policy admin system, rating models and catastrophe modelling stay where they are, whether on your own servers or with their vendors. Nothing in this design needs them to move.

Uses cloud AI

Document reading, the guidelines index and the submission review agent can run in AWS or Azure UK regions, or on your own GPUs with open-weight models if broker data must stay in your estate.

How they connect

A private link (AWS Direct Connect or Azure ExpressRoute) and the API layer. Only the documents and fields the review needs are sent, and the structured record comes back as an event onto your queue.

If the link drops

Submissions keep arriving and queue safely on your side. Underwriting assistants key them by hand, exactly as before, and the backlog is read when the link returns.

The agents

What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.

Submission review agent

May do

  • Read the submission email and every attachment
  • Extract the risk data and map it to your fields and the CDR
  • Look up the line guide, appetite statements and referral rules
  • Check the risk against the underwriter's authority limits
  • Request a sanctions screen from the existing tool and return the result
  • Find previous submissions and policies for the same insured
  • Draft the summary, the referral note and an information request
  • Create and route a task in the underwriting workbench

May not do

  • Quote, price, decline or bind a risk
  • Write to or reply to a broker
  • Clear a sanctions match or mark it as a false positive
  • Change a line guide, appetite statement or authority limit
  • Remove a referral the rules require
  • Discard information from the submission

Where a person signs offThe underwriter decides every quote, decline and set of terms, and the referral authority signs off every referral. Compliance handles every possible sanctions match. The agent's permissions are enforced by the platform's identity and policy controls, not by instructions in a prompt.

Middleware and integration

The underwriting workbench and policy admin system are reached only through an API layer, never directly. If you already run an integration platform, the AI uses it like any other system does.

Every submission becomes a message on a queue with a stable ID: the broker's reference, then the Unique Market Reference once it exists. A resubmission or a broker's follow-up email is linked to the same record, so nothing is processed twice and the underwriter sees one risk, not three.

Extracted data is handed to rating and exposure tools in the formats they already accept. Where a schedule of values feeds catastrophe modelling, the reconciled version and the original are both kept, so the modelling can always be traced back to what the broker sent.

The AI can be switched off without stopping the business. If it's paused, submissions flow straight to underwriting assistants, exactly as they did before.

Process and people

  • Each class of business has a named underwriting owner for its line guide, appetite statement and referral rules. A change goes through the same approval as today, then into the guidelines index.
  • Underwriting assistants move from re-keying to checking: they confirm extracted data on new broker layouts and on anything the AI isn't confident about.
  • Override rules, so underwriters know how to disagree with an appetite result, and their reasons are captured and reviewed.
  • Peer review continues as now, with a sample that includes risks the AI marked as in appetite and those it marked as out.
  • Brokers hear from underwriters, not the AI. Information requests are drafts until an underwriter sends them.
  • Underwriters trained before go-live, including what the summary can't show: the broker relationship, the market and their own judgement.

Delivery plan

  1. 3 weeks

    Discovery

    Map today's submission flow, measure the baseline, collect a sample of real submissions, check workbench APIs, and pick the first class of business.

  2. Gate · must be true to passBaseline agreed, workbench route confirmed, DPIA started, underwriting owner named for the first class.

  3. 6–8 weeks

    Pilot

    One class, such as UK commercial property, in shadow mode: the AI extracts, checks and drafts, assistants and underwriters work as normal, and the two are compared.

  4. Gate · must be true to passExtraction accuracy and appetite agreement within agreed limits, no missed sanctions referrals, and underwriting management sign-off.

  5. 4–6 weeks

    Production

    Summaries and checks go live for the first class, with monitoring, support and a rollback plan.

  6. Gate · must be true to passMonitoring, support model, rollback plan and underwriter training in place.

  7. Ongoing

    Scale

    Add classes one at a time, then reuse the pattern for bordereaux from coverholders and for renewal review.

  8. Gate · must be true to passEach new class passes the same pilot gate.

Roles and RACI

Who is responsible, accountable, consulted and informed, by activity
ActivityChief underwriting officerProduct ownerSolutions architectI can fill thisTechnical PMI can fill thisEngineersI can fill thisCompliance & DPOSecurityI can fill this
Business case and benefitsAccountableResponsibleConsultedConsultedInformedConsultedInformed
Target architectureInformedConsultedAccountable and ResponsibleConsultedConsultedConsultedConsulted
Guidelines, appetite and authority rulesAccountableResponsibleConsultedInformedConsultedConsultedInformed
DPIA, sanctions and Consumer Duty reviewConsultedConsultedConsultedInformedInformedAccountable and ResponsibleConsulted
Build and integrationInformedConsultedAccountableResponsibleResponsibleInformedConsulted
Accuracy testing on real submissionsConsultedAccountableResponsibleConsultedResponsibleConsultedInformed
Go-live decisionAccountableResponsibleConsultedResponsibleInformedConsultedConsulted
Run, monitor and improveInformedAccountableConsultedConsultedResponsibleConsultedConsulted

Business case and benefits

Chief underwriting officer
A · Accountable
Product owner
R · Responsible
Solutions architect
C · Consulted
Technical PM
C · Consulted
Engineers
I · Informed
Compliance & DPO
C · Consulted
Security
I · Informed

Target architecture

Chief underwriting officer
I · Informed
Product owner
C · Consulted
Solutions architect
A/R · Accountable and Responsible
Technical PM
C · Consulted
Engineers
C · Consulted
Compliance & DPO
C · Consulted
Security
C · Consulted

Guidelines, appetite and authority rules

Chief underwriting officer
A · Accountable
Product owner
R · Responsible
Solutions architect
C · Consulted
Technical PM
I · Informed
Engineers
C · Consulted
Compliance & DPO
C · Consulted
Security
I · Informed

DPIA, sanctions and Consumer Duty review

Chief underwriting officer
C · Consulted
Product owner
C · Consulted
Solutions architect
C · Consulted
Technical PM
I · Informed
Engineers
I · Informed
Compliance & DPO
A/R · Accountable and Responsible
Security
C · Consulted

Build and integration

Chief underwriting officer
I · Informed
Product owner
C · Consulted
Solutions architect
A · Accountable
Technical PM
R · Responsible
Engineers
R · Responsible
Compliance & DPO
I · Informed
Security
C · Consulted

Accuracy testing on real submissions

Chief underwriting officer
C · Consulted
Product owner
A · Accountable
Solutions architect
R · Responsible
Technical PM
C · Consulted
Engineers
R · Responsible
Compliance & DPO
C · Consulted
Security
I · Informed

Go-live decision

Chief underwriting officer
A · Accountable
Product owner
R · Responsible
Solutions architect
C · Consulted
Technical PM
R · Responsible
Engineers
I · Informed
Compliance & DPO
C · Consulted
Security
C · Consulted

Run, monitor and improve

Chief underwriting officer
I · Informed
Product owner
A · Accountable
Solutions architect
C · Consulted
Technical PM
C · Consulted
Engineers
R · Responsible
Compliance & DPO
C · Consulted
Security
C · Consulted

R ResponsibleA AccountableC ConsultedI Informed· not involved

Where I'd fit

Option A

Lead the architecture

If there's no architect on the programme, I'd own the design end to end: the target architecture, the data model around the Core Data Record, the integration with your underwriting workbench and rating tools, and the gates. I'd report to your programme board and work closely with underwriting management.

Option B

Support your architect

If your partner or your own team already has an architect, I'd take on the document reading, the agent and the workbench integration under their lead, and give them a second senior opinion on data standards, security and resilience.

Where this goes wrong

  1. Goes wrong

    The demo used tidy spreadsheets. Real schedules of values have merged cells, hidden tabs and a different layout from every broker.

    How the design avoids it

    Pilot on last quarter's real submissions, every broker, and confirm each new layout once with a person.

  2. Goes wrong

    A value is read in thousands instead of pounds, and nobody notices until the cat model does.

    How the design avoids it

    Plain code checks units and reconciles totals against the slip, and anything that doesn't reconcile goes to a person.

  3. Goes wrong

    Appetite rules live in a prompt and drift away from the line guide.

    How the design avoids it

    Guidelines are retrieved from versioned, owned documents, and authority limits are hard rules in code.

  4. Goes wrong

    Underwriters treat the summary as the submission, and miss a fact in an attachment the firm is treated as knowing.

    How the design avoids it

    Every summary links to its sources, flags what it couldn't read, and peer review checks the source documents, not just the summary.

  5. Goes wrong

    A one-off data model is built, so nothing can be shared with brokers or the market later.

    How the design avoids it

    Map to Core Data Record and ACORD-aligned fields from the start.

On the horizon

Changes already announced or under way that affect this design. More in the UK horizon scan.

  1. Under way in 2026–2027
    The London Market Group's Data Council keeps extending the Core Data Record: treaty reinsurance (v3.3, 2026), first notification of loss data (October 2026), a delegated authority consultation, and work to build it into the next version of the market reform contract.

    Map extracted data to the current CDR version and keep the mapping as configuration, so each new release is an update, not a rebuild.

  2. 2026–2030
    The London market's 2026–30 modernisation plans, which move step by step rather than through one central platform.

    Don't wait for a market platform to clean the data. Design for email and structured data side by side, and take structured feeds as they appear.

  3. Q1 2027
    The FCA's policy statement following CP26/23 on the Consumer Duty in wholesale markets, distribution chains and non-UK business.

    Record customer type and UK connection on every submission now, so you can apply whatever scope the final rules set.

  4. 18 March 2027
    The PRA's and FCA's operational incident and third-party reporting rules (PS7/26 and PS26/2) take effect, with an updated SS2/21. Firms keep a register of material third-party arrangements.

    List the AI, cloud and model providers in this design, decide which are material, and map them to your important business services.

  5. 2026–2027
    The ICO's code of practice on AI and automated decision-making, required by regulations in force since May 2026.

    Keep the decision log, sources and underwriter decisions in a form you could show the ICO, especially for sole traders and small businesses.

Questions to ask your partner or vendor

Good answers are specific. Vague answers to any of these are worth following up.

Copy them into your next supplier meeting

  1. What happens to a submission when the AI or the link is down?
  2. How will we measure extraction accuracy on our own brokers' submissions, not a supplier's samples?
  3. Which checks are hard rules in code, and which rely on a model reading our guidelines?
  4. How does the summary make sure underwriters see everything the broker sent?
  5. Which actions can the agent take without a person, and where is that enforced?
  6. What does it cost to run per thousand submissions, at our volume and file sizes?

Planning something like this?

Whether you need someone to lead the design or to support the architect you already have, let's talk it through.

Sam Naseem
Sam NaseemBirmingham, UK · UK & Europe
Available now