A product manager wants windscreen cover added to a motor product, with its own limit, excess and rating factor. On many older cores that request becomes a change ticket, a slot in the next release and a round of regression testing, while someone checks that policies already in force will not be re-rated by mistake. The policy administration system (PAS) decides how long that takes, so it sets the pace for every product an insurer launches. In 2026 the test for a PAS is whether the business can make that change itself, with AI drafting it and a person approving it, on a record that keeps every version.

What is a policy administration system?

A policy administration system is the system of record for every policy an insurer, MGA or delegated-authority broker writes. Celent's definition starts there: the PAS holds the policy-level data (coverages, limits, benefits, riders, terms) and keeps the complete history of each policy from issue to cancellation or reinstatement (Celent, February 2026, in a reprint published by Majesco).

In practice the PAS does more than store records. It runs the policy lifecycle: quote, bind, issue, mid-term endorsements, renewal, cancellation and reinstatement. Around that lifecycle are the modules that read and write the same record: rating, underwriting rules, billing, claims, document generation and, under delegated authority, bordereaux reporting to the capacity provider.

A policy administration system runs the policy lifecycle, quote, bind, issue, endorse, renew and cancel, on one policy record that keeps versioned products, the full history and an audit trail. Rating, underwriting, billing, claims, document generation and bordereaux reporting read and write the same record.THE POLICY LIFECYCLEQuoteBindIssueEndorseRenewCancelOne policy record: versioned products, full history, audit trailRatingUnderwritingBillingClaimsDocumentsBordereauxMODULES THAT READ AND WRITE THE SAME RECORD
Every lifecycle step writes to one policy record, and the modules around the PAS read the same record instead of keeping copies.

Policy administration system vs core insurance system

The terms overlap. A core system usually means the PAS plus billing and claims sold as one suite; some insurers buy the three separately and connect them. Our guide to insurance core systems compares the main suites. Either way, what matters is the shared record: when billing and claims read the same policy version the PAS issued, nobody re-keys data between systems, and a regulator's question about what the cover was on a given date has one answer.

Who works in a PAS

Underwriters quote and refer risks in it, operations staff process endorsements and renewals, finance reconciles premium against it, and claims handlers check cover before they pay. Brokers with delegated authority use the same functions to issue, endorse and renew on behalf of a carrier. Brokers without it mostly need client, placement and commission tools instead, which our comparison of insurance broker management systems covers.

Where older policy administration systems hold insurers back

Many policies still run on cores built decades ago. McKinsey describes such a core as several decades of sparsely documented business rules, batch windows, custom interfaces and data semantics, and names underdocumented product logic and actuarial settings as a common reason PAS migrations slip (McKinsey, April 2026). For the business the symptoms are familiar: a rate change waits for a release, a report needs an export and an analyst, and few people can say which rules apply to which product. We cover the options for living with, or leaving, such systems in our article on legacy software systems.

Use of AI in policy administration in 2026

A few years ago, AI in policy administration mostly meant personalised customer emails. In 2026 it reaches the configuration and the data: AI drafts product changes, answers questions about the book, reads submission documents and briefs underwriters on referred cases. The risk grows with it. An AI that writes to a rating table or a policy record can do damage a clumsy email cannot, so the question to ask about any AI feature in a PAS is what it may change and who signs off.

The examples below come from Openkoda, the PAS built by our sister company, because these are the features we configure for clients.

AI Product Builder: product changes in plain English

In the AI Product Builder, a product manager or underwriter describes a product or a change in plain English, such as “add windscreen cover to Motor and re-rate it”. The AI turns that into a typed change-set: a new coverage, its limit and excess, a rating factor and an underwriting referral rule, each line drawn from a fixed catalogue of operations rather than written as code. The user reviews a before-and-after view, approves the whole set or adjusts it and asks for a new draft, and only then is the change applied.

