Integration Capabilities of Insurance Policy Administration Software: A 2026 Architecture Framework for Mid-Tier US Carriers

Why PAS integration is the architecture decision that shapes everything else

In my experience working with US carriers between $500M and $5B GWP, the integration capabilities policy administration software actually delivers - not the integration capabilities the vendor claims in the RFP - determine whether the platform supports productive operations five years after go-live or becomes the integration bottleneck the next modernization project has to solve. Daniel - the chief architect or Head of Enterprise Architecture in our buyer persona work - knows this. The integration architecture decision is the one that locks in or unlocks every other system in the carrier's landscape, and getting it wrong costs more than getting any other PAS decision wrong.

This is not a small technical detail. According to Deloitte's 2026 Global Insurance Outlook, the industry is bifurcating into tech-forward carriers that thrive and laggards that struggle under cost and compliance pressures, with success depending on improved data quality, ongoing modernization of legacy systems, and robust cybersecurity. The integration architecture is what makes data quality possible, what determines whether legacy modernization is gradual or catastrophic, and what shapes the security posture across every external connection the carrier maintains. The PAS that ships with strong integration capabilities is the carrier's gateway to the bifurcated future; the PAS that ships with weak integration capabilities anchors the carrier in the legacy half of the bifurcation.

I've spent over 20 years inside insurance core modernization - including a 20+ year partnership with Allianz, multi-line PAS work with Warta, an Aviva engagement, and a full Generali Group Poland migration completed in 14 months. Across more than 100 insurance projects, the carriers who treat integration capabilities policy administration software as a central RFP requirement - not a secondary one - are the carriers whose Daniel equivalents stay in their roles past go-live and into the second platform release. The carriers who treat integration as a vendor's marketing slide pay for that decision through 18–36 months of integration rework, change-cost premiums on every downstream system, and the kind of architectural debt that compounds quietly until the next CTO inherits it.

This article is for the chief architect, the CIO, the Head of Enterprise Architecture, and the technical evaluation team who need an integration-first PAS evaluation framework that holds up under technical due diligence. I'll walk through the integration landscape mid-tier US carriers actually face, the 8 integration patterns every PAS RFP should address, the API-first vs API-supplied distinction that surfaces real platform maturity, ACORD XML and AL3 implementation depth tiers, the decision framework for event-driven architecture, integration cost categories that don't show up in vendor pricing, and Daniel's PAS integration evaluation checklist. No vendor slogans. Just the architectural depth that determines whether your PAS investment supports growth for a decade or limits it from year one. For broader architectural context, see our Pillar overview on the policy administration system.

For the broader feature framework that includes integration as one dimension among twelve must-haves, see key features of policy administration insurance software. For the operations user impact of integration architecture, see user experience and interface design in policy administration software. For the financial side of the integration architecture decision, see the ROI of modernizing policy administration systems and cost savings with modern policy administration systems.

The integration landscape mid-tier US carriers actually face

Before walking the integration patterns, Daniel needs to map the actual integration landscape - the systems his carrier needs the PAS to connect with, the directionality of each integration, and the data volumes involved. The mid-tier US carrier integration landscape is structurally different from the tier-1 carrier landscape, and PAS vendors who optimize for tier-1 footprints often miss what mid-tier carriers actually need. McKinsey's research on P&C core modernization flags the same blind spot industry-wide: carriers weighing build, buy, or upgrade decisions consistently underweight integration complexity relative to core functionality, and that miscalibration is what turns a well-scoped modernization into a multi-year overrun.

The systems a mid-tier US carrier PAS typically integrates with

A representative mid-tier US carrier in the $500M–$5B GWP range typically connects the PAS to 12–18 systems. Internal: claims management system, billing and collections, document management, customer relationship management (CRM), business intelligence and analytics, the underwriting workbench, agent portal, and customer self-service portal. External: ACORD-based agent management systems and MGA partner systems, reinsurance partner systems, third-party data providers (credit bureaus, MVR data, industry loss data, telematics where applicable), payment processors, and state DOI regulatory reporting systems. Each integration has its own data volume profile, latency requirement, and failure mode that the integration architecture has to accommodate.

Why this list looks different at tier-1 carriers

