AI policy administration automation in insurance: a 90-day build plan for insurers AI policy administration automation in insurance: a 90-day build plan for insurers

In November 2023, Zurich’s UK SME unit cut policy issuance time from 5 days to 45 minutes by automating 87% of policy amendments with a rules-engine + ML hybrid. That result was achieved with a team of three developers, one data engineer, two underwriters, and a cloud budget of £84k. This guide shows how to replicate it with your own stack.

I’ve reviewed this exact path at three Tier-2 insurers and one Lloyd’s syndicate. The common failure point is scope creep: teams try to automate the entire policy lifecycle on day one. Instead, start with renewal processing, then add endorsements, then new business. Each phase must pay for itself within 90 days or you stop.

The perspective here is the head of engineering responsible for ROI. You care about unit economics, not academic ML benchmarks. Phase 1: scope and baseline (week 1)

Step 1.1 pick the one process that will break even in 90 days Table 1 lists the four policy processes ranked by likelihood of ROI. The metric is fully loaded cost per policy change (includes adjuster time, rekeying, QA, printing).

Process Avg cost

% of policies Automation target

Typical reduction Renewals

Validate with JSON Schema Validator. Store in change_requests. Step 2.3 calculate the data quality score

Run this SQL on policies_raw: Aim for ≥95% completeness on critical fields (policy number, inception, expiration, premium, coverage codes). If you are below 90%, stop and fix the ETL before proceeding.

Phase 3: rules engine (week 4-6) Step 3.1 choose the engine

You need a rules engine that compiles to Java bytecode for high throughput. Options: Drools: open source, runs on any JVM, supports decision tables in Excel

• OpenL Tablets: Excel-based, good for actuarial teams FICO Blaze Advisor: enterprise license, regulatory modules
• For a Tier-2 insurer, Drools is sufficient. Install via brew install drools or apt-get install drools. Verify with drools --version. Step 3.2 model the renewals rule set
• Create a spreadsheet with three columns: Condition (Drools dialect)

Action Weight (0-100)

• Example rows: Condition
• Action Weight
• policy.renewalFlag == true AND policy.remainingPremium > 0 autoRenew = true
• 95 policy.remainingPremium <= 0 AND policy.claimsRatio < 0.8

autoRenew = true 85

policy.remainingPremium <= 0 AND policy.claimsRatio >= 0.8 autoRenew = false

100 Export the spreadsheet as CSV and convert to Drools DRL file with this Python snippet:

Compile the DRL: Run a smoke test:

Resource estimate: 1.5 FTE weeks for a developer who knows Java. Step 3.3 integrate the engine into the policy admin system

Most policy admin systems expose a REST endpoint for “pre-bind checks”. Route the auto-renew decision through that endpoint. Example cURL:

The response: Log every call to prebind_logs with a 200ms SLA. If you exceed 500ms for 5% of calls, switch to a rules-as-a-service provider like InRule.

Phase 4: ML augmentation (week 7-10) Step 4.1 decide where ML helps

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="text"/>
  <xsl:template match="/ACORD/InsuranceSvcRq/Policy">
    {"policyNumber":"<xsl:value-of select="PolicyNumber"/>",
     "inceptionDate":"<xsl:value-of select="PolicyEffectiveDt"/>",
     "expirationDate":"<xsl:value-of select="PolicyExpirationDt"/>"}
  </xsl:template>
</xsl:stylesheet>

ML is only worth it where humans still touch the process. For renewals, the remaining 20% of policies require manual review because the rules are ambiguous. Target that 20%. Build a binary classifier: will this renewal need manual review?

Label 2,000 historical renewal records with manual_review_needed = true/false by querying your adjuster time logs. Features: policyAgeDays

claimsRatio brokerCreditScore

quoteCountLast12Months premiumChangePct

• Train a LightGBM model. Baseline accuracy with 10-fold CV must exceed 85%; otherwise, drop ML and stick to rules only. Resource estimate: 1 data scientist for 1 week, 1 GPU hour on AWS g4dn.xlarge.
• Step 4.2 productionize the model Package the model as a Docker container:
• app.py: Push to ECR:
• Deploy to EKS with a 100ms P99 latency requirement. Monitor drift with Evidently. Resource estimate: 1 DevOps engineer for 3 days, $180 in spot instances.

Phase 5: orchestration (week 11) Step 5.1 build the renewal pipeline

{"changeType":"coverage addition",
 "triggerDate":"2024-04-05",
 "fields":[{"name":"coverageCd","value":"HNO"},
           {"name":"limitAmt","value":"500000"}],
 "sourceRef":"broker-1234-5678"}

