TL;DR
Underwriting automation uses rules, data services and AI models to take an insurance submission from intake to an approve, refer or decline decision. The workflow extracts and checks the application, adds approved outside data, scores the risk and applies appetite and authority rules. Clean, in-appetite risks can then go straight through, while unclear or high-stakes files reach an underwriter with the evidence attached. Rules own eligibility and authority, models estimate risk, and generative AI and agents prepare files without any power to bind. The hardest parts are the referral rules, the data underneath and a decision record that shows reasons and sources. As of November 2026, 29 US jurisdictions have adopted the NAIC’s AI bulletin, and New York and Colorado set their own expectations.
Key Takeaways Underwriting automation is a spectrum, from assisted file preparation to automated referral to straight-through decisions on clearly in-appetite risks. A full workflow has seven steps, from intake and extraction through enrichment, scoring, referral rules and decision to an audit record. Define approve, refer and decline triggers before you choose a model, because referral rules shape every outcome the program produces. Rules own eligibility and authority, predictive models estimate risk, and generative AI and agents prepare files without authority to bind. Measure straight-through rate against eligible submissions only, and track referral, override and leakage rates next to speed. As of November 2026, 29 US jurisdictions have adopted the NAIC AI bulletin, and every automated decision needs reasons and sources you can show. Watch on YouTube
Reinventing Insurance Operations with Data and AI
Kanerika’s discussion of how data and AI change insurance operations, the groundwork any underwriting automation program sits on.
The Underwriting Queue That Grows Faster Than It Clears
Take a hypothetical small commercial desk on the first Monday of renewal season. At 8 a.m., 300 submissions wait in the queue, while new ones arrive at about 40 an hour. Yet the four underwriters on shift clear roughly 30 an hour between them.
In this example, about 250 of those files are clean renewals. Still, they wait in the same line as a 60-location schedule that needs senior judgment. Meanwhile, the one file with a real problem, a roof older than the guidelines allow, sits at position 214.
Underwriting automation is built for this queue. It prepares, scores and routes each submission, so clean risks are decided quickly and hard ones reach an underwriter first. The catch is that the routing rules, the data and the decision record do the real work, not the model.
What Is Underwriting Automation?
Underwriting automation is the use of software to prepare, score and route insurance submissions toward the right decision path. In other words, it covers the work between a broker’s submission and a bound quote. That span includes reading documents, checking data, applying guidelines and recording why each decision was made.
The term covers three different jobs, though, and they are easy to mix up. Software can prepare the evidence, recommend a decision, or issue a binding decision on its own. Each job carries a different level of risk, so each needs different controls.
Automation across the wider insurance value chain, from claims to servicing, is covered in the guide to automation in insurance . This guide stays with underwriting instead, from the first document to the decision record.
Three Levels: Assisted, Referral and Straight-Through
At the assisted level, software does the preparation and a person does the deciding. For example, it extracts fields, flags gaps and drafts a summary, and the underwriter still reviews every file. This level fits complex commercial and specialty lines, especially where pricing depends on judgment.
At the referral level, software scores each file and routes it. Clean files move to a fast lane, while anything outside set thresholds goes to an underwriter with the reasons listed. As a result, the underwriter still decides referred files but stops reading clean ones line by line.
At the straight-through level, software issues the decision for risks that meet every rule. A person writes those rules and then checks samples after the fact. This level fits high-volume personal lines and small commercial classes, particularly those with stable guidelines and good data.
In practice, the three levels describe how much routine work leaves the underwriter’s desk. Still, underwriters stay in charge of the rules and of the hard files at every level.
Insurance Underwriting vs Automated Underwriting in Lending
Insurance underwriting selects and prices risk, while lending underwriting judges whether a borrower can repay. Because of that overlap in names, the search term “automated underwriting system” also returns mortgage tools. For instance, Freddie Mac calls its Loan Product Advisor its automated underwriting system, and Fannie Mae runs Desktop Underwriter .
The legal rules also differ. In US lending, Regulation B requires a creditor to state specific reasons for adverse action, and that rule covers credit, not insurance. Banks that automate credit decisions face their own questions, which the guide to generative AI in banking covers.
How an Automated Underwriting Workflow Works, Step by Step
An automated underwriting workflow moves each submission through seven steps, shown as five stages in the graphic below. The order matters, because each step depends on clean output from the one before it.
Intake: the system collects the application and attachments from every channel.Extraction and validation: it reads the documents and then checks the values.Enrichment: it adds data from approved outside sources.Risk scoring: a model estimates how likely and how costly a loss could be.Appetite and authority rules: rules decide what the score is allowed to trigger.Decision and write-back: the file is approved, referred or declined, and the result reaches the policy system.Audit record: the system stores what it saw, what it did and why.To make this concrete, follow one illustrative file through the steps. A small accounting firm with 12 staff applies for a business owners policy through its broker. The sections below trace what happens to that application.
Steps 1-2: Intake, Extraction and Validation
Submissions arrive in several formats, such as emails, portal uploads, PDFs and spreadsheets. First, the system classifies each document, such as the application, the loss runs and a statement of values. Then intelligent document processing pulls out the fields underwriting needs, each with a confidence score and a link to its place on the page.
Validation then follows right away. The system checks that required fields exist, that totals add up and that the application agrees with the loss runs. When a value is missing or conflicting, it becomes a request to the broker, never a guess.
Confidence thresholds deserve the same care as risk thresholds. For example, total insured value needs a higher bar than a broker’s phone number. Set the bar per field, and then sample the results each week.
Next, the extracted fields should land in one schema that every later step reads. ACORD publishes insurance data standards for this purpose, from P&C XML and AL3 standards to newer API standards. Class codes and addresses also need normalizing, which the guide on data standardization explains.
For the accounting firm, the system reads the class code, the revenue figure and three years of losses. However, the building’s year of construction comes back with low confidence. Instead of guessing, the system sends the broker a request for that one value.
Step 3: Data Enrichment From Approved Sources
Enrichment adds data the applicant did not supply. Depending on the line, that can mean property details, motor vehicle records or prior loss data. Where state law allows it, the file can also include a credit-based insurance score. Each source should also sit on an approved list with a named owner.
Every value that enters the file also needs a source and a timestamp. That way, when someone questions a decision months later, the record shows exactly which data the system saw. Consumer report data brings extra duties under the Fair Credit Reporting Act, which the governance section below covers.
In the example, a property data service then returns a year of construction and a roof type. That value does not overwrite the broker’s answer, though. Instead, it sits beside the broker’s pending answer, and any conflict between the two gets flagged.
Steps 4-5: Risk Scoring, Appetite and Authority Rules
Scoring estimates how likely a loss is and how costly it could be. A predictive model trained on past policies and losses produces the score as well as the factors that drove it. Model types and pricing methods are covered in the guide to predictive analytics in insurance .
Rules then decide what the score is allowed to trigger. Appetite rules check the class of business, territory and limits against what the carrier wants to write. Authority rules, in turn, check whether the requested limit falls within what this desk, or this system, may approve.
That split matters more than it first appears, because a model and a rule answer different questions. A model can say a risk looks good, but only a rule can say the carrier writes that kind of risk at all.
Steps 6-7: Decision, System Write-Back and the Audit Record
Step 6 sends the file to one of three outcomes. It can be approved and quoted, referred to an underwriter, or declined with stated reasons. After that, the result has to reach the policy administration and rating systems.
That write-back should run through APIs or events rather than bots that copy values between screens. A screen-scraping bot fails when a screen layout changes, and that failure can go unnoticed. The guide to enterprise application integration explains the API and event patterns.
Finally, step 7 stores the decision record, the evidence for everything above. In other words, it holds the inputs, data sources, rule and model versions, score, reasons and any human action. Tracing each value to its origin is a data lineage problem, and it is far easier to design in than to rebuild later.
In this illustrative case, the firm’s file meets every rule once the broker confirms the year of construction. The quote then goes out, and the record shows which rules passed and which sources the system used.
Datasheet
Insurance Data Ingestion Accelerator for Databricks Lakehouse
Kanerika’s FLIP-powered accelerator processes policy documents, claims forms and bordereaux reports through AI-powered extraction, validation and standardization.
Get the Datasheet → Referral Rules: When to Approve, Refer or Decline
Referral rules are the written conditions that send a file to a person. Because they decide what the program does with every submission, they deserve more design time than the model. A short routing table also makes that logic easy to review.
Trigger Automated action Who reviews Evidence attached Low extraction confidence on a rating field Hold and request the value Intake team Source page and extracted value Application and loss run disagree Refer Underwriter Both values and their sources Class or territory outside appetite Decline or refer by rule Underwriter, for referrals The appetite rule that fired Limit above desk authority Refer upward Senior underwriter Requested limit and authority table Score in the uncertain middle band Refer Underwriter Score, top factors and model version Sanctions or watchlist match Stop and refer Compliance Match details and list source New class of business Refer every file Underwriter Full file, no score
How to Set Referral Thresholds and Keep Them Honest
Set thresholds by back-testing on past decisions, not by accepting a vendor default. For example, run last year’s submissions through the rules and compare the routing with what underwriters actually did. When the two disagree, either the rule or the guideline needs work.
Referral queues also need an owner and a service level. Otherwise, the backlog from the opening example simply moves from one queue to another. A human-in-the-loop design names who picks up each referral and how fast.
Every override needs a reason code, too. Review those codes before any override becomes a training label, because a rushed override can teach a model the wrong lesson. For more on splitting decisions between people and systems, see the guide to AI decision making .
Rules, Machine Learning, Generative AI and Agents: Who Does What
Each technology in an underwriting stack has one job. Trouble starts when one of them takes over another’s job. The list below sets out each role, together with the one thing it must never do.
Rules engine: owns eligibility, appetite and authority, so a model score must never override it silently.Document processing (OCR and IDP): reads submissions in steps 1 and 2, but must never fill a missing field with a guess.Predictive model: estimates loss likelihood and severity in step 4, but must never decide eligibility on its own.Generative AI: drafts risk summaries, broker emails and referral notes, but must never set a price or issue a decision.AI agent: coordinates tasks across steps and calls approved tools, but must never bind coverage.Generative AI belongs in the reading and writing work around a file, where a draft saves an underwriter time. The guide to generative AI in insurance walks through that work in detail, from summaries to broker correspondence.
Where AI Agents Fit, and Where They Stop
An agent can chase a missing loss run, assemble the file and then ask the scoring service for a result. That takes follow-up work off the underwriter’s day. Even so, the agent should work from a fixed list of allowed tools, with no authority to bind and every action logged.
Agents also face a risk that rules engines never had. OWASP describes indirect prompt injection , where text inside a file or web page changes how a language model behaves. A submitted PDF could carry hidden instructions, and for that reason the agent must treat document text as data, never as commands.
Every agent action should also land in the decision record. When an agent requests a document, calls a data service or drafts a note, the record shows when it happened and what came back. That way, a reviewer can follow the agent’s work as easily as an underwriter’s.
In short, an agent in underwriting is a coordinator with a short leash. The guide to AI agent guardrails covers tool allowlists, approvals and logging in more depth.
Kanerika Service
Agentic AI Services
Kanerika builds AI agents that work inside defined tools, permissions and approvals, with every action logged for review.
Explore Agentic AI Benefits of Underwriting Automation and the KPIs That Prove Them
The first benefit is time. In a 2021 survey of 434 US underwriters by Accenture and The Institutes, commercial lines underwriters spent about 40% of their time on non-core and administrative tasks. Redundant inputs and manual processes were the top reason, named by 71% of them.
Accenture’s own write-up of that research also put actual underwriting at 30% of the average underwriter’s time. Because the data dates from 2021, it works best as a direction rather than a current figure.
A KPI Scorecard for Underwriting Automation
Other benefits follow from the workflow itself. Clean files get quotes sooner, appetite rules apply the same way every time, and every decision leaves a record ready for an exam. Still, each benefit needs a number that proves it.
Metric How to measure it Watch alongside Straight-through rate Files decided without a person, divided by eligible files only Leakage and override rates Time to quote Median and 90th percentile, submission to quote Age of the referral backlog Referral rate Share of files sent to an underwriter Override rate on referrals Override rate Share of system recommendations an underwriter changes Reason codes behind them Extraction accuracy Correct values on rating fields, checked on samples Broker requests per file Post-bind leakage Premium or terms errors found in audits after binding Straight-through rate
In particular, measure straight-through rate against eligible submissions only. Counting files that were never candidates makes a program look worse, while counting only easy renewals makes it look better than it is.
Speed figures without override and leakage tracking can also hide a drifting loss ratio. For a first ROI estimate, multiply hours saved per file by file volume and loaded hourly cost, then subtract the run cost. The guide to insurance business intelligence shows how to report numbers like these to leadership.
AI Assessment
Is Your Underwriting Data Ready for AI?
Take Kanerika’s AI maturity assessment to score your data foundations, AI practices and governance before an underwriting pilot starts.
Start Your AI Assessment → Underwriting Automation Use Cases by Line of Business
Lines of business differ in how much work can move straight through. The pattern runs from high-volume personal lines, where straight-through decisions fit, to specialty risks, where automation mainly prepares the file.
In personal auto and homeowners , high volume and stable guidelines make straight-through decisions a strong fit. Colorado’s governance rule also covers private passenger auto, and telematics data brings its own consent questions.
For small commercial and business owners policies , class-code checks, appetite rules and loss-run reading automate well. On the other hand, unusual operations and large schedules of locations still go to an underwriter.
In mid-market and specialty commercial lines, automation prepares and triages the file, while underwriters price the risk. The gain is a complete, checked file on the desk from the start.
In individual life , accelerated underwriting uses data checks in place of medical exams for some applicants. Colorado’s rule covers life insurers, and the EU AI Act also treats life and health risk assessment as high-risk.
For group health and benefits , census intake and eligibility checks automate well, whereas pricing stays with underwriters and actuaries. Health benefit plans also fall under Colorado’s governance rule. For a wider view across lines, see Kanerika’s insurance solutions .
Governance, Audit Trail and the Rules That Apply
An automated underwriting decision has to be explainable to a regulator, a broker and sometimes a court. Even so, treat the summary below as planning guidance, not legal advice. Check the current text with counsel before you build.
What US Regulators Expect: NAIC Bulletin, New York and Colorado
The NAIC adopted its model bulletin on insurers’ use of AI systems on December 4, 2023. In particular, it expects insurers to keep a written AI systems program that covers underwriting, rating and pricing, including systems bought from vendors. As of November 2026, the NAIC’s adoption map shows 29 adopting jurisdictions, namely 27 states plus DC and Puerto Rico.
Four states have their own insurance AI rules or guidance instead, namely California, Colorado, New York and Texas. New York’s Circular Letter No. 7 , dated July 11, 2024, covers AI and external data in underwriting and pricing. It expects discrimination testing before production, on a regular cadence and after material changes.
Colorado, by comparison, signed SB21-169 into law on July 6, 2021. Its Amended Regulation 10-1-1 took effect on October 15, 2025. It sets governance rules for how life, private passenger auto and health benefit plan insurers use external consumer data and models. Insurers in those lines that use no such data or models file an officer-signed attestation each December 1.
Kanerika Service
AI in Insurance
Kanerika applies data engineering, analytics and AI to insurance work, from document intake to reporting and decision support.
See Insurance AI Solutions Adverse Decisions, Reasons and the FCRA
Adverse decisions carry the heaviest duties. Under the Fair Credit Reporting Act, adverse action includes denying insurance or raising its price in connection with underwriting. When that action rests even partly on a consumer report, the insurer must notify the consumer .
New York also goes further on reasons. Circular Letter No. 7 says the reasons for an adverse underwriting decision should include the source of the information relied on. It also says an insurer may not rely on a vendor’s proprietary algorithm to justify a lack of specific reasons.
For that reason, vendor models need the same documentation as in-house ones. The guides to AI vendor risk assessment and AI model risk management cover those controls in detail.
What Goes in an Underwriting Decision Record
A decision record is the file that proves what happened. It should let a reviewer replay a decision months later without asking anyone. In practice, it holds the following items.
References to every input document and the page each value came from. Data sources, with their versions or retrieval timestamps. Rule set and model versions in force at the time. Score, reason codes and the routing path taken. The reviewer, any override and its reason code. Timestamps for each step and a copy of any notice sent. Fairness testing methods sit outside this record, and the predictive analytics guide linked earlier covers them. Similarly, the guide to AI governance in financial services explains how records like this fit a wider governance program.
EU AI Act for Life and Health Insurers
Insurers with EU business face one more rule. The EU AI Act’s Annex III lists AI used for risk assessment and pricing of individuals in life and health insurance as high-risk. However, property, casualty and commercial underwriting are not on that list.
As of November 2026, the European Commission states that rules for these high-risk uses apply from December 2, 2027. Life and health carriers should therefore plan their documentation and testing against that date.
Common Pitfalls in Underwriting Automation
The six pitfalls below are design mistakes to plan around. Each one comes with the control that prevents it.
Automating unwritten guidelines: if underwriters apply rules nobody wrote down, the system copies the inconsistency. Instead, write and version the guidelines first.Trusting values without provenance: an extracted number with no link to its page cannot be checked. So store the source with every value.Chasing a touchless target: pushing the straight-through rate up can let poor risks through. Watch leakage and override rates at the same time.Moving the backlog instead of clearing it: a referral queue with no owner becomes the new bottleneck. Give each queue an owner and a service level.Silent changes: a new model, prompt, data feed or document format can shift results overnight. Run a fixed regression set before every release.Fragile integration: screen-scraping into a legacy policy system breaks when a screen changes. Use APIs or events instead.When you build that regression set, the guide to AI agent evaluation describes the method. Where an old policy system cannot support APIs at all, plan an insurance data migration before you automate around it.
Checklist
Enterprise AI Checklist
A practical checklist for AI readiness, governance and adoption, covering the controls an automated decision program needs before release.
Get the Checklist → Historical labels also deserve care. After all, past decisions reflect past underwriter habits, and a model trained on them can repeat old bias. New York’s discrimination testing expectations, covered above, are one check on that risk.
How to Implement Underwriting Automation: A Phased Roadmap
A first program should start as a bounded pilot with clear exit criteria. The path below follows an illustrative 90-day pilot, a typical shape rather than a promise.
Pick the First Workflow and Set the Baseline
Choose the first workflow by volume, manual effort, data readiness and the cost of a wrong call. Evidence preparation or referral routing makes a safer first pilot than end-to-end binding. Both remove manual work while every decision stays with a person.
Before building anything, measure the KPIs from the scorecard above on current work. Without that baseline, nobody can show later that the pilot changed anything.
Keep the scope narrow as well. A workflow that touches one line, one channel and one policy system is easier to measure. Once it proves itself, the same rules and records then extend to the next line.
Build, Test in Shadow Mode, Then Release With Limits
Back-test the rules and models on historical submissions, including the incomplete and contradictory ones. Then run in shadow mode, where the system records its recommendation while the underwriter’s decision stands unchanged. Comparing the two shows where the rules or models disagree with experienced judgment.
Only then release to live work, with thresholds, a rollback plan and an incident path. Generated summaries also need their own test set, and the guide to LLM-as-a-judge explains one way to score them at scale. For the data platform side, see also the guide to Databricks for insurance analytics .
Buy, Build or Extend: Questions for Any Vendor Demo
Carriers can buy an underwriting platform, build on their own data platform, or extend the policy system they already run. The right choice depends on how distinct your guidelines are as well as how much of the stack you want to own. Whatever the route, ask every vendor to prove these points live in the demo.
Process an incomplete, contradictory submission instead of a clean sample file. Show an underwriter override and the record it leaves behind. Export a decision with its reasons and data sources, as New York expects. Version a rule change, then roll it back. Explain where data is stored and how you hear about model or data changes. How Kanerika Helps Insurers Automate Underwriting
Kanerika has not published an underwriting automation case study. Instead, the insurance work it can point to sits on the data and automation layers that an underwriting program depends on.
Insurance Work We Can Point To
One client, an advisor to member-owned group captive insurers, had previously reconciled underwriting and financial data by hand. Kanerika then unified four systems, including a PEGA policy administration system, on Microsoft Fabric. The captive insurance analytics case study reports 40% faster board and executive reporting and 100% elimination of manual data reconciliation.
A second project worked on claims rather than underwriting. For an insurer covering healthcare, travel and accident lines, AI and ML-driven RPA checked claims for fraud before payment. The insurance fraud detection case study reports a 20% reduction in claim processing time and 36% cost savings.
Case Study
100% Manual Data Reconciliation Eliminated for an Insurance Advisor
Kanerika unified four core systems, including PEGA policy administration, on Microsoft Fabric for an advisor to group captive insurers, with 40% faster board and executive reporting.
Read the Case Study → Where Kanerika Fits in an Underwriting Program
On the data side, Kanerika’s data engineering services build the pipelines behind intake and enrichment. Its Insurance Data Ingestion Accelerator for Databricks Lakehouse also processes policy documents, claims forms and bordereaux reports through AI-powered extraction, validation and standardization.
For governance, Kanerika’s data governance services put lineage, access controls and data ownership in place. Bounded agents for file assembly fall under its agentic AI services . Also, KlarityIQ , a document agent, gives teams quick answers over business files at scale.
When teams scope an underwriting program, they can talk to Kanerika’s experts about their own submissions and rules. For AI across the rest of the insurance value chain, see the AI in insurance page.
Underwriting Automation That Clears the Right Files First
The Monday queue from the opening grew because every file waited in one line. Underwriting automation changes the order. Routine, in-appetite submissions move straight through, while unclear or high-stakes files reach an underwriter first, with the evidence and reasons attached.
Build it in that sequence. First write the referral rules, then fix the data underneath, and keep a decision record that shows every reason and source to a regulator. The model comes last, and it only works on top of those three.
Frequently Asked Questions
What is underwriting automation?
Underwriting automation is the use of rules, data services and AI models to prepare, score and route insurance submissions. It extracts and checks the application, adds approved outside data, scores the risk and applies appetite and authority rules. Clean risks can go straight through, while unclear or high-stakes files reach an underwriter with the evidence attached.
How does automated underwriting work?
A typical automated underwriting workflow has seven steps. It takes in the submission, extracts and validates the data, enriches it from approved sources and scores the risk. Rules then decide whether to approve, refer or decline, the result is written back to the policy system, and a decision record stores the reasons and sources.
What is the difference between automated underwriting and AI underwriting?
Automated underwriting is the wider term for any software that prepares, scores or routes submissions, including plain rules engines. AI underwriting refers to the parts that use machine learning or generative AI, such as risk scores, document reading or drafted summaries. A sound program uses both, with rules keeping authority over eligibility and binding.
Will underwriting be fully automated, or will underwriters still be needed?
Underwriters will still be needed. Automation can decide clean, in-appetite risks that meet every written rule, but people write those rules, review referred files and handle complex or new classes of business. In specialty and mid-market commercial lines, automation mainly prepares the file, while underwriters still judge and price the risk.
How long does automated underwriting take?
There is no standard benchmark, because timing depends on the line, the data and the rules. For clean straight-through files, a decision within minutes is a design target rather than a guaranteed result. Referred files take as long as the referral queue allows, which is why each queue needs an owner and a service level.
How accurate is automated underwriting?
No universal accuracy figure exists, and any vendor quoting one should show how it was measured. Track field-level extraction accuracy on sampled files, the rate at which underwriters override system recommendations, and errors found in post-bind audits. Together, those three measures show whether the program decides well on your own book of business.
What happens when an application fails automated underwriting?
A failed check leads to referral or a request for information, not straight to rejection. The file goes to an underwriter with the reasons and evidence attached, or the system asks the broker for missing information. If the decision is adverse and relies on a consumer report, US law requires the insurer to send the consumer an adverse action notice.
What data does underwriting automation need?
It needs the application, loss runs, schedules and statements of values from the broker. It also uses approved outside data such as property details, motor vehicle records, prior losses or credit-based insurance scores where state law allows. Every value should carry its source and timestamp, so later reviews can trace exactly what the system saw.
What regulations apply to AI in insurance underwriting?
As of November 2026, 29 US jurisdictions have adopted the NAIC model bulletin on insurers’ use of AI. New York’s Circular Letter No. 7 and Colorado’s Regulation 10-1-1 set their own expectations. The FCRA covers adverse actions based on consumer reports, and the EU AI Act treats life and health risk assessment as high-risk.
What is Freddie Mac's automated underwriting system called?
Freddie Mac’s automated underwriting system is called Loan Product Advisor, or LPA. Fannie Mae’s equivalent is Desktop Underwriter, or DU. Both are mortgage lending tools that check loans against agency eligibility rules, so they belong to credit underwriting rather than the insurance underwriting automation this guide covers.
How do you choose underwriting automation software?
Judge any platform on your own messy files, not a polished demo. Ask the vendor to process an incomplete submission, show an underwriter override and its record, and export a decision with its reasons and data sources. Also check rule versioning and rollback, data residency, and how you are told about model or data changes.