Tier-1 carriers with $10B+ GWP and captive agent distribution have a structurally different integration landscape - heavier on internal proprietary systems, lighter on ACORD-based external integration with independent agents, with deeper integration into reinsurance partner systems sized for their book. Mid-tier US carriers in the independent agent distribution model carry a heavier ACORD footprint, more partner-facing integration points, and less proprietary internal infrastructure. The PAS that's optimized for tier-1 integration patterns often falls short on the mid-tier integration footprint, even when the vendor claims comparable capabilities.

Directionality and data volume by integration

Some integrations are write-heavy from PAS to downstream systems (billing, document management, regulatory reporting). Others are read-heavy from external sources into PAS (third-party data, reinsurance schedules, agent commission rates). Some are bidirectional with high update frequency (CRM, agent portal, customer portal). Daniel needs to map each integration on these two dimensions because the integration architecture that handles write-heavy outbound with batch tolerance is structurally different from the architecture that handles bidirectional real-time. Vendors who present a single "integration capability" answer without addressing directionality and volume are oversimplifying.

The change frequency dimension

Some integrations are stable for years (regulatory reporting formats, ACORD standard transactions). Others change frequently (third-party data provider APIs, partner CRM versions, payment processor interfaces). Daniel needs the PAS integration architecture to handle high-change-frequency integrations without forcing platform-level changes - which means abstraction layers, mapping configuration, and integration testing infrastructure that's separate from the core platform release cycle. Vendors who treat every integration change as a platform configuration project are not architecturally ready for the change frequency mid-tier carriers actually experience.

The Aviva integration architecture pattern

In our Aviva engagement, the integration architecture pattern was structured around clear separation between core PAS functions and integration adapters, with the adapters versioned and deployed independently of the core platform. That pattern - core stable, integrations evolving - is what allowed the carrier to absorb partner system changes without core platform impact. For a mid-tier US carrier facing 4–8 partner system updates per year on top of regular third-party data provider changes, this separation is structurally important. The integration architecture isn't a feature; it's the platform's tolerance for change.

The 8 integration patterns every PAS RFP should address

Below is the 8-pattern integration framework I walk every mid-tier US carrier through before they release the integration section of a PAS RFP. Each pattern has an RFP weight reflecting how much technical depth differentiates vendors on this dimension. Weights sum to 100. Vendors who can't demonstrate concrete capability on a pattern with a weight of 10 or higher don't make the technical shortlist.

Why pattern-based evaluation beats feature-list evaluation

The trap I see in most mid-tier RFP integration sections is treating integration as a single dimension - "yes/no on API support" - rather than as eight distinct architectural patterns each with its own capability profile. The result is vendor responses that all say "yes" to integration and the carrier has no basis for differentiating real architectural depth from marketing claims. A pattern-based framework forces the carrier to ask specific questions per pattern and evaluate vendor responses against concrete capability rather than checkbox compliance.

Summary table of the 8 integration patterns

Pattern 1: Synchronous REST API for real-time queries and commands

The default integration pattern. Every modern PAS exposes REST APIs for the most common operations - policy lookup, quote, bind, endorsement, billing query. The depth question is whether the API surface covers the carrier's actual integration scope. Ask the vendor for the OpenAPI 3.0 specification and count endpoints. A PAS that exposes 200+ documented endpoints supports rich integration; a PAS that exposes 30 generic endpoints forces every consumer to handle business logic the platform should be enforcing.

Pattern 2: Asynchronous event publishing

State changes in the PAS - policy issued, endorsement applied, premium calculated, document generated - should publish events that downstream systems can subscribe to. The integration pattern is variously called event streaming, event-driven architecture, or pub/sub depending on the technology stack. Section 6 of this article walks the decision framework for when this pattern matters vs when REST suffices. The brief version: any integration that needs near-real-time visibility into PAS state changes is structurally better served by events than by polling.

Pattern 3: ACORD XML and AL3 transaction support

Non-negotiable for US P&C carriers. Section 5 of this article is dedicated to the depth-of-implementation tiers for ACORD support, because this is where vendor responses oversell most consistently. The brief version: real ACORD support means native ingestion and production of ACORD XML transaction types and AL3 batch transaction types with documented mapping; partial support means ACORD-named fields with semantic loss; logo-only support means no real ACORD capability.

Pattern 4: Bulk data export and import

