Underwriting Automation: Build vs Buy vs Configure

Underwriting automation pays off fastest when you settle the build, buy, or configure question before you evaluate a single vendor. Most carriers already run a policy administration system with a rating engine and a rules layer inside it, so the question is rarely “which tool” and almost always “which path.”

The hard part is that vendor content cannot answer it, and most listicles are written by people who have never migrated a product model or reconciled a loss run. Meanwhile, the submissions arriving from brokers keep breaking whatever you deploy.

That is why we wrote this guide from the engineering side of insurance software development.

We cover what automation touches in the underwriting process, why multi-source submission data defeats OCR, how to compare the four paths on eight criteria, how filing-guideline validation works, what US regulators now require, and where straight-through processing stops.

By the end, you will know which path fits your lines and your policy admin system, which data gaps to close first, and which metrics prove the program works.

What Underwriting Automation Automates

Underwriting automation is software that ingests a submission (ACORD applications, loss runs, statements of values, broker notes), screens it against appetite guidelines, enriches it with bureau and third-party data, prices it through a filed rating engine, routes exceptions to an underwriter through referral triage, and issues the policy with an audit trail.

The process has seven stages, and each one fails differently. Robotic process automation in underwriting handles screen-level work in the first two stages, machine learning covers risk assessment, and the rating engine inside your policy admin system owns pricing.

Seven stages of the underwriting process

Stages three and four are where machine learning engineering earns its budget. Stages one, two, and six are integration work, and our insurance process automation practice usually starts at stage one, because nothing downstream works on incomplete input.

Rules engine vs rating engine: why the difference is regulatory

A rating engine calculates premium from the rate plan your carrier filed with the state, so its logic is a regulated artifact. A rules engine decides eligibility, declination, and referral, and in a number of states those underwriting rules are filed as well.

The NAIC Product Filing Review Handbook 2024 lists what carriers submit for review as “rates, rating rules, policy forms, underwriting rules, etc.”

For architecture, that means a rule you change in a BRMS on Tuesday may be a rule you were supposed to refile on Monday. Keep rating, eligibility rules, and their version history in systems that can prove what was in force on any given effective date.

The Submission Data Problem Nobody Solves With OCR

Risk engineers and underwriters need automated solutions for consolidating multi-source underwriting information, and OCR is the smallest part of that job. Reading a page is solved. Reconciling six documents that describe the same insured in six formats decides whether a submission reaches the rating engine untouched.

Two surveys size the cost:

• A 2022 Accenture survey of 434 US underwriters found that underwriters spend 40% of their time on non-core activities.
• The Sixfold Future of Underwriting report, fielded in Q1 2026 across 543 underwriters in the US and Europe and commissioned by a vendor, puts eight in ten underwriters at between 30 minutes and four hours chasing missing information from brokers on a single risk.

The same pattern shows up across enterprise underwriting and claims intake workflows. The bottleneck sits between documents, in the joins.

What arrives in a commercial submission

A commercial package arrives as a broker email with attachments. The core set includes:

• The commercial application with the insured’s identity, locations, and requested coverages.
• The general liability section with hazard classifications and payroll or sales figures.
• The property section with construction, occupancy, protection, and year built per location.
• The business auto section with vehicles, drivers, and radius of operation.
• The workers’ compensation section with payroll by class and loss history.
• Three to five years of loss runs, a statement of values, financial statements, supplemental applications, and the broker’s cover note explaining what the forms do not.

Personal lines pull a different set: a CLUE report from LexisNexis with up to seven years of claims history, motor vehicle records, a credit-based insurance score where the state allows it, and bureau data from ISO/Verisk, NCCI, or AAIS.

Submission intake platforms improve underwriting responsiveness only when they know which sources a given line needs and which absence stops straight-through processing. That map is the first artifact we build with a carrier.

Submission Data Completeness Map

Why loss runs break automated ingestion

Loss runs have no standard. One prior carrier reports incurred losses, another reports paid plus reserved, and allocated loss adjustment expense appears as a separate column in one file and folded into indemnity in the next.

Extracting the numbers is easy. Knowing which claim belongs to which policy and which policy year takes a data model, which is the same pipeline problem we described when explaining how to rebuild a data pipeline for unreliable sources.

Four things break on the way in:

