Policy Administration Systems

New domain. No handbook prerequisite — this chapter is self-contained.

Your mid-term endorsement engine has a bug. A customer adds a driver to their auto policy, and the system recalculates the premium correctly — $47 more per month. But the billing schedule update fires before the endorsement commits. The next invoice reflects the new premium on the old coverage period. The customer disputes. Your agent cannot explain it. The state insurance department receives a complaint, and now you have 30 days to demonstrate that your rating engine, endorsement workflow, and billing system produce consistent results across every policy state transition. The policy administration system is the system of record. When it disagrees with itself, everything downstream — billing, claims, reinsurance, regulatory reporting — inherits the contradiction.

The Policy Lifecycle

Every insurance policy follows a state machine. The states are universal across lines of business; the transitions and the data they carry vary by product.

quote → bind → issue → endorse* → renew* → cancel/expire
                         ↑          ↑
                         └──────────┘

Each transition triggers downstream effects — premium calculations, billing schedule updates, commission adjustments, reinsurance notifications. A policy administration system (PAS) is the orchestrator that ensures these effects execute atomically with the state transition.

Transition	Trigger	Downstream effects
Quote → Bind	Customer accepts, agent binds	Premium locked, deposit invoice generated, underwriting file created
Bind → Issue	Underwriting approval	Policy number assigned, documents generated, reinsurance ceded
Issue → Endorse	Coverage change request	Premium recalculated, pro-rata adjustment, billing schedule updated
Issue/Endorse → Renew	Term expiration approaching	Re-rating, new term created, renewal offer generated
Any active → Cancel	Customer request or non-payment	Earned premium calculated, return premium issued, cancellation notice

The endorsement and renewal transitions can repeat. A commercial property policy might accumulate 15-20 endorsements per term — adding locations, adjusting limits, changing deductibles. Each endorsement creates a new version of the policy with a new effective date, and the premium must be correct for every version at every point in time.

Premium Calculation

Premium calculation is the most computationally dense operation in the PAS. A single auto policy quote evaluates 50-200 rating variables against a rate table that can contain 10,000+ factor combinations.

The rating engine applies factors multiplicatively:

base_rate = territory_rate(zip_code, vehicle_class)
premium = base_rate
        × driver_factor(age, experience, violations)
        × vehicle_factor(make, model, year, safety_features)
        × coverage_factor(limits, deductible)
        × discount_factor(multi_policy, good_student, ...)
        × tier_factor(credit_score_band)

Each factor is a lookup into a filed rate table. “Filed” means approved by the state insurance department — you cannot change these factors without filing an amendment and receiving approval. The rate tables are versioned. A policy issued on March 1 uses the rate table effective on March 1, even if a new table was filed on March 15. This is rate table point-in-time correctness, and getting it wrong produces regulatory violations.

Rate tables are legal documents. Applying the wrong version of a rate table to a policy — even by one day — constitutes a rating error that the state can fine you for. Every premium calculation must reference the rate table version effective on the policy’s rating date.

For endorsements, the premium engine calculates the difference between the old and new coverage configurations, pro-rated to the remaining term. A mid-term endorsement on a 12-month policy with 6 months remaining applies 50% of the annual premium difference. The pro-rata calculation must account for short-rate cancellation tables, minimum earned premium rules, and state-specific pro-rata requirements.

Commercial lines are harder. A commercial package policy bundles general liability, property, auto, umbrella, and workers’ compensation. Each line has its own rating algorithm, its own rate tables, and its own regulatory filing requirements. The PAS must rate each line independently, apply package discounts across lines, and produce a single premium that equals the sum of the parts.

Billing Schedules

A policy’s billing schedule is a projection of future invoices derived from the premium, the payment plan, and any adjustments from endorsements. A $2,400 annual premium on a monthly payment plan generates 12 invoices of $200. An endorsement that adds $120 in annual premium mid-term does not simply add $10 to each remaining invoice — it adds a pro-rated adjustment to the next invoice and redistributes the remaining balance across the remaining installments.

Event	Billing impact
New business	Generate full installment schedule
Mid-term endorsement (increase)	Pro-rated charge on next invoice, redistribute remainder
Mid-term endorsement (decrease)	Credit applied to next invoice or refund
Renewal	New schedule generated from renewed premium
Cancellation	Earned premium calculated, return premium refund or final bill
Payment received	Apply to oldest outstanding invoice, recalculate past-due status

The billing engine must handle partial payments, overpayments, payment reversals (NSF checks), and grace periods. Each state has specific requirements for cancellation notice timing — typically 10 days for non-payment, 30-60 days for underwriting cancellation. The billing system enforces these timelines. If a payment is 11 days late in a state with a 10-day grace period, the system initiates cancellation notice generation. If payment arrives during the notice period, the system must reinstate and reverse the pending cancellation.

Payment plan fees add complexity. An insurer offering monthly billing charges a $5-10 installment fee per payment. These fees are not premium — they are service charges with different accounting treatment, different tax implications, and different regulatory disclosure requirements.

Commission Tracking

Every policy generates commission payments to the producing agent, the managing general agent (MGA), and potentially multiple intermediaries. Commission structures are contractual — defined per agent, per product, per line of business — and they change on endorsements and cancellations.

{
  "agent_id": "AG-4521",
  "commission_schedule": {
    "new_business": { "personal_auto": 0.15, "homeowners": 0.12 },
    "renewal": { "personal_auto": 0.12, "homeowners": 0.10 },
    "endorsement": "pro_rata_of_applicable_rate"
  }
}

New business commission rates are higher than renewal rates — 15% vs 12% is typical for personal lines. The PAS must track which term a policy is in and apply the correct rate. On endorsements, commission is calculated on the premium change, not the full premium. On cancellations, previously paid commission is clawed back proportionally to the unearned premium.

