Connecting policy admin systems: The Policy System Integration API That Feeds Your Renewal Engine

How a multi-LOB carrier with policy admin systems across regions uses InsightUW's Policy System Connector to ingest 200 expiring policies nightly — mapping ACCT_WARN_FLG to account_warning and PLCY_STAT_CD to policy_status — through a single POST /api/uw_renewals/ingest-policies endpoint that processes the entire batch in under 30 seconds.

The Problem

Large carriers do not run on one policy administration system. They run on three. Or five. Or seven — one per region, one per acquisition, one per LOB that was too complex to migrate. Each system stores policy data in its own schema, its own field naming convention, its own date format, and its own status code vocabulary.

When renewal season arrives, the underwriting team needs expiring policy data to feed their renewal workflow. But getting that data is a project in itself:

• Policy System A stores the policy number as PLCY_NBR, the expiry date as PLCY_EXP_DT (YYYYMMDD format), and the account warning flag as ACCT_WARN_FLG (values: Y/N).
• Policy System B stores the policy number as PolicyRef, the expiry date as ExpiryDate (DD/MM/YYYY format), and the account warning as RiskAlert (values: true/false).
• Policy System C stores the policy number as policyNumber, the expiry date as expirationDate (ISO 8601 format), and the account warning as accountFlag.warningIndicator (values: 1/0).

Three systems, three schemas, three field names for the same concept. The renewal team either builds custom integrations for each (expensive, fragile) or exports to CSV and manually reconciles (slow, error-prone).

The real cost is not just the integration effort. It is the ongoing maintenance: every time one of these systems upgrades, field names shift, new fields appear, old fields are deprecated, and the integration breaks silently. Policies fall out of the renewal queue. Underwriters discover missed renewals when the broker calls asking why they have not received a quote.

The InsightUW Approach

InsightUW provides the Policy System Connector — a configurable integration layer that maps fields from any policy administration system to InsightUW's canonical renewal schema. Each source system gets a connector configuration that defines field mappings, value transformations, and validation rules. A single API endpoint accepts policy data from all connectors, normalizes it, and feeds the renewal engine.

The Policy System Connector Model

Each policy system gets a connector configuration that defines how its fields map to InsightUW's canonical schema. The connector is a JSON configuration — no custom code required.

The Nightly Batch Flow

Each connector runs on a cron schedule, pulling expiring policies from its source system and pushing them through the normalization pipeline.

The Ingest-Policies API

For carriers that prefer to push rather than pull, InsightUW exposes a single ingestion endpoint that accepts policies from any configured connector.

Field Mapping Reference: Three Systems to One Schema

The following table shows how the same concept is represented across all three systems and how InsightUW normalizes them:

The Scenario

Atlantic Mutual Insurance operates across three regions with three policy administration systems:
- policy admin system for US operations (Commercial Property, GL, WC, Auto, Umbrella)
- policy admin system for EU operations (Property, Liability, Motor Fleet, D&O, PI)
- policy admin system for APAC operations (Commercial Property, GL, WC, Auto, Cyber)

Each night, the policy systems push expiring policies (90-day lookahead) to InsightUW. On April 21, 2026, the nightly batch processes 200 policies across all three systems.

Nightly Batch Timeline

What the Underwriting Team Sees at 8:00 AM

When the team logs in Monday morning, 26 new renewal work items have appeared in the unified queue — 12 from US, 8 from EU, 6 from APAC. Each renewal has a source system badge indicating its origin, but all data is in the same canonical format. The underwriter does not need to know whether a policy came from policy admin system or policy admin system — the fields are identical.

Seven policies arrived with flags. These sort to the top of the queue per the urgency scoring algorithm. The manager can see at a glance that 4 US policies and 2 EU policies need immediate attention.

Metrics: Before and After Policy System Integration

Key Takeaways

1. Field mapping is the integration, not code. The Policy System Connector replaces custom integration code with declarative JSON configuration. When policy admin system renames PLCY_EXP_DT to POLICY_EXPIRY_DATE in their next release, you update one field in the mapping config — not a code deployment.

2. Every system speaks differently, but the renewal engine only needs one language. The normalization layer converts the policy admin system's YYYYMMDD dates, policy admin system's DD/MM/YYYY dates, and policy admin system's ISO 8601 dates into a single format. The renewal engine never sees the source format.

3. Nightly batch with push fallback covers all patterns. Some policy systems support API pull (InsightUW calls them). Others only support push (the policy system calls InsightUW). The same /ingest-policies endpoint handles both patterns.

4. 200 policies in 27.4 seconds is not a performance number — it is a UX number. It means the entire batch completes before anyone notices it ran. By morning, the queue is up to date.

5. Deduplication across systems prevents double-counting. A global program with policies in both Policy System A and Policy System C would generate two renewal work items without cross-system dedup. InsightUW catches these using insured name matching, policy number patterns, and effective date overlap.

Ready to connect your policy administration systems to a unified renewal engine? InsightUW's Policy System Connector maps policy admin systems, and any other system to a single canonical schema — in configuration, not code.

Schedule a Policy Integration Review →