The scope goes beyond rates: coverages, deductibles and limits, rating factor rows and formulas, underwriting rules (auto-approve, refer, decline), the product structure, workflow steps, extensions, exclusions and endorsement templates. When a structural change hits a product that already has issued policies, the platform clones a new product version, so the policies in force stay on the version they were bound under.

The AI Product Builder tab of a motor product in Openkoda: a box to describe a change in plain English, and a list of what can be changed, from product settings, coverages and risk items to rating, underwriting, the application form and the workflow
The AI Product Builder in Openkoda: the change is described in plain English, nothing is applied until someone approves it, and every applied change is recorded in the audit trail.

Reporting AI: questions about the book without a query language

Reporting AI answers a question such as “loss ratio by product, this quarter” with a report, and shows the query it ran next to the result, so anyone can check how a number was produced. The answer can be pinned to a dashboard, and each role (executives, underwriting, sales, billing, operations) gets its own. Every query is scoped to the insurer's own data at the data layer, which is what makes it safe to open reporting to the whole business instead of a few analysts. Because policy, underwriting, claims and billing run on one platform, one question can span the whole lifecycle without stitching exports together.

Other AI features in the platform

  • Document reading: details extracted from PDFs, emails and images pre-fill a submission or a case, and a person confirms them before they are used.
  • Underwriting copilot: on a referred case, risk signals, pricing context and suggested next steps appear in the underwriter's workbench.
  • AI steps in workflows: a configured workflow calls AI to summarise a claim, classify a document or draft a customer email.
  • Explain this: a plain-language explanation of a report or of a change in a KPI, for readers who are not analysts.
  • An MCP server: an assistant such as Claude connects to the live book over the Model Context Protocol and works under the connected user's own permissions; anything that changes data is shown as a preview and goes ahead only when the user confirms it.

Openkoda AI is a separate monthly subscription on top of the platform licence, with a credit allowance spent per action: a report query, a document read, a product change.

Guardrails: typed change-sets, human approval and an audit trail

Four controls decide whether AI can be trusted near a policy record. Ask any PAS vendor how its AI handles each of them.

  • Typed changes only. The AI proposes operations from a fixed catalogue, never free-form code, so it cannot produce a change the platform would not accept.
  • A person approves. Nothing is applied until someone with the right role accepts the before-and-after; for underwriting and claims decisions that affect people, a qualified person signs off.
  • Versions, not overwrites. A product moves from Draft to Current to Superseded, new business rates on Current, policies in force keep the version they were bound under, and a prior version can be restored.
  • Every call audited. Each request and result is logged, attributed and timestamped, and each query runs inside the insurer's own tenant.
How AI changes a product in a policy administration system with guardrails. A user describes a product change in plain English; the AI drafts a typed change-set from a fixed catalogue of operations, with no code; a person reviews the before and after and approves it, or it goes back to be adjusted and re-drafted; the approved change is applied as a new product version and recorded in the audit trail. Product versions move from Draft to Current to Superseded: new business rates on the Current version, and policies in force keep the version they were bound under.AI DRAFTS, A PERSON APPROVESDescribea product changein plain EnglishAI draftsa typed change-setfrom a fixedcatalogue, no codeHuman approvalof the changebefore and afterAppliedversioned andrecorded in theaudit trailNot approved: adjust and re-draftPRODUCT VERSIONSDraftCurrentSupersededNew business rates on Current; policies in force keep the version they were bound under.
The AI drafts and a person approves; an approved change becomes a new product version, and policies in force stay on the version they were bound under.

The same controls are what supervisors increasingly expect. McKinsey's April 2026 paper on agentic AI in core modernization calls for “human-in-the-loop approvals at stage gates” and for traceability from requirements to configuration to test evidence. In the EU, the AI Act classes AI used for risk assessment and pricing of individuals in life and health insurance as high-risk (Annex III), with the high-risk obligations applying from December 2027. A record of what the AI proposed and who approved it is the evidence those rules ask for. Where AI goes into a regulated path, our AI integration work starts from the same audit requirements.