The integration pattern most underweighted in RFPs and most painful at go-live without it. Bulk data export is required for data migrations, partner-facing data feeds, and reconciliation processes. Bulk import is required for data migrations into the PAS and for periodic reference data updates (rate factors, regulatory tables, partner data). Mid-tier carriers without strong bulk support pay for the gap during data migration and again during every reconciliation cycle.

Pattern 5: Webhook-based notifications

A simpler form of asynchronous integration than full event streaming, widely used for partner-facing notifications. The PAS publishes a webhook to a partner endpoint when a relevant state change occurs. Lower throughput than streaming, simpler to implement on both sides, sufficient for partner-facing integration where real-time but not high-volume.

Pattern 6: File-based batch integration for legacy partner systems

The pattern that gets dismissed in modern integration discussions but is the reality of mid-tier carrier integration landscapes. ACORD AL3 batch files, regulatory reporting files, partner data feeds - many of these still flow through scheduled file-based integration. The PAS that handles file-based integration cleanly with scheduled triggers, retry logic, and exception monitoring saves the carrier from building this infrastructure separately. The PAS that doesn't forces the carrier to maintain a separate integration platform alongside the PAS.

Pattern 7: Streaming data integration for real-time analytics

Modern analytics and AI workflows increasingly consume PAS state changes through streaming data platforms. This is the integration pattern that's growing most quickly in importance, particularly for carriers building AI-driven claims triage, fraud detection, and underwriting decision support on top of PAS data. Datos Insights' 2025 research on the P/C PAS market describes AI moving from a supplementary feature to an essential, embedded component of modern policy administration platforms. Per McKinsey's 2025 analysis of agentic AI in insurance, autonomous and semi-autonomous software agents need real-time access to operational state changes to deliver value. Streaming integration is increasingly the architecture pattern that supports this.

Pattern 8: Identity and access integration

The integration pattern that determines whether the carrier delivers a unified user experience across PAS, agent portal, customer portal, and partner systems - or whether users juggle multiple credentials across multiple systems. Modern identity integration uses SAML 2.0 for enterprise single sign-on, OAuth 2.0 for API access authorization, and OpenID Connect for federated identity. The PAS that doesn't support these standards forces the carrier into custom identity integration that ages badly and creates security gaps.

API-first vs API-supplied - what really matters in production

API-first is one of the most overused terms in PAS marketing, and the gap between vendors who genuinely deliver API-first architecture and vendors who supply APIs as a layer on top of a non-API-first platform is one of the largest hidden risks in PAS evaluation.

What API-first actually means

API-first means every business operation in the platform is available through a documented API before it's available through the user interface - not the other way around. The API is the primary interface to the platform; the UI is one consumer of the API. The architectural implication: when the platform adds new capability, the API surface grows first, the UI consumes the new API, and integrating systems can use the new capability immediately without waiting for the vendor to expose it through a separate integration release.

What API-supplied means

API-supplied means the platform was built with the UI as the primary interface, with APIs added later as a separate layer that exposes a subset of platform capability. The platform's internal operations don't all have API equivalents. Adding a new capability requires the vendor to also build the API for it, often as a separate release cycle. The integration team frequently finds that operations available in the UI aren't available through the API, which forces workarounds.

The test that surfaces the difference

Ask the vendor for the OpenAPI 3.0 specification. If it doesn't exist or is partial, the platform isn't API-first. Then ask: "Show us a recent platform feature release. Was the API for the new capability available before the UI shipped, simultaneously, or after the UI shipped?" The answer reveals the platform's architecture posture. API-first platforms ship the API first or simultaneously; API-supplied platforms ship the API later.

Why this matters more for mid-tier carriers

Tier-1 carriers can absorb the integration cost of working with API-supplied platforms because they have the engineering depth to build wrappers, workarounds, and custom integration. Mid-tier US carriers in the $500M–$5B GWP range typically don't have the platform engineering team to absorb that cost. The PAS that ships API-first delivers usable integration out of the box; the PAS that ships API-supplied forces mid-tier carriers to build the integration infrastructure they assumed the platform would deliver.

The OpenAPI 3.0 maturity check

Beyond the existence of the OpenAPI spec, Daniel should evaluate maturity. Does the spec include all endpoints or only a subset? Are request and response schemas fully defined or do they reference generic types? Are error responses documented with specific error codes and meanings? Are authentication patterns documented? The maturity of the OpenAPI spec is a leading indicator of the maturity of the API-first architecture behind it. Generic, sparse OpenAPI specs are a finding worth weighting in the technical evaluation.