1. ACORD forms rarely arrive as ACORD. Brokers send retyped versions, partially completed PDFs, and their own agency templates. The format is standardized; the flow is not.
2. There are two different ACORDs. One is the library of paper forms with more than 850 variants. The other is the set of data exchange standards: AL3 for flat-file batch, XML for near-real-time exchange, GRLC for large commercial and reinsurance, and the NGDS Object Model launched on August 28, 2025. AL3 has no public retirement date, so plan to parse it.
3. Loss run semantics differ by carrier, as described above, so every prior carrier needs its own mapping to a common claim model.
4. Entity resolution. The same insured shows up under a legal name in the application, a DBA name on the loss run, a parent entity in bureau data, and a third spelling in your clearance registry. Matching on FEIN, address, and subsidiary structure, or clearance will produce both duplicates and false clears.

What you are not allowed to pull: DPPA and FCRA limits

The “enrich everything up front” architecture fails on legal grounds before it fails on cost. Two federal statutes set the boundary.

• The Driver’s Privacy Protection Act restricts use of DMV records to permissible uses, so pulling every driver’s record at submission for risks you may decline needs a defined purpose.
• Under the Fair Credit Reporting Act, CLUE reports, motor vehicle records, and credit-based insurance scores are consumer reports. An adverse action such as declination, cancellation, or a premium increase triggers an adverse action notice naming the consumer reporting agency, and the FTC notes the notice is required even when the report played a small part in the decision.

Design enrichment as a staged pull tied to the decision that needs it. Appetite and clearance first, consumer reports only once the risk is in appetite, and every pull logged with its purpose.

Build vs Buy vs Configure: Which Path Comes First?

Configure first, buy for the intake gap, build only where decision logic is your competitive edge. That order holds for most US carriers because the policy administration system already contains a filed rating engine and a rules layer, and replacing either one restarts your filing calendar. The exceptions are carriers whose differentiation lives in the rules themselves.

Four paths exist on the market:

• Configuring the PAS you already run.
• Adding a business rules management system on top of it.
• Buying a specialized product for intake or an underwriting workbench.
• Building custom.

Insurance underwriting automation tools from any of these categories pay off only when they sit in the right slot. The table compares the four on eight criteria.

Build vs buy vs configure on eight criteria

The mistake we see most often is treating the table as a ranking. Each row has a scenario where it wins, and the scoring changes by line. A personal auto book with stable rules configures well, while a specialty book with negotiated terms rarely fits any vendor product model.

Our underwriting automation services start with this scoring before any code.

When configuring your existing policy admin system is the right answer

Configuration wins when your lines, rating plan, and eligibility rules fit inside the vendor’s product model. Duck Creek, Guidewire, and Sapiens each expose a product definition layer where rating tables, forms attachment logic, and underwriting rules are maintained without custom code, and those platforms already carry the filing versioning your regulator expects.

The economics are simple. You have paid the license, your team knows the upgrade path, and the vendor’s release cadence includes state-specific changes you would otherwise track yourself.

Configuration is the right call when:

• Your competitive edge is distribution or claims service, and underwriting rules are table stakes.
• Your rules change at roughly the same pace as the vendor’s release cycle.
• Your intake data already lands inside the PAS in structured form.

The limit is the release cycle. If your rules change monthly and the PAS moves quarterly, a BRMS on top handles eligibility and referral logic at your pace while the rating engine stays inside the PAS. Every rule version must then be logged with its effective date, or the two layers drift, and you lose the ability to prove what was in force.

Configuration also fails when the data you need never enters the PAS. Submission intake, loss run parsing, and enrichment happen before the policy exists, and no PAS is built for that. A specialized intake product or a custom intake layer sits there, feeding the PAS a complete, resolved submission.

When custom development is justified and when it is not

Custom insurance underwriting software development is justified when the decision logic is the business. Three carrier profiles hit that wall:

• Specialty carriers pricing on proprietary risk models.
• MGAs operating across multiple carrier papers with different rules per paper.
• Insurers whose intake spans data sources no vendor supports.

The strongest argument for building is control over the audit trail. When every rule, data pull, and model score is your code, you can produce the lineage a state regulator asks for without waiting on a vendor’s logging roadmap. That provability is why we design custom underwriting systems around versioned rules and decision records from the first sprint.

Proof from adjacent territory: for a US consumer-finance marketplace, we migrated the loan origination system to Salesforce and automated disclosures, underwriting, and document workflow, cutting issuance operating costs by 50% and shortening the cycle. That was credit underwriting, and we say so directly.

What transfers is the mechanics of rules orchestration, document workflow, and an auditable decision record, the same foundation we apply in lending platform engineering. The regulatory frame stays with insurance, which is why this article includes filing sections.

Custom is the wrong answer when:

• Your volume cannot support a standing engineering team.
• Your rules are stable and standard across the market.
• The thing you are trying to fix is intake, and decisioning already works.

Our engagement with Kin Insurance, a US home insurance carrier, focused on expanding engineering capacity, quality assurance, and automation across an existing platform. That is the more common shape of the work.