Must-have features in PAS software in 2026

Every PAS vendor lists quote, bind and renew, so feature lists look alike. The differences that show up after go-live are who can change a product, how the AI is controlled, and whether you can leave with your data. The graphic groups the must-haves by layer; the sections below say what to check in a demo.

Must-have features of a policy administration system in 2026, by layer. Channels: client portals, apis and webhooks, ai assistant access. Products: configured products, rating and rules, versioning. Policy servicing: quote, bind, issue, endorsements, renewals. Operations: billing, claims, bordereaux. Insight: dashboards by role, plain-english reports, document reading. Control: full audit trail, role-based access, managed or on premise. AI assistant access, plain-English reports and document reading are AI-assisted, with a person confirming the result.MUST-HAVE PAS FEATURES IN 2026ChannelsClient portalsAPIs and webhooksAI assistant accessProductsConfigured productsRating and rulesVersioningPolicy servicingQuote, bind, issueEndorsementsRenewalsOperationsBillingClaimsBordereauxInsightDashboards by rolePlain-English reportsDocument readingControlFull audit trailRole-based accessManaged or on premiseAI-assisted, with a person confirming the resultCore feature
Must-have PAS features in 2026, from channels to control; the outlined ones use AI, with a person confirming the result.

Products the business can change

Coverages, limits, deductibles, rating tables and formulas, and underwriting rules (auto-approve, refer, decline) should be configuration, not a schema project or a code release. Ask the vendor to make a change live in the demo: add a coverage, change a rating factor, add a referral rule. Then ask what happens to the policies already in force. The answer you want is versioned products: the whole configuration (structure, rating, underwriting, forms, workflow) versioned together, policies staying on the version they were bound under, and a way back to the previous version.

Where a system needs a proprietary programming language for these changes, every product change needs a specialist, and that cost comes back in every year of the contract.

The full policy lifecycle on one record

Quote, bind, issue, endorse, renew, cancel and reinstate in one system, with each transaction triggering the next step: documents produced, invoices raised, tasks assigned, partners notified. A mid-term endorsement should re-rate only the change and calculate the pro-rata premium. Renewal offers should be generated and followed up on a schedule, with staff stepping in only where judgement is needed. A 360-degree view, with policy, customer, claim and billing on linked screens, lets a customer question be answered on the first call.

Billing, claims and delegated authority

Billing (invoices, payment plans, dunning) and claims (intake, reserves, approvals, payments) should read the policy version the PAS issued. MGAs and coverholders also need premium and claims bordereaux in the format the capacity provider expects, produced from the data rather than assembled in spreadsheets every month. Our guide to insurance claims management software covers the claims side in more depth.

Integration, reporting and your exit route

A REST API, webhooks and a documented data model (ACORD is the common reference) connect the PAS to rating engines, payment providers, CRM, accounting, reinsurance and distribution partners. Policy data should be reportable the moment it is written, through dashboards per role and, in 2026, questions asked in plain English. Finally, check that your products, configuration and data export in a usable form: that export is your exit route if the vendor relationship ends.

Security, compliance and deployment

A PAS holds personal and financial data, so it inherits the privacy rules of every market you write in: GDPR in the EU and the UK, the CCPA in California, PIPEDA in Canada, the GLBA for US financial institutions, HIPAA where health data is involved, and PCI DSS wherever card payments are taken. EU insurers have also been subject to DORA since January 2025, which makes ICT risk management, incident reporting and oversight of critical technology providers a legal duty. In the PAS that means role-based access, encryption, strict data isolation between brands or tenants, and a full audit trail of every action, attributed and timestamped.

Deployment is the last check. A managed cloud service removes the infrastructure work and the upgrades; an on-premise installation keeps data in your own environment and region, and puts the upgrade cadence in your hands. Insurers with strict data-residency rules often need the second option, so ask whether the vendor offers it.

