As advanced technology and predictive modeling continue to shape the evolution of insurance operations, two systems remain at the heart of most commercial and specialty insurance enterprises—underwriting and policy administration. As important as these systems are, many insurers still struggle to overcome the challenges that arise from integrating them.

Most organizations understand the business case for having product development, underwriting and policy processing systems integrated; the benefits include the ability to quickly deploy new products to market, improve the accuracy of risk analysis, promote processing efficiency and analyze risk and performance data. The overall objective is to optimize end-user effectiveness and process efficiency while minimizing technology expense.

But IT groups and business leaders often struggle to define the optimal path forward for such integration. For instance, some commercial and specialty organizations strive for a single user interface across UW and PA systems, believing such standardization is necessary to achieve cohesive processing. They neglect to consider the natural work delegation patterns inherent to underwriting and underwriting support operations. Others attempt to simplify their technical environment by using a single engine for all rule-processing, overlooking the range of rule complexity and limitations of rule-based technologies.

In this article, we outline the critical dimensions of successful integrations from the perspectives of business stakeholders and IT leaders who must collaborate to create the optimal solution architecture. We also highlight best practices that have proven effective for those insurers that have successfully integrated UW and PA systems. Along the way, we will cover process, data and rules implications from both the business and IT perspectives.

Critical considerations: the business perspective

Process: Recognize the unique roles and processes supported by UW and PA systems.

The key question from the business is who uses which tools and why.

Within commercial and specialty business lines, the general rule for optimized processing has been that risk analysis—generally performed by underwriters—should be supported by an underwriting system, while transaction processing—typically performed by operations staff—should be supported by a policy administration system.

Looking more closely at these user segments, it’s important to recognize that most underwriters will use UW systems for the vast majority of their work—90 to 100 percent in most cases. In contrast, operations staff will toggle between the two systems much more frequently and use each one for a significant portion of their work.

There are natural hand-offs between underwriters and support staff. For example, in middle-market and large commercial lines, underwriters use the underwriting system to complete risk assessments and initial quotes; then, they will typically instruct operations staff to prepare additional quote options in the policy admin system. Similarly, upon proposal acceptance and binding (captured in the UW system), underwriting will provide direction to the support team for policy issuance in the PA system.

In small commercial lines, the operating model involves more straight-through and rules-based processing. That means underwriters use the UW system primarily for referral handling and portfolio underwriting; in such “no-touch” underwriting environments, the PA system is virtually invisible to underwriters (and agents/brokers) and only visible to support staff when exception processing dictates interaction with the PA system.

These differences in processing and user behaviors align with the distinct user experiences and interfaces of the UW and PA systems.

Underwriters typically spend most of their time in the Underwriting Workbench while Operations owns policy processing. The UW Workbench centralizes the account management and workflow across the UW/Ops team.

Figure 1: UW and PA systems are designed to handle different tasks and support different types of users.

Data: Define structured approaches to data acquisition, sharing and storage across the account lifecycle

Because UW and PA systems rely on some common data for risk assessment and policy processing activities, it’s critical to determine consistent approaches for creating, collecting and updating data to ensure integrity and proper data ownership.

Data can originate from a multitude of sources, including email, upload from agency systems, agent portals, aggregators and third-party providers. Data may be digital, contained in documents or images, or communicated verbally. The same data may be used for both risk assessment, and rating, quoting and issuance processes, although not necessarily using the same business rules.

Parallel processing between underwriting and support operations may mean concurrent data changes in the account-handling process. Business leaders must define data usage protocols for the IT team working on the integration of the UW and PA systems.

Rules: Organize business rules to align with key processes and rule behavior

It is important to define a business rules architecture to inform and guide the integration of UW and PA systems. The foundation of such an architecture is a rules taxonomy that categorizes rule types by business process.

Typically, underwriting rules include categories such as:

• Clearance/registration
• Risk qualification
• Information ordering
• Risk assessment
• Pricing
• Authority and referrals
• Tasks and account workflow
• File documentation