Versioning and deprecation policy

API-first platforms have explicit versioning and deprecation policies - when an API contract changes, the old version remains available for a defined period while consumers migrate. API-supplied platforms often handle versioning ad-hoc, which means consumers of the API face surprise breaking changes. Ask the vendor for their published API versioning policy. Vendors who don't have one are exposing the carrier's downstream systems to ongoing breakage.

ACORD XML and AL3 implementation depth - beyond the checkbox

ACORD support is integration pattern #3 and the one where vendor "yes" answers vary most in real depth. This section walks the depth-of-implementation tiers and what to ask for to surface where each vendor actually sits.

The three implementation depth tiers

Tier 1 - full native ACORD support. The platform ingests and produces ACORD P&C XML transaction types in their native form, with full schema validation, semantic preservation across the platform's internal data model, and round-trip fidelity (a transaction received as ACORD XML can be regenerated identically). AL3 batch support is parallel - native ingestion and production with documented data dictionary mapping. This is the depth required for production-grade ACORD integration with independent agent systems and MGA partners.

Tier 2 - partial ACORD mapping with semantic loss. The platform has fields named after ACORD elements but transforms data internally in ways that don't preserve full semantic fidelity. ACORD transactions can be received and approximate transactions can be produced, but round-trip fidelity is broken. This tier works for carriers with light ACORD dependency but breaks at scale or for carriers with heavy independent agent distribution.

Tier 3 - logo-only ACORD support. The platform has the ACORD logo in marketing materials, references ACORD compliance in vendor responses, but lacks production-grade ACORD transaction handling. This tier is unacceptable for any US P&C carrier with meaningful agent or partner ACORD dependency.

What to ask in the RFP to surface tier

The RFP question that surfaces ACORD depth: "Please provide the complete list of ACORD P&C XML transaction types your platform ingests natively, with version (1.x or 2.x). Please provide the complete list it produces natively, with version. Please provide the same lists for AL3 transaction types with the AL3 standard version. Please indicate which transactions require custom mapping vs out-of-the-box support, and provide a sample ACORD XML message produced by the platform from a recent production deployment."

Why round-trip fidelity matters

Round-trip fidelity is the test that separates Tier 1 from Tier 2 ACORD support. If the carrier receives an ACORD XML transaction from an agent system, processes it through the PAS, and then needs to send it forward to a reinsurance partner or MGA, the regenerated transaction needs to be semantically equivalent to the received transaction. Platforms with semantic loss in their internal data model can't regenerate equivalent transactions, which means the carrier's downstream partners receive subtly different data than the carrier received. Over time this creates reconciliation issues that are expensive to debug.

ACORD next-generation digital standards

Per ACORD's 2024 Value of Standards documentation, the standards organization is publishing next-generation digital standards for microservices, APIs, and fine-grained insurance transactions. Vendors with active roadmaps for the next-generation standards - not just legacy XML and AL3 - are positioned for the API-first integration architectures mid-tier US carriers are building. Ask the vendor for their published roadmap on next-generation ACORD standards. Vendors without a roadmap are at risk of falling behind as the industry moves to the new standards.

Why mid-tier carriers need ACORD depth more than tier-1 carriers

Mid-tier US carriers in the independent agent distribution model rely fundamentally on ACORD integration with agent management systems. Tier-1 carriers with captive agent distribution have lower ACORD dependency. The ACORD depth that's a nice-to-have at a tier-1 carrier is a structural must-have at a mid-tier carrier. A PAS that's "mostly ACORD" doesn't fit the mid-tier carrier distribution model and creates ongoing operational friction with the carrier's agent partners.

Event-driven architecture - when it matters and when it doesn't

Event-driven architecture (EDA) is the integration pattern that's growing fastest in importance and that Daniel needs to evaluate carefully because vendor claims about EDA support range from comprehensive to cosmetic.

What event-driven architecture delivers

EDA decouples the PAS from downstream systems. State changes in the PAS publish events; downstream systems subscribe to events relevant to them. The benefits compound across the integration landscape: downstream systems don't need to poll the PAS for updates, the PAS doesn't need to know which systems care about which state changes, new downstream systems can be added without PAS changes, and failures in one downstream system don't cascade back to the PAS. For mid-tier carriers building modern claims, billing, and analytics integration, EDA is structurally better than synchronous request-response patterns.