How Do Insurers Validate Programs Against Filing Guidelines?

Insurers validate programs against filing guidelines by comparing every issued policy with what was filed through SERFF for that state and effective date: the rating factors applied, the forms and endorsements attached, and the product metadata on the filing itself. Anyone asking who offers automated validation of insurance programs against filing guidelines is asking for that comparison to run on every issuance, ahead of a market conduct exam.

State rating law sets the stakes. Depending on the state, a rate change runs under one of six regimes:

• Prior approval.
• Modified prior approval.
• Flex rating.
• File and use.
• Use and file.
• No file.

Under every regime, the NAIC Property and Casualty Model Rating Law (#1780) standard applies: rates may be neither excessive, inadequate, nor unfairly discriminatory. A mismatch between what your engine applied and what you filed may constitute an unfiled rate, which is material to market conduct action and premium refunds.

What SERFF is and what it processes

SERFF is the System for Electronic Rate and Form Filing, operated by the NAIC. According to the NAIC Product Filing Review Handbook 2024, nearly every jurisdiction accepts rate and form filings through it: “More than 7,000 insurance companies, third-party filers, advisory organizations, and other companies make filings electronically through SERFF to the individual jurisdictions. SERFF processes over half a million transactions annually.”

Note that 7,000 counts four categories of filers, so it is a filer count and never an insurer count.

The “filing guidelines” a validation service checks against are the uniformity layer around SERFF:

• Uniform Review Standards Checklists per state and product.
• Uniform Transmittal Documents, whose fields are built into SERFF.
• Uniform Product Coding Matrices, updated annually with changes effective January 1.

The Interstate Insurance Product Regulation Commission, known as the Compact, has accepted filings since 2007 for life, annuity, disability income, and long-term care products. P&C filings still state by state, so a validation registry must be versioned per state.

The three things automated validation checks

Software that ensures insurance programs meet filing guidelines efficiently performs three comparisons on every issuance:

1. Applied rating factors and rules against the rate and rule schedule filed for that state and effective date.
2. Attached forms and endorsements against the filed form numbers and edition dates.
3. Filing metadata against the state’s Product Coding Matrix codes and review checklist.

SERFF is a filing channel, so the runtime comparison needs a machine-readable filing registry on your side. Building that registry, with effective dates and version history per state, is most of the engineering work.

Filing-Validation Checkpoint List

What US Regulators Now Require of Automated Decisions

The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, adopted by the Executive Committee and Plenary on December 4, 2023, requires a written AI Systems Program under senior management accountable to the board. As Sullivan & Cromwell’s summary of the bulletin notes, it sets principles-based standards for insurers that use AI.

The bulletin applies four existing model acts to automated decisions:

• Unfair Trade Practices Model Act (#880).
• Unfair Claims Settlement Practices Model Act (#900).
• Corporate Governance Annual Disclosure Model Act (#305).
• Property and Casualty Model Rating Law (#1780).

The bulletin is proportional to potential consumer harm. Two of its proportionality factors map directly onto underwriting automation: how involved a human is in the final decision, and how transparent and explainable the outcome is to the consumer.

Section 4 lists what a state department may request, and it reads like a contractor’s scope of work:

• An inventory of predictive models and AI systems.
• Documentation of data lineage, quality, integrity, bias analysis and data currency.
• Validation, testing and audit records, including assessment of model drift.
• Third-party due diligence and contracts with model and data vendors.

Most carriers cannot yet answer that request on demand. In Grant Thornton’s 2026 AI Impact Survey, fielded February 23 to March 18, 2026, 44% of the insurance subsample (n=100) said governance and compliance issues contributed to failed AI projects, and only 24% were very confident they could pass an independent review within 90 days.

This is why regulatory compliance engineering belongs in the underwriting program from the first sprint.

Where state rules diverge from the NAIC bulletin

As of August 31, 2026, 26 jurisdictions have adopted the NAIC bulletin, 25 states plus the District of Columbia. The latest is Mississippi, which adopted it through Bulletin 2026-9 on July 22, 2026.

Four large states sit outside that list with their own regimes:

• California: Bulletin 2022-5.
• Colorado: 3 CCR 702-10.
• New York: Insurance Circular Letter No. 7 of July 11, 2024.
• Texas: Bulletin B-0036-20.

Colorado is the most prescriptive. Its amended Regulation 10-1-1 took effect on October 15, 2025 and extended governance and testing requirements beyond individual life to private passenger auto and health benefit plans. Commercial lines are outside its scope. Starting July 1, 2026, the Division of Insurance may request evidence of compliance from auto and health benefit plan insurers.

The broader Colorado AI Act (SB24-205) is a general statute, and its enforcement was stayed in April 2026 pending litigation, so the insurance-specific regulation is the operative text for carriers.

Enforcement has started. In May 2026, Pennsylvania Attorney General Dave Sunday announced an agreement with GEICO after the company used an AI tool to select a new Philadelphia policyholder for additional verification during its standard 60-day new customer review. The policy was cancelled over missing documentation, a procedural decision, and the AI tool’s role was selecting the policyholder for review.

Under the agreement, GEICO:

• Follows the Pennsylvania Insurance Department’s AI guidance.
• Adds a week to the documentation deadline for policyholders selected for review.
• Accepts one proof of residence in place of two.

This section is an engineering reading of the rules and does not constitute legal advice; confirm it with counsel before relying on it.

Where Does Straight-Through Processing Stop?

Straight-through processing stops at the boundary of decision type and distribution channel, and that boundary is stable. Personal lines are standardized and sold direct, so the carrier controls the data format. Large commercial and specialty risks arrive through brokers who have no obligation to submit machine-readable data, and that incentive sits outside any intake platform’s control.

The gap between personal and commercial STP is a market structure fact. Treating it as an IT backlog produces programs that automate the wrong things.

Submissions fall out of straight-through processing for five reasons:

1. No appetite match on class, state, or hazard.
2. Incomplete package, most often loss runs for the required years or a missing statement of values.
3. Contradiction between sources, such as payroll on the application that fails to match the workers’ compensation history.
4. Limits or capacity beyond the automated authority.
5. Risk characteristics that require a physical inspection.

Underwriting also continues after bind. The GEICO case above shows an AI tool operating during a post-bind 60-day review, the clearest evidence that instant bind and completed underwriting are different events. Design your automation so that post-bind verification carries the same audit trail as the initial decision.

Can an AI agent underwrite? What the benchmarks show

Current benchmark evidence supports AI agents as assistants inside the underwriting workflow and argues against agents as the final decision-maker. The UNDERWRITE benchmark (Dsouza, Ramakrishnan, Dickens, Pohani and Glaze, “Benchmarking Agents in Insurance Underwriting Environments,” arXiv:2602.00456, January 31, 2026) tested 13 frontier models in simulated underwriting environments.

Two findings matter for architecture:

• Its pass^k results show a 20% drop in performance when tasks are re-run.
• The models “hallucinate domain knowledge despite tool access.”

That result argues for agents as intake assistants and referral drafters, with the decision held in versioned rules and the underwriter’s authority. A system that gives a different answer on the second run cannot produce the lineage a regulator asks for.

What to Measure Instead of Accuracy

Headline accuracy is the wrong metric for underwriting automation, because it is measured on the documents that got through. If a large share of submissions lands in an exception queue for a human, the model can be 98% accurate on the rest, and the program still fails.

The metric that matters is the share of submissions that travel from receipt to a bound record without a human touch, with the reasons for every exception counted. Underwriting audit software and monitoring should report the numbers below, per line, per month.

Metrics that replace headline accuracy

Two of these deserve a note.

The audit trail share is the number a regulator will test first. For the same consumer-finance client mentioned above, centralizing consent management cut compliance audits from manual cross-system exports to minutes, and underwriting decision records need the same treatment.

Model drift matters because the industry is early. The WTW 2026 Advanced Analytics & AI Survey of 59 US and Canadian P&C insurers, published March 19, 2026, found that only 16% currently use AI to augment human underwriting, with 60% of insurers planning to prioritize this between now and 2028.

The financial case for measuring intake quality has been on the table for years. Verisk estimated premium leakage at at least $29 billion annually, or 14 percent of personal auto premiums collected (Verisk, 2017). The number is nine years old and remains the most cited figure in the category.

Final Word

Choosing a path for underwriting automation takes work. You have to score your policy admin system against your rules, inventory the sources each line needs, read your filing calendar, and accept that the broker channel will keep sending PDFs.

That work is worth doing before the vendor demos.

A wrong path costs more than a failed pilot. It costs a refiling cycle you did not plan for, an exception queue that grows faster than the automation empties it, and a Section 4 request you cannot answer with a report. A right path gives you complete submissions, decisions with lineage, and a rules layer that changes at your pace.

Start with the eight-criteria table, score your own lines against it, and close the intake data gaps before you touch decisioning. If you have read this far, you already know which row you are in.

If you want a second opinion from engineers who have done this in both insurance and lending, our team provides insurance underwriting software development services and is ready to review your PAS, your intake flow, and your filing constraints before you commit to a path.