The five-tier mental model

Carrier technology is not one system, it is five tiers stacked on top of each other. Every IDP engagement integrates with at least two of them, and most touch three or four. Get the layering right and integration conversations become tractable.

From bottom to top: data & reference services feed the stack. Document and email gateways collect inbound work. Underwriting workstations and rating engines do the evaluation work. Policy admin systems hold the contract of record. Broker management systems sit on the distribution side and feed everything inbound. Reinsurance systems sit above policy admin and cede risk outward.

Two cross-cutting layers

Underneath the five tiers, two cross-cutting layers feed the entire stack and are worth keeping in mind:

• Data & reference services. Verisk / ISO (forms, rating, geocoding), NCCI (class codes), PCS (cat events), RMS / AIR / Moody's (cat models), LexisNexis (loss data, MVRs), Dun & Bradstreet (firmographics). The reference data every other tier consults.
• Identity, governance, and observability. Okta / Entra ID, audit logging, SOC 2 / ISO 27001 controls, model governance frameworks. The control plane that wraps the workflow tiers and that every InfoSec review examines.

Policy administration systems

The policy admin system is the contract of record. It holds the named insured, the policy form, the limits, the endorsements, the billing instructions, the producer of record. Everything ultimately reconciles to the PAS. The PAS is also the system most carriers spent the last decade replacing, and the migration is rarely complete.

What this means for IDP

An IDP platform almost never writes into the PAS at first. It extracts data from inbound documents, normalizes it, and hands it to an upstream system — the underwriting workstation, the broker portal, or a routing layer — which then writes to the PAS through that system's normal interface. Trying to write directly to PolicyCenter or Duck Creek triggers an integration project measured in quarters, not weeks.

Underwriting workstations & rating

The underwriting workstation is where the actual evaluation work happens. It is the screen the underwriter looks at to triage a submission, request additional information, apply schedule modifications, and bind. Some carriers buy this layer from a vendor. Many build it themselves, especially in commercial and specialty. The rating engine — which computes the actual premium given exposure inputs — sometimes lives inside the workstation, sometimes separately.

Where IDP fits

The underwriting workstation is the highest-leverage integration target for IDP at most commercial carriers. Pre-populating the workstation from inbound submissions is the canonical "submission triage" use case. The pattern: inbound email or broker portal lands a submission → IDP extracts ACORD, supplemental, loss runs, narrative → structured fields are pushed to the workstation, often via a thin queue or message bus → underwriter opens an already-populated workspace.

The integration interface varies enormously. Mature vendor workstations have REST APIs. In-house workstations may have only a database write or a file drop. The most common pattern in production: IDP writes to a staging table that the workstation reads, with a clear handoff schema.

Broker management systems

The broker side of the wire runs on a completely different software ecosystem. Brokers — retail and wholesale — use broker management systems (BMS) to handle the client relationship, the placement workflow, the certificate issuance, and the commission accounting. For US/Canada, the market is dominated by three or four vendors. For UK/EU, the landscape is different and Acturis is dominant.

What this means for IDP

For carrier-facing IDP, the BMS is the system the submission came from. Understanding which BMS a key broker uses lets you predict the submission format. Acturis exports look one way; Applied Epic exports look another. Many brokers have email submissions that bypass the BMS entirely for non-standard placements.

A growing pattern: carriers building BMS-integrated submission portals (often using Acturis APIs in the UK or Applied integrations in the US) so submissions arrive as structured data instead of email attachments. IDP still has a role here — supplementals and narrative content rarely come through the structured pipe — but the value proposition shifts from "extract data" to "fill the gaps."

Document gateways & ECM

Below the workflow tiers, carriers run an enterprise content management (ECM) layer that holds every inbound document, every issued policy, every claim file. Historically this was an imaging system; today it is a content services platform. The ECM is rarely talked about by name in sales conversations, but it is almost always the first system an IDP platform integrates with.

The intake pipeline pattern

The standard pattern at a commercial carrier: a shared mailbox (e.g., newbusiness@carrier.com) receives broker submissions → an email gateway parses attachments → documents are stored to the ECM → metadata is generated → a routing engine assigns the file to an underwriting team → IDP runs against the documents to classify and extract → results flow into the underwriting workstation. Five systems just to land a submission in front of an underwriter.

Most IDP integrations sit at the "documents are stored to ECM" or "routing engine assigns" stage. Integrating earlier in the pipeline (at email landing) is technically possible but often touches more InfoSec surface than carriers want to open.

Reinsurance systems

Above the policy admin tier sits the reinsurance system. This is where the carrier or MGA tracks what they have ceded to reinsurers (treaty and facultative), what they have retained, what they expect to recover on a given loss, and what bordereaux they owe to which reinsurance partner. It is its own ecosystem, distinct from the primary PAS, and increasingly an IDP target as ceded data flows become more automated.

The reinsurance system is where bordereaux land. Premium bordereaux, claims bordereaux, risk bordereaux — all flow from MGAs into carriers, and from carriers into reinsurers. IDP plays an enormous role here: bordereaux normalization across hundreds of MGA partners with hundreds of slightly different Excel templates is one of the highest-ROI use cases in the entire stack.

Data & reference services

Underneath the entire stack sits a layer of reference and external data services. Every workflow tier consults them. Knowing which carriers subscribe to which ones lets you predict what data is available natively versus what needs to be extracted from inbound documents.

A worked submission example

Putting the tiers together. A mid-market commercial GL submission from a wholesale broker to a US carrier, end to end:

This is the canonical flow. Variations are everywhere — a small MGA might compress steps 2 through 5 into a single platform; a London syndicate would replace step 1 with a PPL/Whitespace risk submission and step 7 with the Sequel stack. But the underlying logic — ingestion → classification → enrichment → evaluation → contract of record → cession — is universal across regions.

Where IDP plugs in

Mapping Indico-typical use cases to the stack:

The "where is the data" cheat sheet

Six questions to ask in any first technical discovery call. The answers tell you where to integrate.

1. What is your PAS, and what version? (Guidewire / Duck Creek / Insurity / Majesco / Sapiens / in-house)
2. What ECM holds inbound documents? (ImageRight / OnBase / FileNet / SharePoint / shared drive)
3. What underwriting workstation do underwriters use? (Vendor / in-house / browser tabs on the PAS)
4. Where do brokers submit? (Direct email / broker portal / BMS integration)
5. What rating engine fires the price? (Earnix / hx / in-house / inside the PAS)
6. If a ceded business — what reinsurance system holds the treaty book? (TAI / SICS / Sapiens / Sequel / Excel)