When EDA matters most

Three scenarios where EDA is materially better than REST. First, real-time analytics and AI workflows that need PAS state changes within seconds. Second, integration with multiple downstream consumers of the same state change (claims, billing, BI all need to know when a policy is endorsed). Third, integration with systems that have variable availability or processing rates and would otherwise force the PAS into queueing or retry logic the platform shouldn't carry.

When REST suffices

Three scenarios where REST is fine and EDA is overkill. First, low-volume integrations where polling at acceptable frequency is operationally simpler than event subscription. Second, request-response integrations where the consumer needs an immediate response (real-time policy lookup, real-time premium calculation). Third, integrations with partners or systems that don't support event consumption and would need to poll an event queue anyway.

What to ask the vendor about EDA

"What event broker technology does the platform support - Kafka, RabbitMQ, AWS EventBridge, Azure Event Hubs, or proprietary? What event schemas are defined for which PAS state changes? What's the typical latency from state change to event publication? What guarantees does the platform provide on event delivery - at-least-once, exactly-once, ordered? What happens if a downstream consumer is offline when an event publishes - how is replay handled?" Vendors who can answer these questions concretely have real EDA support; vendors who can't are claiming capability they don't have in production form.

EDA and the AI workflow integration future

Per McKinsey's 2025 analysis of agentic AI in core insurance technology, autonomous and semi-autonomous software agents need real-time access to operational state and the ability to react to state changes as they happen. The PAS architectures that support this future are event-driven; the PAS architectures that aren't will limit the carrier's AI workflow integration options. For carriers planning AI workflow integration over the 5-year planning horizon, EDA support is becoming structurally important rather than nice-to-have. Any AI-driven decisioning built on top of that real-time data also has to hold up against the NAIC's Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, adopted in December 2023 and since implemented by state insurance departments across the country.

Integration cost categories that ambush your business case

Theintegration cost line in PAS business cases is consistently underestimated.Across the carriers I've worked with, integration costs run 1.5x to 3x theinitial estimate, and the gap is almost always in cost categories the businesscase didn't break out separately. Datos Insights'research on core system transformations, based on interviews withmidsize and large P/C insurers, points to the same industry-wide pattern:project costs and timelines routinely land outside what carriers scoped goingin.

The 4 integration cost categories that matter

Below isthe framework for breaking out integration cost in the business case. Mid-tiercarriers who use this framework typically come within 15–25% of actualintegration cost; carriers who use a single integration line typically miss by 50–100%.

Why the initial integration build runs higher than vendors estimate

Vendor estimates for initial integration build are typically based on the integration patterns that are well-documented and out-of-the-box for the platform. The cost overruns come from the integrations that aren't well-documented - the legacy partner system that uses a non-standard variant of ACORD, the third-party data provider whose API was last updated in 2018, the regulatory reporting system whose format changes annually. Mid-tier carriers have more of these long-tail integrations than tier-1 carriers, and the PAS vendor's reference customer experience often doesn't translate.

Why integration maintenance is the cost category most missed

Integration maintenance shows up in year 2 of the platform deployment, after the initial integration build is complete and the carrier has moved on to other priorities. Partner systems change, third-party data provider APIs update, regulatory reporting formats evolve, and each change requires integration team work. Mid-tier carriers with 12–18 integrations typically face 8–15 integration maintenance events per year. At $40–60K per event in fully-loaded engineering cost, this is a $300K–900K annual line item that often isn't in the business case.

Change cost per integration

When a downstream system changes - the carrier replaces the claims system, adds a new third-party data provider, switches reinsurance partners - the integration to the PAS has to change. Change cost per integration depends on the integration architecture quality of the PAS. Platforms with strong abstraction layers and integration testing infrastructure handle changes for $40–80K. Platforms without that infrastructure handle changes for $150–250K. This is one of the larger long-term cost differentiators between PAS platforms and rarely shows up in vendor pricing.

Partner onboarding cost

For mid-tier carriers in the independent agent distribution model, adding new agent partners or MGA relationships is a regular operating activity. Each partner onboarding involves integration work - ACORD configuration, partner-specific mappings, testing. Platforms with strong partner onboarding tooling support this for $20–40K per partner; platforms without tooling for partner onboarding can run $100–150K per partner. For carriers with active business development, this cost compounds quickly.