Commission statements are generated monthly. The agent receives a statement showing each policy transaction, the premium, the commission rate, and the commission amount. The total must reconcile with the payment. Discrepancies between the PAS commission calculation and the agent’s expectation are the most common source of agent complaints and E&O (errors and omissions) disputes.

Reinsurance Integration

Reinsurance treaties define how risk is shared between the primary insurer (the cedant) and one or more reinsurers. The PAS must track cession at the policy level.

Proportional treaties (quota share, surplus share) cede a fixed percentage of every policy. A 30% quota share treaty means 30% of every premium dollar and 30% of every claim dollar flows to the reinsurer. The PAS tags each policy with its treaty allocation at issuance.

Non-proportional treaties (excess of loss, catastrophe) activate based on loss thresholds. These don’t require policy-level tracking but do require the PAS to report bordereau — detailed policy-level data — to reinsurers monthly or quarterly.

Treaty type	PAS requirement	Data flow
Quota share	Tag each policy with cession percentage	Premium and loss bordereau monthly
Surplus share	Calculate cession based on policy limit vs retention	Policy-level cession reports
Excess of loss	No policy-level tagging	Aggregate loss reporting
Facultative	Individual policy placement	Per-policy certificate tracking

Bordereau files follow ACORD standards — structured CSV or XML with standardized field definitions. ACORD AL3 (Agency/Company interface) defines 400+ transaction types. ACORD XML defines the data model for policy, claim, and accounting transactions. Your PAS must produce compliant bordereau, or your reinsurance relationships require manual reconciliation.

Reinsurance accounting operates on a different calendar than policy accounting. Treaties renew annually (often January 1), while policies renew on their anniversary dates. The PAS must allocate premiums and losses to the correct treaty year, which may differ from the policy year.

The Legacy Problem

The insurance PAS market is dominated by platforms built in the 1990s and 2000s. Guidewire PolicyCenter (Java, on-premise or cloud) and Duck Creek Policy (originally .NET, now cloud-native) together serve a significant share of the US P&C market. Both carry architectural decisions from an era when batch processing was the norm and real-time API access was not a requirement.

Platform	Architecture	Deployment	Typical implementation timeline
Guidewire PolicyCenter	Java monolith, Gosu scripting	On-premise or Guidewire Cloud	18-36 months
Duck Creek Policy	.NET, configurable rules engine	SaaS (AWS)	12-24 months
Majesco Policy	Cloud-native, microservices	SaaS	12-18 months
Socotra	API-first, JSON configuration	SaaS	3-6 months
Custom-built	Varies	Varies	6-18 months

Implementation timelines correlate with configuration complexity, not code quality. Guidewire’s 18-36 month timeline reflects the depth of product configuration — rate tables, forms, workflows, document templates, regulatory rules for 50 states — not the difficulty of deploying the platform itself.

Modern insurtechs (Lemonade, Root, Hippo) typically build custom PAS platforms optimized for a single product line. A custom PAS for renters insurance is orders of magnitude simpler than a general-purpose PAS that handles commercial package policies across all 50 states. The build-vs-buy decision hinges on product complexity and line-of-business scope.

Modernization Patterns

Legacy PAS modernization follows three patterns, each with a different risk profile.

Strangler fig. Route new products to a modern system while existing products remain on the legacy platform. The two systems run in parallel, connected by a synchronization layer. New business on new products flows through the modern system; renewals and endorsements on legacy policies stay on the old system. The risk is the synchronization layer — if agent data, billing, or claims must span both systems, the integration cost dominates.

Headless PAS. Keep the legacy system as the system of record but replace the user interface and API layer. Agents and customers interact with modern frontends; the legacy system processes transactions. This preserves the regulatory compliance embedded in the legacy rating and forms engines while modernizing the user experience. The risk is that the legacy system’s batch-oriented architecture creates latency that the modern frontend cannot hide.

Lift and replatform. Migrate the entire book of business to a new platform. Every in-force policy is converted — coverage, billing schedule, claims history, document archive. Conversion errors on a book of 500,000 policies at a 0.1% error rate produce 500 policies with incorrect data. Each error requires manual review. The risk is conversion accuracy, and the cost of finding errors after migration is 10-100x the cost of preventing them.

Policy conversion is not data migration. A policy is a legal contract with state-specific terms, endorsed modifications, and billing commitments. Converting a policy means reproducing its exact legal state in the target system — not just copying fields. Every converted policy must be validated against its source to confirm that coverage terms, premium, billing balance, and claim reserves match exactly.

ACORD Data Standards

ACORD (Association for Cooperative Operations Research and Development) defines the data standards that insurance systems use to communicate. Three standards matter for PAS integration.

ACORD AL3 — the legacy standard. Fixed-width records with transaction codes (e.g., code 01 = new business, code 05 = endorsement). Still used for agency-company data exchange. Parsing requires transaction-code-specific field maps.

ACORD XML — the modern standard. Structured XML schemas for policy, claim, billing, and reinsurance data. The PersPolicy schema alone has 200+ elements. Namespaced, versioned, and validated against XSD.

ACORD Forms — standardized insurance forms (applications, declarations pages, endorsement forms). Form numbers like ACORD 25 (Certificate of Insurance) and ACORD 125 (Commercial Insurance Application) are industry-universal. Your PAS must generate these forms with data populated from the policy record.

ACORD compliance is not optional for carriers that work with independent agents. The agency management systems (Applied Epic, Vertafore AMS360) that agents use expect ACORD-formatted data. If your PAS cannot produce ACORD downloads, your agents must re-key every transaction — a non-starter for any carrier with an independent agency distribution channel.