Policy processing rules include categories such as:

• Rating
• Transactional management
• Policy issuance
• Out-of-sequence endorsement processing
• Pre-renewal initiation.

Product configuration rules include categories such as:

• Product availability
• Product eligibility
• Product packaging

The taxonomy should also define any inter-rule dependencies, as well as rule outcomes that trigger additional rules. This business approach to rules will help inform the approach to technical integration between the UW and PA systems.

Critical considerations: the IT perspective

Process integration: Define the functional integration to support the natural work processing and hand-offs

The integration between the UW and PA systems should account for the optimal processing environment for key functions, as well as the natural flow of activities and work delegation between underwriting and support operations. For example, in the new business process, the initial set of activities occurring in the UW system will typically include clearance/registration, risk qualification, third-party information ordering, risk assessment and file documentation.

Once underwriting has determined the account is worth quoting, a request or event will initiate the rating process; this is the first activity where the PA system will take over the data to calculate the premium. The two systems must govern the quote iterations that typically occur with commercial and specialty business, supported by system-event triggers and system workflows. “In some cases, a BPM (business process management) tool may be included in the solution architecture to move data from one system to the other. The bottom line is that when designing the integration between UW and PA systems, the functional boundaries of each system, as well as the surrounding systems, should be considered and the account lifecycle process hand-offs must be clearly defined as services.

Data: The totality of the solution architecture should be considered when designing the UW and PA integration

Another of the key considerations in designing the UW and PA integration is the use of master data management (MDM) components in the solution architecture. Such a best practices-based approach to integration will incorporate customer, producer and location data. In this case, the UW and PA systems either navigate to a distinct system for entry and editing of this data or utilize their native interfaces that then interact with the MDM system and database. To ensure data integrity, all systems in the solution architecture that are creating or editing such data must consistently follow this integration approach.

In the absence of an enterprise MDM approach, the UW system will typically serve in the “master” role for customer, producer and location data. While the UW system will capture and use some policy data in the clearance and risk evaluation processes, ultimately the PA system serves as system of record for booked policies.

Effort should be made to define a quote and policy XML schema that can be utilized across underwriting, policy, external engines (e.g., rules, rating) and external data acquisition. The backbone of this schema will be the product model.

The second key component is a cohesive operational storage strategy. Data will be captured and derived across multiple systems, but risk data is owned by UW systems, while the PA owns policy system-of-record data for downstream financials. Both databases should feed downstream data warehouses to support account and risk analytics as well as policy premium analytics.

Rules: The technical integration between rules-based engines must align with the business rules architecture while also optimizing rule performance.

In most implementations of UW and PA systems, the best-practice approach aligns the rule types with the appropriate technology components, such as:

• UW risk qualification/assessment/pricing with the UW rules engine
• Product availability and eligibility with the product configuration engine

• Premium calculation rules with the PA rating engine
• Task rules with the UW task engine
• System-to-system orchestration rules with the BPM engine
• Transaction rules with the PA transaction engine and
• Regulatory policy issuance rules with the PA issuance engine.

Key considerations for rule configuration as well as integration include alignment between the rule type and method (e.g., Boolean or true/false logic, mathematical logic) with the target engine to optimize engine performance.

The rules architecture should clearly define the approach to rule storage, rule execution and rule outcome in the solution. And, a cohesive approach to rule testing—across the lifecycle of account handling and across the integration architecture—is important to ensure that inputs and outputs of rules being executed are generating the results expected.

Alignment is Key

Successful UW and PA solutions depend on strong alignment between the business and technical aspects of account processing, data handling and rules management.

The inherent complexity of commercial and specialty business requires a sophisticated solution for integrating UW and PA platforms. Successful integration of these systems requires that project teams address both business and technical considerations within the context of a comprehensive overall solution architecture (including surrounding systems and databases) and that they adopt a proven approach and specific best practices for processing, data acquisition and ownership and business rules.