Launching your own platform on top of a customizable PAS

Insurers and MGAs that want a platform of their own, with their products, brands and portals, used to choose between a packaged suite and a custom build. A packaged suite brings years of insurance logic but changes through the vendor's tools and timelines. A custom build fits exactly, but spends its first months rediscovering what a policy is, how endorsements attach and how versions work. A customizable PAS is the middle path: the insurance logic comes ready, and the parts that make the business different are configured or built on top. We also describe the custom route in how to build insurance policy management software.

What Openkoda is

Openkoda is an insurance policy administration system that insurers configure with AI, from quote to claim: rating, underwriting, policy administration, claims, billing, workflow automation, document generation and bordereaux reporting for delegated authority. It is built and licensed by our sister company of the same name, and Stratoflow is the implementation partner. It runs fully managed on Openkoda Managed Cloud or on premise in the insurer's own environment, under a subscription licence; the products, configuration and data remain the insurer's and export at any time.

The data model is ACORD-aligned; the platform is multi-tenant, multi-brand and multi-currency, with role-based access and a full audit trail; and every form has a submission API alongside the REST API and webhooks. Products are versioned (Draft, Current, Superseded), so a policy stays on the version it was bound under. The demo below walks through Policy 360, the platform's view of a single policy.

Openkoda PAS demo: Policy 360, one policy record with its customer, claim and billing context.

How the platform is customized

Customization works in three layers. Products, rates, underwriting rules, workflows, forms, documents, dashboards, roles and navigation are configuration, changed by business users, often through the AI Product Builder. Portals and branding are configured per organization, so one deployment can run several brands. Anything configuration does not cover, such as a specialised rating model, an unusual claims process or an integration with a finance or partner system, is built as an extension in Java and Spring and runs inside the same versioned, audited platform.

Stratoflow as the implementation partner

Our part is the work around the platform: configuring products, rates and rules with the client's team; integrating accounting, payment, reinsurance, document and distribution systems; migrating policies and history with their versions intact; building custom modules in Java and Spring; and hosting and supporting the result. The first five professional-services days of configuration analysis come with every Openkoda plan, and openkoda.com puts implementations at weeks to a few months, depending on scope.

Core Travel Insurance went from contract to a live platform in eight weeks in 2026, migrating its existing clients along the way. SkyGuard, a life and aviation specialty insurer, runs its policy administration on the same platform, each line with its own workflows and underwriting.

We required a smooth migration of our existing clients along the way. We’ve gone from implementation to production in only eight weeks.

Fiona Lally, Chief Executive Officer, Core Travel Insurance
Case study: Stratoflow implementations of the Openkoda insurance policy administration system. Products and rates are configured with AI on the platform, which covers quote to claim, and custom modules in Java and Spring extend it. Core Travel Insurance went from contract to production in eight weeks in 2026, and SkyGuard runs life and aviation policy administration on the same platform.CASE STUDY: INSURANCEOpenkoda: Core Travel and SkyGuardCore Travel Insurance went from contract to alive policy platform in eight weeks; SkyGuardruns life and aviation cover on the platform too.8 weekscontract to production2 insurerslive on the platformProducts and ratesconfigured with AIOpenkoda PASquote to claimCustom modulesJava and SpringconfigureextendRead the case study

When Openkoda is the wrong fit

A large multi-line carrier that has recently finished a suite implementation, with a team trained on it, will usually get more from extending that suite than from moving again. Most of our insurance software work is implementation and integration on whatever core an insurer already runs, and we say early on when a platform change is not worth it.

Stats and insights: overview of insurance technology (insurtech) in 2026

Premium growth is slowing in 2026

Swiss Re Institute expects global insurance premiums to grow 1.3% in real terms in 2026, down from 3.9% in 2025. Non-life slows to 0.6% as pricing softens, while life holds at 2.3% (Swiss Re Institute, sigma, July 2026). In a soft market, growth depends less on rate and more on new products and a lower cost per policy, both of which run through the PAS.

