Pillar guide · Insurance technology

Policy Administration System (PAS) for Insurance: complete CIO guide

· 14 minute read · Audience: CIOs, IT managers, operations leadership
Summary

A Policy Administration System (PAS) is the core software system of an insurer or large intermediary: it manages the entire policy lifecycle, from initial rating to issuance, from in-life changes to claims, through to technical accounting. It is distinct from CRMs (focused on the customer relationship) and ERPs (focused on general accounting). This guide describes the anatomy of a modern PAS in 7 layers, the substantial differences with CRM and ERP, 12 vendor-selection criteria, 7 signals that a legacy PAS needs replacing, and a realistic 5-year TCO calculation.

1. What a PAS is (and isn't)

A Policy Administration System (PAS) is the software category that manages, end-to-end, the lifecycle of insurance products. It is the core system, the "system of record" of an insurer or large insurance intermediary: without a PAS, operations fragment across generalist software, Excel spreadsheets and manual workflows — with non-compliance costs that grow non-linearly as portfolio size increases.

The PAS covers, by market standard, seven macro-functions:

What a PAS is not

To avoid vendor-selection ambiguity, it helps to clarify the boundaries:

2. Anatomy of a modern PAS — the 7 functional layers

A modern PAS is articulated in seven interconnected functional layers. Understanding them helps assess vendor coverage during selection.

2.1 Customer and product master data

The system's foundation: a single customer master (principals, insureds, beneficiaries) with duplicate control, address normalisation, integration with public registries (Italian Revenue Agency for VAT, IVASS for intermediaries listed in the RUI). The product catalogue defines line, type, tariff, covers, exclusions, allowed durations, renewal rules.

2.2 Rating and quotation

The rating engine applies IVASS-approved rules for premium calculation. It handles multiple parameters (principal master data, duration, sum insured, possible extensions), commercial discounts within authority limits, customer overrides with audit trail. Exposes REST APIs for real-time quoting consumable by customer portals, comparators, mobile-equipped agents, bancassurance partners.

2.3 Underwriting and approval workflow

The underwriting workflow applies decision-authority rules by user profile: the agent quotes up to limit X, above X the in-house underwriter, above Y the head of underwriting, above Z technical management. Each step is logged with mandatory motivation. For complex underwriting lines (specialty, marine, aviation, surety) the system integrates consultation workflow with reinsurer or Lloyd's syndicate leader.

2.4 Document issuance and electronic signature

Document generation is template-based: a parameterised template (cover page, general conditions, particular conditions, IPID, information booklet) integrates structured policy data. The PAS signs the document with FEQ (qualified electronic signature) using the issuer's qualified certificate, time-stamps via AgID TSA, sends for decade-long preservation to an accredited Preservation Provider. For tender-attached bonds, the PAS verifies the CIG against the ANAC BDNCP.

2.5 In-life policy management

A policy is not a point event but a contract that lives in time. The PAS handles: automatic or confirm-required renewals, endorsements (data or cover changes), progressive releases (for performance bonds against work progress), early cancellations with pro-rata refund calculation, suspensions for non-payment, reactivations. Each in-life event produces a signed and versioned endorsement document. History is queryable for IVASS audit.

2.6 End-to-end claims management

The claims module covers from notice (FNOL — First Notice of Loss) to closure: claim classification by type and severity, expert appointment, reserve calculation, possible integrations, settlement decision, payment via SEPA SCT, post-payment regress activation. For surety bonds, the workflow handles the difference between prior-execution and first-demand (see glossary). For claims-made professional liability, the workflow handles recognition of the retroactive and run-off.

2.7 Technical accounting, reinsurance, reporting

The PAS produces the insurer's technical accounting: written and earned premiums, paid and reserved claims, claims reserve (including IBNR), premium reserve, cessions to reinsurers, recoveries. Generates quarterly bordereaux for reinsurers and Lloyd's, periodic IVASS reporting, output for the actuarial system. Integrates with the ERP via monthly accounting interface for general accounting.

3. PAS vs CRM — substantial differences

The most frequent error in insurance digital-transformation projects is confusing PAS and CRM. They are complementary, not substitutable.

Operational rule

The CRM manages the relationship. The PAS manages the product. If the CRM disappears, the sales pipeline breaks but policies keep living. If the PAS disappears, the insurer stops functioning in two weeks.

When the CRM isn't enough

A generalist CRM doesn't natively manage concepts like sum insured, cover, retroactive, IVASS line, approved tariff, claim reserve, facultative cession, premium BDX, decade-long CAD preservation. Trying to force a CRM to act as PAS produces endless custom developments and fragile architectures.

When they coexist

The typical configuration has CRM and PAS coexisting with bidirectional API integration: the CRM handles leads, commercial activities, communications; when the lead becomes a principal, its master data is synced to the PAS, where the policy is born. Policy life events (upcoming renewal, open claim) are notified to the CRM for engagement activities. The clear separation of concerns simplifies governance, user training, and both systems' evolution.

4. PAS vs ERP — boundaries and overlaps

The ERP manages general accounting, human resources, fixed assets, purchasing, payables. The PAS manages technical insurance accounting, which is a sub-discipline with its own rules.

General vs technical accounting

General accounting, handled by the ERP, covers chart of accounts, journal entries, statutory balance sheet, tax, VAT. Technical accounting, handled by the PAS, covers specific concepts: written vs earned premiums, premium and claims reserves, reinsurance cessions and acceptances, post-payment recoveries, SEPA reconciliation for premium collections. Technical accounting is summarised and transferred to the ERP to produce the final balance sheet.

Customer master data: one or two?

The most frequent data-governance question. Recommended approach: a single customer master in the PAS, with synchronisation toward CRM and ERP for their respective needs. The PAS is the "system of record" for insurance master data (principals, beneficiaries, damaged parties), because it also contains the insurance-natured information (policy history, claims, exposure) that ERP and CRM have no reason to duplicate.

5. PAS vs generalist software

"Generalist software" indicates administrative and accounting software not specialised for insurance (e.g. Italian accounting packages popular among micro-enterprises). They can manage invoices, journals, customer/supplier accounting, but have no notion of policy, line, IVASS tariff, claim. They are adequate for small intermediaries (sub-brokers, single-mandate agencies with a few hundred contracts), but fail when the portfolio grows or heavily regulated lines come into play.

The typical threshold above which generalist software no longer suffices appears in these scenarios:

6. Vertical vs generalist PAS — the surety case

PASs on the market split into two strategic families.

Generalist PAS cover all main lines (motor, home, accident, life) with good configurability. Suitable for mid-to-large multi-line insurers, where a single line's volume doesn't justify a dedicated system. Pattern example: a large insurance group with a unified PAS handling 5-15 different lines.

Vertical PAS specialise on one or two lines, where the line's technical specificity requires native domain logic. The paradigmatic case is the surety line: the ANAC CIG workflow, L210 templates, AGEA policies, joint-venture management with shares, post-call regress, mapping to Lloyd's Risk Code for Italian coverholders. All this domain is impossible to configure satisfactorily on a generalist PAS — it requires custom developments that defeat the packaged-product advantage.

Practical rule: the more a line has regulatory or operational specificity, the more a vertical PAS makes sense. NewPicass 14.Net falls into this category — its historical domain is surety, where 9+ European insurers use it in production, some for more than a decade.

7. Legacy on-premise PAS vs cloud SaaS

The transition from legacy on-premise PAS to cloud SaaS is the most relevant digital-transformation theme in the Italian insurance back-office for 2026.

7 signals that the legacy PAS needs replacing

  1. Vendor end-of-life: the vendor announces that the current version will no longer be supported, or the product enters maintenance mode.
  2. Difficulty integrating with modern APIs: new standards (ANAC BDNCP, Lloyd's Atlas, FatturaPA SDI, AgID) require REST/JSON integrations that the legacy PAS struggles to expose.
  3. Rigid tariffs: every pricing change requires coded modifications. Launching a new cover takes weeks of development.
  4. No mobile: the distribution-network app doesn't exist or is non-native mobile-web.
  5. Rising maintenance costs: maintenance contracts grow 7-10% per year, expert legacy developers are scarce.
  6. Doesn't pass DORA due diligence: the PAS doesn't expose security logs, doesn't have a tested disaster-recovery plan, doesn't have ISO 27001 audit.
  7. Obsolete user experience: the interface is old-style form-based, workflows require too many clicks, average time to issue a policy is a multiple of the market benchmark.

Migration risks and mitigations

Migration is a complex project. The three main risks are:

The most adopted operational strategy is the strangler pattern: the new PAS goes into production for new products and new renewals, while the legacy keeps managing the historical portfolio through natural run-off (2-5 years), then is decommissioned.

8. Built-in compliance — IVASS, IDD, DORA, Solvency II

A modern PAS doesn't manage compliance "separately": it embeds it in its operational workflows. The relevant frameworks for the Italian and European market are:

In vendor selection, the "built-in compliance" axis is today a de facto prerequisite: a PAS that doesn't document its coverage on these frameworks hardly passes formal due diligence.

9. Reference technical architecture

A modern enterprise PAS typically adopts a three-layer architecture plus a belt of external services:

The adapter belt wraps each external service (TSP for signature, AgID Preservation Provider, SEPA payment gateway, actuarial systems, bank integration) so that replacing an external provider doesn't require core changes. It is a pattern of contractual and evolutionary isolation.

For availability, the typical modern SaaS PAS architecture is multi-data-center active: two or more geographically separated data centers but within the European Economic Area (for EU data residency), in active-active or active-passive mode depending on line criticality. NewPicass 14.Net operates for instance on two EU data centers in Strasbourg and Roubaix.

10. Typical PAS ecosystem integrations

A PAS is not an isolated system: it lives in an ecosystem of external services. Typical integrations of an Italian insurance PAS include:

11. TCO — total cost of ownership over 5 years

Economic comparison between PASs must happen on 5-year TCO, not first-year licences. Main TCO items are:

The most common mistake is comparing only licences between vendors. An apparently cheap PAS requiring 200 person-days of customising to be usable on your use case costs more than an "expensive" PAS that works out-of-the-box. List price is the minor part of the economic truth.

12. Vendor selection — 12 criteria

Operational summary of criteria to use during RFP/RFI:

  1. Functional fit to current portfolio: native coverage of operated lines;
  2. Functional fit to future portfolio: roadmap for lines you want to enter in the next 3 years;
  3. Technical architecture: cloud-native, REST APIs, multi-tenant, documented scalability;
  4. Built-in compliance: IVASS, IDD, DORA, eIDAS, AgID preservation, ISO 27001;
  5. Data residency: EU data center, security certifications, DORA exit clause;
  6. Vendor maturity: years on market, referenced customers in your line, financial sustainability;
  7. Product quality: release cadence, bug management, contractual SLA, customer NPS;
  8. Integrability: documented APIs, available SDKs, real integration examples with CRM/ERP/banks;
  9. Professional services: implementation capability, migration experience, training, post-go-live support;
  10. 5-year TCO: licences + implementation + integration + evolutions + expected customising;
  11. Public roadmap: visibility on evolutions in the next 12-24 months;
  12. Exit strategy: contractual clauses for data extraction, termination, portability.

13. PAS categories on the market

A summary map of PAS categories available today on the Italian and European market. We deliberately avoid naming individual competitor vendors: assessment of specific products depends on your use case and should be conducted with formal assessment.

Category Pros Cons When it makes sense
Legacy on-premise PAS Mature user knowledge; full data sovereignty High costs; rigidity; DORA difficulty; skill scarcity Historical portfolio run-off
International generalist cloud PAS Wide multi-line coverage; robust roadmap; community Complex configurations; incomplete IT localisation Multinational groups, multi-line, large size
Italian vertical cloud PAS Native IT domain; local-language support; agility Roadmap dependent on single vendor; small community Surety, specialty insurers, mid-size intermediaries
NewPicass 14.Net (vertical surety) 9+ EU surety insurers in production; CIG/Lloyd's/BDX domain; 14 native modules Specialised on surety + related lines Surety insurers, Lloyd's coverholders, surety MGAs

14. Frequently asked questions

What does PAS mean in the insurance context?

PAS stands for Policy Administration System. It is the software category that manages the end-to-end lifecycle of insurance policies: from initial quotation to issuance, from in-life changes (renewals, endorsements, releases) to claims, through to technical accounting and reporting to supervisors and reinsurers. It is the core system of an insurer or large intermediary: without a PAS, operations fragment across generalist software, Excel spreadsheets and manual processes.

What's the fundamental difference between a PAS and a CRM?

The CRM (Customer Relationship Management) manages the relationship with the customer: leads, commercial pipeline, communications, sales activities. The PAS manages the insurance product in its lifecycle: rating, underwriting, issuance, changes, claims, reinsurance. A CRM doesn't know what a surety bond is, a run-off, a facultative cession. A PAS doesn't manage email marketing campaigns. They integrate via API but cover different dimensions of the insurance business.

Can an ERP like SAP or Oracle replace a PAS?

No. ERP manages cross-company processes (general accounting, HR, supply chain, asset management). The technical specificities of insurance — multi-line tariffs, actuarial reserves, reinsurance treaties, IVASS compliance, Lloyd's BDX — require domain logic that generalist ERPs don't have. PAS and ERP typically coexist: the PAS handles technical accounting (premiums, claims, reserves, cessions), the ERP handles general accounting (balance sheet, fixed assets, payroll). The two communicate through periodic accounting interfaces.

When does an insurer or intermediary actually need a PAS?

Typically when more than 5,000 contracts are managed, or when entering heavily regulated lines (surety bonds, healthcare PI, credit insurance, Lloyd's specialty). Below that, a CRM + Excel + accounting software mix can suffice, although operational risk increases. At the first serious IVASS inspection, the first Lloyd's coverholder audit, or the first significant claims spike on a specialty line, the absence of a PAS becomes a structural drag.

What are legacy PAS systems and why are they being replaced?

Legacy PAS are systems typically developed between 1995 and 2010, on-premise, based on now-dated technology (mainframes, AS/400, Visual Basic 6, old Delphi versions or Oracle Forms). Three structural problems: (1) difficulty integrating with modern APIs required by Lloyd's, ANAC, AgID; (2) rigidity in tariffs and workflows, requiring coded modifications for every product change; (3) rising maintenance costs because developers with skills on the platform are dwindling. Replacement typically happens when the original vendor announces end-of-life or when the company decides on a digital transformation programme.

Is a vertical PAS better than a generalist one?

Depends on the portfolio. For portfolios concentrated on a single line (e.g. surety only, or trade credit only), a vertical PAS that natively incorporates specific workflows (ANAC CIG, Lloyd's BDX, credit limits) outperforms a generalist PAS that requires configuration or custom development. For very wide multi-line portfolios (a generalist insurer doing motor + home + life + industrial), a generalist PAS with good product flexibility and solid technical governance can work better, avoiding the burden of managing multiple specialist PAS.

How long does a PAS migration project usually take?

For a mid-sized insurer (~100,000 policies, 50-100 users, one main line), a PAS migration project typically takes 9-18 months: 2-3 months of assessment and fit-gap, 4-8 months of implementation and configuration, 2-3 months of integrated testing and UAT, 1-3 months of parallel run and cutover. For larger insurers or multi-line operations, timeframes rise to 18-36 months. The most critical component is almost never technical: it is historical data migration (master data, pending claims, reserves), user training and change management.

What are the main criteria to choose a PAS?

Four families of criteria: (1) Functional fit to your portfolio lines (a PAS without a reinsurance module isn't right for a cedent on treaty); (2) Technical architecture (cloud-native, REST APIs, multi-tenant, scalability); (3) Built-in compliance (IVASS, IDD, DORA, eIDAS, AgID preservation); (4) Vendor sustainability (years in business, referenced customers in your line, public roadmap, contractually defined exit strategy per EU Reg. 2022/2554 DORA). Price matters but is rarely the deciding factor: 5-year TCO is dominated by cost-of-change, not licences.

Is a SaaS cloud PAS or on-premise better?

For mid-sized Italian insurers and intermediaries, SaaS is now the dominant choice for three reasons: (a) zero infrastructure-management costs, (b) continuous updates without heavy upgrade projects, (c) ISO 27001 certified data centers included in the offering. On-premise still makes sense only for very large insurers with specific data sovereignty constraints beyond GDPR/DORA requirements, or with existing investments in proprietary data centers. DORA compliance (arts. 28-44 on third-party risk) explicitly treats cloud as a legitimate option provided standard contractual conditions are met.

How do you calculate a PAS's TCO (Total Cost of Ownership)?

Realistic 5-year TCO includes: SaaS licences or software licences + maintenance (40-50% of total), initial implementation (15-25%), training and change management (5-10%), integration with existing peripheral systems CRM/ERP/banks (10-15%), evolutions required during the 5 years (10-15%), in-house dedicated team cost (variable). A common mistake is comparing only licences between vendors, ignoring customisation costs: a "cheap" PAS requiring 200 person-days of customising to be usable can cost more than an "expensive" PAS that works out-of-the-box for your use case.

Must a modern PAS be ISO 27001 certified?

Yes, in practice it is a de facto requirement. Italian insurers in vendor due diligence require ISO/IEC 27001:2023 certification from the supplier as an IT security prerequisite. Adding DORA-readiness (third-party register, incident reporting, resilience testing) and SOC 2 Type II (for Lloyd's coverholders) are natural evolutions. A PAS without ISO 27001 hardly passes today an insurer or Lloyd's managing agent due diligence.

Can a new PAS be integrated with existing legacy systems during transition?

Yes, and it is the dominant operational model in real projects. Complete big-bang migration is rare because too risky. More common is the strangler pattern strategy: the new PAS goes into production handling new products and new renewals, while the old system continues to manage the historical portfolio through natural run-off (2-5 years). The two systems integrate via API for shared master data, unified accounting and consolidated reporting. At the end of the run-off the old system is decommissioned.

Want to assess your current PAS?

A 45-minute session with one of our senior architects, no sales script, to frankly assess your current PAS: functional gaps, compliance coverage, evolution roadmap, DORA non-compliance risk, automation opportunities. Output: a synthetic 3-page document with priorities ordered by impact. Request the free assessment.