The Decerto integration services view

For the broader services context that complements the PAS platform integration capabilities, see our API and system integration services page. The integration architecture decision isn't only about the PAS - it's about the partner who can deliver the integrations across the carrier's actual landscape. For mid-tier US carriers, the partner who's worked with Allianz, Aviva, Warta, and Generali Group Poland integration patterns brings reusable knowledge to the engagement that significantly reduces integration cost overruns.

Daniel's PAS integration evaluation checklist for RFPs

The integration section of a PAS RFP that surfaces real architectural depth has specific evaluation methods that go beyond reading vendor responses. Below is the checklist I walk every Daniel equivalent through before they release the integration section of a PAS RFP.

The OpenAPI 3.0 spec audit

For each shortlist vendor, request the complete OpenAPI 3.0 specification for the platform. Don't accept summary documentation - request the actual spec file. Count endpoints. Audit a sample of 20 endpoints for completeness of request/response schemas, error response documentation, and authentication patterns. The spec quality is a direct leading indicator of integration architecture quality. Vendors who can't deliver a complete, current OpenAPI spec have weaker API-first architecture than vendors who can.

The reference customer integration architecture review

For each shortlist vendor, schedule a 2-hour technical architecture review with a reference customer's enterprise architecture team. Review the integration architecture they implemented, the integration patterns they used per system, and the integration issues they encountered post-go-live. The pattern that emerges from reference customer architecture reviews is more diagnostic than vendor-provided documentation.

The ACORD transaction sample request

Request a sample ACORD XML message produced by the platform from a recent production deployment, with the carrier name redacted. Validate the message against the ACORD schema. Check for semantic completeness - does the message preserve all the information the original transaction would have carried? Vendors who can't or won't produce a sample have ACORD support gaps they're hiding.

The integration pattern coverage matrix

Build the 8-pattern integration framework from Section 3 of this article into the RFP as a coverage matrix. For each pattern, ask the vendor to describe their capability with specific evidence - for synchronous REST, the OpenAPI spec; for events, the event broker support and schema documentation; for ACORD, the transaction list and sample message. The matrix forces the vendor to produce evidence per pattern rather than checkbox claims.

The partner system inventory mapping

Provide the vendor with your actual partner system inventory - agent management systems, MGA partner systems, third-party data providers, reinsurance partners - and ask them to identify which integrations are out-of-the-box, which require configuration, and which require custom development. Vendors who can map your inventory to their integration capability have done this work before; vendors who can't have integration gaps relative to your specific landscape.

The integration test environment evaluation

Ask the vendor about their integration test environment offering. Can the carrier's integration team work in a sandbox that mirrors production behavior? Are partner system integrations available in test? How long does it take to refresh test data? Vendors with mature integration test infrastructure deliver integration projects on time; vendors with weak test infrastructure run over.

The change governance question

"When you release a new platform version, how are integration breaking changes communicated? What's the typical lead time? What support is provided for migrating consumers of the API?" Vendors with mature integration governance answer this with specific commitments - typically 6–12 months notice on breaking changes with parallel-run support during migration. Vendors without governance treat integration breaking changes as the customer's problem.

The legacy integration capability test

Mid-tier US carriers typically need to integrate the new PAS with at least 3–6 legacy systems during the modernization transition. Ask the vendor: "What's your typical approach for legacy system integration during a migration project? What patterns have worked best on similar transitions?" Vendors with experience in mid-tier modernization have concrete answers; vendors who only deploy in greenfield contexts often don't.

The third-party data provider integration map

For the third-party data providers you actually use, ask the vendor: "Which of these have pre-built integrations available? For the others, what's the typical effort to build the integration?" Vendors with deep third-party data provider integration libraries reduce your integration build time substantially; vendors who treat every third-party integration as custom add cost.

The integration architecture decision documentation

For each shortlist vendor, ask for documentation of the integration architecture decisions they recommend for a mid-tier carrier in your line-of-business mix. Not generic best practices - specific recommendations for your situation. Vendors who can produce this have done the work for similar carriers; vendors who default to "we'll figure it out together" haven't. For broader architectural context that informs these decisions, see our policy administration system Pillar overview and the key features of policy administration insurance software framework.

FAQ