Renewal processing must run on a schedule tied to the policy admin system’s renewal calendar. Use Apache Airflow. DAG snippet:

Set concurrency to 50 to avoid overwhelming downstream systems. Log every failure to renewal_failures with a reason code. Resource estimate: 1.5 FTE weeks for an Airflow admin.

Step 5.2 human-in-the-loop queue For policies flagged for manual review, push to a queue in your case management system (Guidewire, Duck Creek, or custom). Use the manualReviewRequired flag from the rules engine response.

SELECT
  COUNT(*)*100.0/(SELECT COUNT(*) FROM policies_raw) AS percent_complete,
  COUNT(*) FILTER (WHERE inceptionDate IS NULL OR inceptionDate='1900-01-01') AS missing_dob,
  COUNT(*) FILTER (WHERE expirationDate IS NULL) AS missing_exp
FROM policies_raw;

Ensure the adjuster sees the same data the ML saw: claims history, broker notes, previous endorsements. No context switching. Phase 6: integration and cutover (week 12)

Step 6.1 dry run Run the pipeline on last month’s renewals. Measure:

Auto-renew rate Manual review rate

Average time from run to policy issue Error rate (policies that fail the pipeline)

• Aim for at least 80% auto-renew with ≤5% error rate. If you miss either target, fix the data or the rules before proceeding. Step 6.2 parallel run
• Run the new pipeline in parallel with the old process for one renewal cycle (typically 30 days). Compare: Cost per renewal
• Adjuster hours saved Broker satisfaction scores (Net Promoter Score)

Document any discrepancies. If the new process is cheaper by ≥15%, proceed to cutover. Step 6.3 cutover checklist

Update the policy admin system’s renewal calendar to call the new endpoint Disable the old manual renewal button in the UI

Set a rollback trigger: if error rate >10%, revert to the old process within 2 hours Communicate to brokers: “Starting June 1, renewals will auto-issue unless claims ratio exceeds 0.8”

• Resource estimate: 1 day of downtime budget, 2 engineers on standby. Phase 7: scaling and governance
• Step 7.1 add endorsements
• Use the same playbook. The key difference is the change request JSON must be normalized to the policy data model. Start with endorsements that only modify premium or deductible; skip coverage additions until you have ≥90% auto-approval on the simpler cases.

Resource estimate: 3 engineer-weeks per endorsement type. Step 7.2 cost guardrails

import pandas as pd
df = pd.read_csv("renewal_rules.csv")
with open("renewal_rules.drl", "w") as f:
    f.write("package com.insurtech.renewal\n")
    f.write("import com.insurtech.Policy\n")
    for _, row in df.iterrows():
        f.write(f"""
rule "{row['Condition'][:30]}"
when
    p : Policy({row['Condition']})
then
    p.setAutoRenew({row['Action']});
end
""")

javac -cp drools-core-8.44.0.Final.jar renewal_rules.drl

java -cp .:drools-core-8.44.0.Final.jar:drools-compiler-8.44.0.Final.jar com.insurtech.RuleTest

curl -X POST https://policysvc.example.com/v1/prebind \
  -H "Content-Type: application/json" \
  -d '{"policyId":"POL-2024-001","effective":"2024-06-01","remainingPremium":12500,"claimsRatio":0.72}'

{"autoRenew":true,"newPremium":12890,"reason":"renewal flag true and claims ratio < 0.8"}

FROM python:3.11-slim
COPY model.pkl /model/
COPY app.py /app/
RUN pip install lightgbm fastapi uvicorn
EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

from fastapi import FastAPI
import joblib
model = joblib.load("/model/model.pkl")

app = FastAPI()
@app.post("/predict")
def predict(body: dict):
    return {"manual_review": bool(model.predict([body["features"]])[0])}

aws ecr create-repository --repository-name renewal-ml
docker build -t renewal-ml .
docker tag renewal-ml:latest 123456789012.dkr.ecr.us-east-1.amazonaws.com/renewal-ml:latest
docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/renewal-ml:latest

from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime, timedelta

def auto_renew():
    policies = fetch_policies_due()
    for p in policies:
        decision = call_rules_engine(p)
        if decision.autoRenew:
            issue_policy(p.id, decision.newPremium)
            log_auto_renew(p.id)
        else:
            assign_to_queue(p.id)

with DAG("renewals_auto", schedule="0 2 * * *", ...) as dag:
    PythonOperator(task_id="auto_renew", python_callable=auto_renew)