Technology spending has not lowered insurers' costs

McKinsey estimates gross written premiums at about $8.3 trillion in 2025, after growing roughly 4.9% a year since 2005, while profits before tax grew about 4.3% a year to around $580 billion. Technology did raise labour productivity, by 14% in P&C and 24% in life across claims, servicing and policy issuance, but McKinsey finds those gains were offset by rising IT costs, compliance overhead and the complexity of layering digital tools onto legacy operating models (McKinsey, July 2026).

Insurtech funding is back, and concentrated

CB Insights counts $2.4 billion of insurtech funding across 107 deals in the second quarter of 2026, the highest quarterly total since the third quarter of 2022 and up from $1.6 billion in the first quarter (Q1 report). Eight mega-rounds, raised by six companies, account for $1.7 billion of it (CB Insights, State of Insurtech Q2 2026). Investors are writing bigger checks to fewer companies.

AI and the cost of moving to a new PAS

The software is rarely the expensive part of a PAS migration. McKinsey finds that in most insurance migrations, rewriting code or configuring the target platform is a small portion of the work; the time goes on understanding the rules, converting data, quality control, reconciliation and stabilising after cutover. From its own project experience, it puts the typical productivity gain from agentic AI at 10% to 90% depending on the step (McKinsey, April 2026). The widest range is in testing and reconciliation, the most repetitive and checkable work.

McKinsey's typical productivity improvement from agentic AI in each step of an insurance core system modernization, from its own experience (April 2026): discovery of legacy rules 20 to 50%, configuring the new platform 15 to 40%, data mapping and conversion 20 to 60%, testing and reconciliation 15 to 90%, cutover and hypercare 10 to 40%, programme management 25 to 50%.TYPICAL PRODUCTIVITY GAIN FROM AGENTIC AI0%25%50%75%100%Discovery of legacy rules20 to 50%Configuring the new platform15 to 40%Data mapping and conversion20 to 60%Testing and reconciliation15 to 90%Cutover and hypercare10 to 40%Programme management25 to 50%
Typical productivity improvement from agentic AI per step of an insurance core modernization, as ranges from McKinsey's own project experience (April 2026).

A crowded PAS vendor market

Celent's 2026 reports profile 33 policy administration system vendors for life insurance in EMEA (reprint published by Sapiens) and 21 systems for group and voluntary life insurance in North America alone (reprint published by Majesco). With that many options on paper, the shortlist comes down to the checks in the must-have list above.

Policy administration system FAQ

What is a policy administration system in insurance?

It is the software that holds every policy an insurer writes and runs its lifecycle: quoting, binding, issuing, mid-term changes, renewals, cancellations and reinstatements. Rating, underwriting rules, billing, claims and documents either run inside the PAS or read its policy record.

Which systems integrate with a policy administration system?

Typically claims management, billing and payment providers, accounting and the general ledger, reinsurance, CRM, document and e-signature services, external rating engines and data enrichment, and the portals and APIs that brokers and partners use. Integrating them with the PAS removes double entry and gives reporting one set of numbers.

How long does a PAS implementation take?

It depends on the number of products, the integrations and how much policy history has to migrate. For Openkoda, openkoda.com gives weeks to a few months, depending on scope; Core Travel Insurance went from contract to production in eight weeks.

Does AI in a PAS make decisions on its own?

It should not. In Openkoda the AI drafts typed changes and a person approves them; document reading pre-fills data that a person confirms; and assistant actions that change data need explicit confirmation. Every request and result goes into the audit trail.

How do we start a PAS project with Stratoflow?

With a thirty-minute scoping call about your products, your current systems and your timeline. Afterwards we send a written ballpark: what the platform covers, which integrations and custom modules you need, and what the work costs.