What are the integration capabilities of policy administration software?

Modern PAS integration capabilities span 8 distinct architectural patterns: synchronous REST API for real-time queries and commands, asynchronous event publishing for downstream consumers, ACORD XML and AL3 transaction support, bulk data export and import for migrations and reconciliation, webhook-based notifications for partner-facing integration, file-based batch integration for legacy partner systems, streaming data integration for real-time analytics and AI workflows, and identity and access integration through SAML, OAuth 2.0, and OIDC. Each pattern has a distinct capability profile and the PAS RFP should evaluate each one separately rather than as a single integration dimension.

How does PAS integrate with other systems in the carrier's landscape?

A mid-tier US carrier PAS typically integrates with 12–18 systems including claims management, billing, document management, CRM, BI/analytics, underwriting workbench, agent portal, customer self-service portal, ACORD-based agent systems and MGA partners, reinsurance partners, third-party data providers, payment processors, and regulatory reporting systems. The integration architecture has to handle different directionality (read-heavy vs write-heavy vs bidirectional), different data volumes, different latency requirements, and different change frequencies - which is why pattern-based integration evaluation works better than feature-list evaluation.

What is API-first PAS integration architecture?

API-first means every business operation in the PAS is available through a documented API before it's available through the user interface, with the API as the primary interface to the platform and the UI as one consumer of the API. The architectural test: when the platform adds a new capability, the API ships first or simultaneously with the UI, and integrating systems can use the new capability immediately. API-supplied platforms - where APIs are added as a layer on top of a UI-first platform - typically have gaps where operations available in the UI aren't available through the API.

How does ACORD integration work in modern PAS?

Real ACORD integration in modern PAS means native ingestion and production of ACORD P&C XML transaction types (versions 1.x and 2.x) and AL3 batch transaction types, with documented mapping for each transaction in the carrier's actual integration scope. The depth-of-implementation tier matters: full native support preserves round-trip fidelity (received transactions can be regenerated identically); partial mapping has semantic loss; logo-only support is unacceptable for US P&C carriers with meaningful agent or partner ACORD dependency.

What integration patterns matter most for PAS evaluation?

The 8 integration patterns that should structure PAS RFP evaluation are: synchronous REST API (RFP weight 16), asynchronous event publishing (14), ACORD XML and AL3 (14), bulk data export and import (12), webhook-based notifications (10), file-based batch integration (10), streaming data integration (12), and identity and access integration (12). Each pattern requires distinct evaluation evidence - OpenAPI specs, event broker support, ACORD transaction lists, sample messages - rather than checkbox responses to a generic integration question.

How should PAS integrate with CRM, claims, and billing systems?

PAS integration with internal systems like CRM, claims, and billing should use synchronous REST APIs for real-time queries (policy lookup, premium calculation), asynchronous event publishing for state change notifications (policy issued, endorsement applied), and bulk data exports for analytics and reconciliation. The integration architecture should decouple PAS from downstream systems so that changes in claims or billing don't require PAS changes. Modern integration patterns avoid the tight coupling that legacy point-to-point integration introduced.

What is event-driven architecture for PAS integration?

Event-driven architecture (EDA) for PAS integration means the PAS publishes events when state changes occur - policy issued, endorsement applied, premium calculated, document generated - and downstream systems subscribe to the events relevant to them. EDA decouples PAS from downstream systems and supports real-time integration without polling. The pattern matters most for real-time analytics, AI workflows, multi-consumer integration, and when downstream systems have variable availability. REST suffices for low-volume integration and request-response patterns where immediate response is required.

How to evaluate PAS integration quality in an RFP?

Use a pattern-based evaluation framework rather than a single integration question. For each shortlist vendor: request the complete OpenAPI 3.0 specification, request a sample ACORD XML message from a recent production deployment, schedule a reference customer integration architecture review, build the 8-pattern coverage matrix with specific evidence per pattern, provide your partner system inventory and ask the vendor to map integration capability, evaluate the integration test environment, and ask about change governance and breaking change communication policies.

What are the integration costs of modernizing PAS for mid-tier carriers?

