Applied Epic and Duck Creek are both enterprise-grade policy administration platforms, but their integration architectures are different enough that the same underwriting automation project will require meaningfully different implementation approaches depending on which platform you are on. The difference is not about feature parity at the application layer — it is about how each system exposes its data model to external tools, and what assumptions it makes about how that data will be consumed.
Getting this wrong at the design stage costs six to twelve months of rework. Getting it right means the risk scoring, FNOL routing, and portfolio monitoring tools you deploy actually work in production rather than generating data that no one looks at because the integration friction is too high.
Applied Epic's API Architecture
Applied Epic's API is built around the Applied Client Network's Integration Toolkit, which exposes a REST API for client and policy data reads and a more limited set of write operations. The REST endpoints follow a resource-oriented structure that is relatively predictable for standard operations: GET policy by ID, GET client by ID, GET activities by client. The authentication model uses OAuth 2.0 client credentials, which integrates cleanly with modern microservice architectures.
The practical limitation in Applied Epic is field-level data access. Not all policy data elements are exposed through the REST API. Some fields — particularly the detailed endorsement data and multi-line policy structure information that underwriting models need — are only accessible through the Applied proprietary data model, which requires database-level access rather than API calls. Carriers who want submission-level risk scoring at the ACORD 125 field level often find that the standard Epic API does not surface the raw ACORD data — it surfaces Epic's internal representation of that data, which may be mapped to Epic's field names rather than ACORD field codes.
The consequence for underwriting automation is that an Epic integration needs a data mapping layer that translates between Epic's internal field names and the ACORD standard that the risk scoring model expects. Building and maintaining that mapping layer is a non-trivial engineering task, particularly as Epic releases updates that may change field names or add new data elements.
Duck Creek's Integration Approach
Duck Creek's approach to external integration is more modular. Duck Creek OnDemand (the SaaS version) provides a set of APIs through the Duck Creek Open Integration Platform (OIP) that expose the policy lifecycle in a more granular way: separate endpoints for new business quoting, endorsements, renewals, and cancellations, each with defined payloads that align more closely with the ACORD XML standard than Epic's REST API does.
The tradeoff is complexity. Duck Creek's API surface area is larger and the payloads are more verbose. An integration that reads new business submissions from Duck Creek will receive substantially more data than the equivalent Epic integration — which is useful for a risk scoring model that can consume additional context, but requires more parsing logic at the receiving end. The Duck Creek OIP also uses a different authentication pattern in some versions, and the session token handling requires careful implementation to avoid authentication errors under high submission volume.
Duck Creek's strength is its event-driven integration capability. The platform supports real-time event publication for policy lifecycle events — submission created, quote issued, policy bound, renewal generated — which allows an external risk scoring system to receive submissions at the moment they enter the workflow rather than polling for new records. For carriers processing hundreds of submissions per day, event-driven integration is materially more efficient than the polling approach that most Epic integrations default to.
What This Means for ACORD Data Extraction
The ACORD standard defines a common data model for insurance transactions, with ACORD 125 for commercial property and casualty accounts and ACORD 126 for commercial general liability. In an ideal world, every PAS would store and expose ACORD-formatted data natively, and every third-party integration would consume standard ACORD fields. In practice, neither Epic nor Duck Creek is fully ACORD-native in their internal data models — they both map ACORD fields to internal representations, and the mapping is imperfect for some edge cases.
For an underwriting risk model that needs specific ACORD fields — prior loss history from ACORD 125 supplemental, scheduled locations from the commercial property application, occupancy codes from the insured's application — the relevant question is how reliably those fields are populated in the PAS and how accurately the API exposes them. In our experience integrating with both platforms, Duck Creek tends to be more consistent in ACORD field preservation for new business submissions, while Epic tends to have better data quality for renewal and endorsement transactions where the account history has been maintained in the system for multiple policy terms.
Guidewire as a Third Reference Point
Guidewire PolicyCenter, widely used in the Tier 1 carrier market, provides a third integration reference point. Guidewire's Cloud APIs are genuinely RESTful with JSON payloads and comprehensive documentation through the Guidewire developer portal. The PolicyCenter data model maps closely to the ACORD XML standard for commercial lines, which makes it relatively straightforward to extract the ACORD fields needed for risk scoring.
The practical challenge with Guidewire integrations is the approval and release cycle. Guidewire customers typically run on a release schedule managed by their IT organization, and API changes — even purely additive ones that add new read endpoints — may require waiting for the next major release cycle. For carriers on annual or semi-annual Guidewire release schedules, this means an underwriting automation integration that works on one release version may need updates after the next release, with a six-month lag between when the change is available and when it can be deployed to production.
Building Platform-Agnostic Risk Scoring
The practical approach for underwriting automation vendors is to build a PAS abstraction layer that normalizes data from Epic, Duck Creek, and Guidewire into a common internal format before the data reaches the risk model. The abstraction layer handles the field mapping, authentication, and polling or event subscription logic specific to each platform; the risk model receives a standardized data structure regardless of which PAS is the source.
This architecture adds one integration layer, but it significantly reduces the total engineering cost for carriers on different platforms and makes the risk model portable between platforms when carriers migrate their PAS (which happens more often than vendors typically account for). It also isolates the PAS-specific logic so that when Applied, Duck Creek, or Guidewire release API changes, only the abstraction layer needs to be updated rather than the core risk model.
RiskVert's PAS integration uses this abstraction architecture. Our Epic, Duck Creek, and Guidewire connectors normalize ACORD field data into a common submission object before it reaches the scoring engine. When a carrier migrates from Epic to Duck Creek — which several mid-market regional carriers have done over the past three years — the scoring model configuration remains unchanged; only the connector configuration updates.
Data Residency and Security Considerations
One architectural decision that is often underweighted in PAS integration discussions is data residency. Policy data for admitted P&C lines is subject to state regulatory requirements that limit cross-border data transfer in some jurisdictions. More immediately relevant for most carriers: their reinsurance agreements and MGA contracts may contain data handling restrictions that limit what policyholder data can be transmitted to third-party systems.
The conservative integration architecture transmits only the data elements necessary for the specific analytical task — for submission risk scoring, the underwriting data fields from the ACORD application without policyholder PII — and performs the scoring computation in the carrier's cloud environment rather than in a third-party cloud. This architecture satisfies most data residency and contractual requirements without requiring the scoring system to have access to the carrier's complete policyholder database.
Conclusion
Applied Epic and Duck Creek are not interchangeable from an integration standpoint, even when the business requirement is the same. The API architecture, field exposure model, and real-time event capabilities differ enough that a well-designed integration on one platform will not translate directly to the other without significant rework. Carriers evaluating underwriting automation tools should ask vendors specifically about their PAS integration architecture: whether it uses a normalization layer, how it handles ACORD field mapping, and what the upgrade path looks like when either the PAS or the automation tool releases updates. Those answers reveal more about the real integration cost than any feature checklist.
Questions about integrating RiskVert with your PAS?
Contact us at support@riskvertx.com or schedule a technical discussion.