Integration costs for mid-tier US carriers in the $500M–$5B GWP range fall in four categories: initial integration build ($1.5–6M for the 12–18 integrations in the typical landscape), integration maintenance ($300K–1.5M annually for ongoing maintenance as partner systems evolve), change cost per integration ($40–250K per change depending on platform integration architecture quality), and partner onboarding ($20–150K per new partner depending on platform onboarding tooling). Mid-tier carriers using the 4-category framework typically come within 15–25% of actual cost; carriers using a single integration line typically miss by 50–100%.

How does modern PAS integrate with legacy systems during a transition?

Modern PAS integration with legacy systems during a modernization transition uses three primary patterns: API-based integration where the legacy system has APIs (uncommon but increasing), file-based batch integration for legacy partner systems and regulatory reporting, and abstraction layers where the legacy system is wrapped in modern integration patterns to insulate the new PAS from legacy interface details. The integration architecture during transition needs to handle the carrier running the new PAS and the legacy systems in parallel for 12–24 months, which is structurally different from greenfield integration architecture.

Talk to Decerto about a PAS Demo and the Vendor RFP Workbook

Each year you defer modernization of your policy administration system, the integration debt accumulates - the workarounds for what the PAS doesn't expose through APIs, the manual reconciliation between the PAS and downstream systems that don't see real-time state changes, the ACORD partner integration gaps that surface as service issues with agent partners, the legacy integration patterns that lock the carrier into another generation of point-to-point connections. But for the technical evaluation team specifically, the bigger risk is signing a contract with a vendor whose integration capabilities look comprehensive in the RFP and turn out to be API-supplied rather than API-first, with logo-only ACORD support and event-driven architecture in roadmap rather than in production. The way out of that risk is an integration evaluation framework structured around the 8 patterns, the API-first vs API-supplied distinction, and the depth-of-implementation tiers for ACORD - exactly what we walk through in the PAS Demo conversation.

If you're earlier in the conversation and still scoping what a modern PAS architecture actually delivers at the platform level, start with the policy administration system Pillar overview before walking the integration framework. If you're already past architecture and need the broader feature framework that situates integration as one dimension among twelve must-haves, see our companion article on the key features of policy administration insurance software. For the operational user experience implications of integration architecture quality, see user experience and interface design in policy administration software.

The first conversation we have with mid-tier US carriers is not a generic product walkthrough. The PAS Demo runs 30 minutes with me (Marcin Nowak, 20+ years in insurance core modernization, 100+ insurance projects) and a senior solution architect - peer-to-peer technical Q&A focused on your specific lines of business, your actual integration landscape, your partner ecosystem, and the architectural decisions that shape your modernization plan. Output: a focused conversation matched to your carrier profile, not a sales pitch.

If we determine during the conversation that an enterprise tier-1 platform is structurally a better fit for your scale than Decerto Higson, we'll tell you that directly. Honesty on fit is not optional - it's the basis of the conversation. We work with mid-tier carriers in the $500M–$5B GWP range, and we know what integration realities that segment faces. The Higson product configurator, the integration with the Underwriting Workbench, the connection with the Agent Portal - 360 Agent's Workplace and the self-service customer portal, and the broader API and system integration services give mid-tier US carriers an integration architecture path that holds up under technical due diligence and through the long-term maintenance horizon.

Sources and citations

1. McKinsey & Company, May 2025, "How P&C insurers can successfully modernize core systems" - analysis of COTS vs build vs upgrade decision dimensions, integration complexity, configuration vs customization tradeoffs.
2. McKinsey & Company, 2025, "Can agentic AI (finally) modernize core technologies in insurance?" - agentic AI in operational workflows, real-time state access requirements, EDA implications.
3. Deloitte, 2026 Global Insurance Outlook - bifurcated industry analysis, modernization priorities, AI integration into core operations, data quality dependence.
4. Datos Insights, January 2025, "Navigating Core System Transformations: Trends, Challenges, and Lessons From P/C Insurers" - operational realities of core system transformations, panel insights from carrier leaders.
5. Datos Insights, 2025, "Property/Casualty Policy Administration Systems: Key Trends Transforming Insurance in 2025" - mid-tier and specialty insurer modernization wave, integration architecture evolution.
6. ACORD, 2024, "The Value of Standards" - standards organization documentation, P&C XML and AL3 standards, next-generation digital standards roadmap for microservices and APIs.
7. National Association of Insurance Commissioners (NAIC), Model Bulletin on the Use of Artificial Intelligence Systems by Insurers - adopted December 2023, with state-by-state adoption tracking through 2026.