One Policy System or Two?

(1)

WHITEPAPER

Guidelines for choosing between combined or separate policy

systems for P&C commercial and personal lines

(2)

© Cover-All Technologies, Inc. 2

Introduction

“Should we have one policy system or two for best managing underwriting and policy processing?” That question has been posed countless times by hundreds of business and IT executives at commercial and personal lines property/casualty (P&C) insurance companies for the last several decades.

After all of our research, here is the simple answer to this complex question: “It depends.”

We understand that this answer may not be exactly what you were looking for. However, we believe the balance of this white paper will assist you in determining the right answer to this question for your organization, which will depend upon on a number of factors including your organization’s requirements for both today and tomorrow. During our research we had challenges finding unbiased opinions on this topic. While we are a for-profit P&C core system software provider, our objective is to provide factual and unbiased information that will be valuable to our readers in concluding for themselves the right direction for their company.

Benefits of a Single Commercial & Personal Lines Policy System

Some of the business benefits of utilizing a combined commercial and personal lines policy administration and underwriting system (many of which can be quantified) include:

 Having a similar user interface (UI) for both external agents and internal users across lines  Reduced initial acquisition and implementation costs, including ongoing IT support costs

 Consistent business processes, practices, and data flows throughout the organization with the flexibility to easily enable custom workflows

 Enhanced responsiveness and efficiency of customer service because customer information is in one location with no need to learn multiple systems and interfaces

 Access to common third-party interfaces and external data sources, including agency systems  Efficiencies afforded by common integration with other systems such as claims, billing,

accounting, sales, and customer relationship management (CRM) systems

These benefits need to be balanced against the total cost of ownership (TCO) for the solution(s) selected to provide this functionality. If selecting two solutions provides a faster time to market, has a lower five-year TCO, including cost to maintain, and is less risky, strong consideration should be given to that option with an eye toward total business benefits.

Is One Policy System Practical?

Prior to delving into the attributes of modern policy system architectures that make a solution capable of managing both commercial and personal lines, or discussing whether a commercial lines solution is more easily adapted to meet the needs of personal lines or vice versa, the first question that an insurer should ask is, “Is having one policy system even practical?”

(4)

© Cover-All Technologies, Inc. 4 offered. Additionally, retrofitting a software solution from a less regulated market or another country may be drastically different, in some cases causing a re-architecture of the policy system in order to conform.

In all of these situations, a review of the solutions requirements gap should be performed in order to reduce implementation risk. In addition, strong consideration should be given to vendors that provide a flexible architecture with the most out-of-the-box capabilities. A flexible architecture which can be more easily configured (not through code changes) to meet most market requirements, or that fully complies with these requirements out-of-the-box, will minimize risks, implementation time, and costs. In principle, taking a sophisticated solution proven to meet the needs of complex regulatory requirements and adapting it to the needs of a less regulated market or less complex product may make sense, depending on the gaps in functionality.

Configuring Down vs. Developing Up

The basic principle here is that it is easier to configure a sophisticated software solution to meet the needs of a less complex insurance product. This is generally less risky than trying to take a less complex insurance product and unnecessarily modifying it by developing new expanded functionality to meet the needs of a complex software solution. It’s the classic problem of trying to fit a square peg into a round hole. Ultimately, why force it?

For example, it may be easier and more cost-effective to adapt a solution that supports commercial auto to personal auto than vice versa. Typically, commercial auto functionality is broad and deep, with the highest number of state exceptions, and it often requires managing large schedules of fleets and a variety of rating plans. This complexity grows exponentially considering the unique nuances of every state, numerous forms, rules of attachment for these forms, and special underwriting rules for each class of business, including the need to take timely bureau updates. Comprehensive features that are required to support commercial auto could easily be “hidden” through configuration when dealing with personal auto, as long as the simplicity of the UI for personal auto is preserved. On the other hand, the development effort would be significantly more involved in order to build the functionality and processing capabilities needed to support commercial auto if you are starting with a software solution specifically engineered to support personal auto.

To further illustrate this point, consider an insurer that writes more personal auto volume than commercial auto. Such a company may lean toward selecting a personal auto solution and then attempt to adapt it to meet the company’s commercial auto needs. However, if a solution known for its strength in commercial auto can effectively demonstrate that it can be configured to meet the needs of both personal and commercial auto, this solution should be considered because the costs and risk of configuring down would be dramatically lower than the costs of developing up.

(5)

© Cover-All Technologies, Inc. 5 The graph below represents the relationship of the configuration efforts in terms of resource hours for building certain underwriting and rating features and functions of commercial auto compared with personal auto.

Commercial and Personal Auto Quoting

Schedule, Experience, Composite, Bulk, Interpolation, Multi-State, Audits (CL)

Large Fleet Management (CL)

Personal Info (PL)

Credit History -(PL)

Vehicle Type and Usage

Loss History

Rating, Audit, Rules CL Shared Fleet Mgmt (CL)

LEVEL OF COMPLEXITY OF RATING DEVELOPMENT IS ILLUSTRATED BY CHART PERCENTAGES.

Loss History

Vehicle Type & Usage

(6)

© Cover-All Technologies, Inc. 6 The One Policy System

Vendors with modern architectures and technology generally have greater success adapting their solutions from either commercial to personal or vice versa. Vendors typically have uneven strengths between personal and commercial lines. Generally, all vendor solutions in the market have started first with either commercial or personal Lines and then invested more heavily in development of functionality and gained traction with their clients in one market segment faster than the other driven by client demands. Consequently, there are no vendor solutions in the market today that equally support both commercial and personal lines with modern architecture and self-serve configuration flexibility.

So, how can an insurer identify whether a policy system is a good candidate for handling both commercial and personal lines? The ability to support both commercial and personal lines on the same policy system seems to be tied to the solution having:

1) The ability to support straight-through processing (STP) 2) A modern architecture

3) An intuitive, powerful, and flexible UI.

Following is a detailed exploration of these three attributes and their importance in determining if the policy system being considered will be a successful candidate for implementation of both commercial and personal lines. Also provided in Appendix A is a CL and PL Complexity Comparison, a table of solution attributes, whether these attributes are considered complex or simple based upon whether a commercial or personal lines solution is being considered, and the factors that should be considered if a commercial lines solution is selected to deploy personal lines or vice versa.

Requirements for One Policy System to Support Commercial and Personal

Lines

1. Straight-Through-Processing (STP)

One of the great advantages of modern insurance policy systems is the ability to have an agency portal, rating, quoting, document generation/issuance, document imaging, and policy administration that supports the full policy lifecycle all on the same system. In addition, a modern policy system should support standard processing functions such as out-of-sequence endorsements (OOSE), auto renewal, and reporting on the same system, as well provide the option for self-serve product configuration capability. When a solution is engineered with all these functions in mind, has a single unified data model, and ideally a single database to minimize the integration and the redundant storage of data between components, STP can be fully achieved, even with complex commercial lines business.

(7)

© Cover-All Technologies, Inc. 7 analytics and other ideas about innovative ways to price risks will continue to accelerate these market changes. In order to accommodate this, a high level of flexibility and agility in a policy system should be the focus of any modernization project.

Many insurance organizations have evolved over the years to utilize separate applications for rating, quoting, policy administration, issuance, document imaging, reporting, business rules, and workflow. The investment in each of these applications may be quite deep, and to the detriment of operational success, there will be a strong temptation to try to preserve these technologies through the legacy transition to ease the pain of the transition. The future is likely to include a movement away from siloed vertical (horizontal) workflows to an optimization of the value chain of the product. However, a heavy focus should be placed on the envisioned environment that will ultimately result from the legacy transformation that will be in place for the next 15-20 years after the project is fully complete, with a reduced focus on trying to simplify the transition process during the couple of years the new policy system is being implemented. Keeping a clean, efficient operational technology future in mind, leveraging the best of what a new policy system can provide and letting go of the past will be essential to the long-term success of your project and achievement of your goals to modernize your organization. The flexibility provided by a solution that promotes STP will allow your organization to compete well into the future and will reduce your TCO for your solutions.

SPECIAL NOTE: An insurer’s choice of policy system should also be heavily influenced by the organizational structure of the business. Technology is too important to be out of synch with strategic business plans, measures, and rewards.

Solutions that support STP and have all of the referenced functionality to manage the full policy lifecycle on the same policy system promote faster speed to market and are better positioned to be adapted from commercial lines to personal or vice versa.

Expert Comments on STP

Due to the complex nature of risks associated with some mid-size and large commercial accounts, creating a solution to automate these types of risks is quite challenging. Here are some comments from experts on the topic of STP:

“In personal lines it’s all about low-touch, no-touch STP (straight-through processing). On the commercial side, companies are doing it [STP] for small risks, but when you get into larger more complex risks, [efficiency] becomes about streamlining the process, reducing handoffs, and using automation to guide the decision-making process and create a platform for collaboration.”

Deborah Smallwood, SMA

“Straight-through efficiency has been a more elusive goal in commercial lines. For smaller commercial policies and business-owner policies, it [STP] is getting there. Never say never, but I think we’ll be hard pressed in the near future [to reach the point] when mid-size or large accounts will be underwritten straight though, no touch.”

(8)

2. Modern Architecture

The flexibility touted by solutions that support STP is typically made possible by the modern architectural approach taken in design. To best understand the new architectural approach, it is important to first examine a contrast with older legacy architectures.

Legacy Policy System Design

Prior to the year 2000, most insurance systems were hard-coded, whether built in Windows, mainframe, or mid-range (AS/400, Unix, etc.) technologies. The UI was not configurable, and even their supposedly configurable business rules were really hard-coded rules with parameters to be executed. Screens, business logic, and database models were all structured in a way that any change required a time-consuming and costly programming modification, thereby making required insurance product maintenance a very expensive proposition. There are no new insurance product related projects that are observed to use this architecture.

Old Industry Metadata Policy System Design Approach

In the early 2000’s, insurance software vendors began designing metadata-driven policy administration solutions in order to increase insurance product development and speed-to-market. The metadata approach provided these solutions with automatic generation or dynamic rendering of the UI from the products defined in the metadata, increasing speed-to-market of new products. However, these applications didn’t employ a standard relational database. Without a relational database, integration back to legacy or batch driven systems, data integrity issues, and a number of additional problems arose that do not easily support complex insurance processing needs, off-setting the benefits of this architectural design. For example, these solutions often stored policy data in XML instead of in a relational database, requiring a complex work-around for extracting data and mapping it to a relational database, often disabling the ability to provide real-time reporting and policy processing.

New Policy System Design Approach

Fortunately, vendors learned from these early designs and have begun to create new, more innovative insurance architectures. A new database + metadata-based policy system design has emerged, which combines the best of the metadata approach with the database-driven approach. This modern design allows policy system data to be more readily accessed and easily extracted for further analysis and business intelligence (BI).This is a major benefit as insurers explore the usage of predictive analytics for underwriting. This new architectural model has proven to be the best approach in increasing insurance product speed-to-market while promoting data quality, improving the user experience, and reducing costs.

Additional benefits include:

 A high degree of reusability which increases speed-to–market

 Automatic generation of relational data model from metadata

 Automatic generation of UI from metadata

 Interactive product design and prototyping between business analysts and the underwriting team

 Relational access to data

 Declarative data integrity

(9)

© Cover-All Technologies, Inc. 9 To take advantage of this architecture, it is vital to have a WYSIWYG product configuration tool that is business analyst–friendly, and that can quickly define and deploy new insurance products in a matter of days or weeks while also maintaining existing products. With this type of tool, the business analyst does not need to be concerned about database schemas or inner workings of rating and policy administration systems, instead focusing solely on product development, design, and prototyping to accelerate the launch of new products, modify existing products, and most importantly, enhance the end-user experience.

Since frequent changes to existing products are necessary and the need to launch new products rapidly continues to increase, automated testing tools that are tightly integrated with an insurer’s policy administration system can provide significant productivity improvements. Perhaps the most important test of any architecture is to prove whether or not the configuration and testing tools can withstand the complexity of product such as bureau-based commercial lines. For example, just because a product configuration tool is used to develop the D&O product does not necessarily guarantee that it will provide the depth of features and functionality needed to configure complex products, such as commercial auto. However, if a product configuration tool is used to develop a complex product like commercial auto, it can almost be guaranteed that this tool can easily configure a less complex product (configuring down vs. developing up) like D&O.

Customer-Centric View

To maximize your investment in having a single solution for all insurance products, both commercial and personal, the solution will need to have a concept of an Account/Household in which all quotes, policies, and claims for the insured can be easily viewed in one place. This insured-centric view should associate information about individual risks such as a schedule of vehicles, properties, and equipment that can be shared between lines of business (LOBs). For example, if a business has a schedule of buildings entered for a quote or for a commercial package policy, this schedule of buildings can be used to validate the locations of vehicles for their commercial auto policy. This functionality and 360-degree view of a client should be carefully considered due to the impact on efficiency, STP, and other important processing considerations.

Vendors with modern architectures should be able to relatively easily adapt their solution to meet the needs of both personal and commercial lines. However, this should be carefully explored by evaluating the product development process and how it impacts the UI, system upgrades, and other ongoing maintenance activities.

(10)

© Cover-All Technologies, Inc. 10 system technical constraints. Simply moving existing insurance products onto a modern platform will be a wasted opportunity without streamlining these processes.

A policy system that is based upon modern architecture supports all policy lifecycle functionality and a customer-centric view WHILE allowing for self-serve configurability should be strongly considered. If the product configuration tools and system can support complex commercial lines, it can almost be guaranteed that these tools can configure and support less complex products and personal lines.

3. Intuitive User Interface (UI)

The success in implementing a single solution as your core policy system for both commercial and personal lines lies in the consistency, simplicity, and intuitiveness of a UI. In addition, if your policy system is to be extended to your agents, the system should be simple and intuitive since many of these agents may be infrequent users and may not retain the training given for the system. However, there is a balance that must be considered, taking into account the need for simplicity in quoting a personal lines product and the robustness required for a commercial lines product. This balance of consistency with a single UI will directly impact the success of STP, particularly for commercial lines.

In SMA’s recent report, “Underwriting Automation: Insurer Plans and Trends,” Deborah Smallwood discovered ease of doing business for agents and brokers was rated the most important factor for insurers to simplify the submission process, but more is expected of insurers, particularly in the areas of efficiency and effectiveness. In fact, Smallwood stated:

“There is a huge gap between underwriting effectiveness and consistency. The way you get consistency is through automated rules and workflows, bringing in some predictive models, and scoring.”

Design

When evaluating systems, there are key principles of good UI design that you can use to help determine whether a solution will be a good option for both commercial and personal lines. These are:

a) Intuitive Navigation

If your policy system is to be extended to your producers, the system will need to be simple and intuitive since many users may be using the system infrequently. Turnover is high at some agencies and brokerages, and it is highly likely that an untrained user will at some point access your system for processing an application in order to generate a quote. If agents and brokers don’t find your systems easy to work with, they will opt to write business with insurers with whom it is easier to do business. Having a fast, real-time rating and issuance system will make it easier to onboard new agents and retain existing producers.

b) Consistency of UI between Products

(11)

© Cover-All Technologies, Inc. 11 user, each product will feel like a separate system, and many of the benefits of having a single policy system for commercial and personal lines will be lost.

To assist with the ease of use, special attention should be focused on:

 Consistency of data entry screens

 Use of reflexive questioning

 Deriving answers to underwriting questions through third party data

 Lookups and partial data entry auto completion

 Formatting of data-dates, zip codes, phone numbers

 Usage of user-friendly data grids for filtering, sorting, adding records, updating records individually or en masse.

Connectivity

Part of expanding product distribution is ensuring agents’ ability to access insurer solutions. The more agents an insurer has, the less control the company will have over how agents access systems. Therefore, it is vital that a policy solution is not only accessible over the Internet, but that it is 100% web-based without any plug-ins, and can be accessed through all leading browsers. In addition, to maximize agent satisfaction and increase usage of the system by distribution channels, the system should automatically save all work to eliminate any re-keying. For example, a commercial insurance application that has a large schedule of risks being insured should be automatically saved by the system, just in case the individual user is disconnected from the internet for any reason.

Performance

Extending rating and policy admin applications to distribution channels will likely result in loss of control of the desktop and networking processing standards that ensure consistent application performance. Consequently, when an outside partner complains about the speed and performance of the application, an enormous amount of time can be spent investigating the cause of a problem. Most frequently the cause of the problem is not the insurer’s software or servers. It is useful to ensure that mission-critical systems, such as core administration applications, have a built-in performance management console that can track each transaction with intelligence to pinpoint the area of performance concern with minimal effort.

Policy System as a Hub

(12)

© Cover-All Technologies, Inc. 12 Other things that also affect the intuitive nature of the UI are:

 A user personalization feature

 Role based security

 Configurable workflows

 Real-time data processing

In order to support both personal and commercial lines, a UI should be consistent, intuitive, and easily accessible by all users across distribution channels. It should also support the entire policy lifecycle and STP via a true 100% web-based system.

Summary

Insurers should carefully evaluate the decision of whether to have one policy system for personal and commercial business or to have a separate policy system for personal and commercial business based on the following considerations:

 The practicality of one policy system for personal and commercial business based upon market, jurisdiction, product mix, and business factors

 TCO and return on investment (ROI) comparisons of a combined or separate policy system configuration for commercial and personal lines systems

 A comparison of “configuring down” a policy system with more out-of-the-box complex commercial lines versus “developing up” a policy system with relatively simpler personal lines

 A thorough assessment of out-of-the-box features and functions relevant for both commercial and personal lines

 A thorough evaluation of system architecture, data model design, and self-configuration flexibility Finally, insurers should review capabilities needed for commercial and personal lines, carefully evaluating the support for the full policy lifecycle and STP across all lines of business, as well as the flexibility of data access and ease of reporting which aids BI and predictive analytics-based underwriting, and a simple, consistent, accessible and intuitive UI.

Works Cited

Smallwood, Deborah M. (2012, February 20). Underwriting Automation, Insurer Plans and Trends. Retrieved from SMA:

https://strategymeetsaction.com/underwriting-automation/

Voelker, M. P. (2012, September 4).The Efficiency Mantra. Retrieved from PropertyCasualty360:

(13)

Appendix A: Comparison of Commercial and Personal Lines

BUSINESS PROCESS COMMERCIAL LINES PERSONAL LINES IMPACT ON RETROFITTING

A CL POLICY SYSTEM TO MANAGE PL IMPACT ON RETROFITTING A PL POLICY SYSTEM TO A MANAGE CL Accounts Complex

Commercial risks are highly varied, and many tend to be very industry specific.

This environment creates a need for highly customized, numerous unique insurance products tailored to meet every industry nuance. As a result there is high

segmentation

Simple- to complex for high value insureds Market segmentation by customer type

Every resident needs some type of housing, property, and vehicle insurance - some required by law

Account centric functionality will be needed in which schedules of units such as properties can be used between lines of business. If there is a change to an address, for example, a notification will need to be sent to the underwriters of each policy

Risks Many more types of risks for business/enterprise can be up to 35 and more lines of business. On top of that, there are many more coverages per line.

Individual, generally up to 11

Distribution Models  MGA

 Broker (program business)

 Agent, IIA only

 Captive Agent

 Independent Agent

(14)

A CL POLICY SYSTEM TO MANAGE PL

IMPACT ON RETROFITTING A PL POLICY SYSTEM TO A MANAGE CL

Because of the subject matter complexity Brokers/MGA’s develop entire practices around a niche market, such as Liquor stores, Construction, aeronautics, etc.

Application, Rating & Underwriting

Much more complex

 Many varying lines of business

 Larger schedules of units being factored in to algorithms (drivers, cars, buildings, boats,

equipment, class codes, etc.)

 Packaging of multiple lines together

 Policies that span multiple states

 More robust functional requirements

 complex risks that require more subjective

judgment

Trend is to move towards more automation

Simpler Tiering

Increased use of automated underwriting and models - some very sophisticated coverages as well as service related components

 More “wizard” like data entry process created

 bulk schedule

management features de-emphasized

Requires functionality to be built and scale tested for managing large schedules of units, including:

 loading of schedules from an external data source

 validating data accuracy including location verification

 mass updating data. For example performing a mass update of 1000 vehicles on a auto policy or 1000 vessels on an Ocean marine policy

In addition, functionality will need to be built that supports

 multiple lines are bundled together in a single policy

 policies that span multiple states

 calculation of taxes and surcharges of each state

(15)

A CL POLICY SYSTEM TO MANAGE PL IMPACT ON RETROFITTING A PL POLICY SYSTEM TO A MANAGE CL architecture to support creation of any insurance product

Creation of a construct in which bureau updates can be adopted that do not overwrite client specific deviation

Policy Size  larger premium volumes

 large schedules of units

Smaller policies: for example, 1-5 vehicles, drivers, or homes; complexity with PAF schedules

Document/Forms Management Complex

Requires ability to manage large complex document packages made up of many smaller documents, some of which are automatically included, others that are subjectively included.

Requirements for multiple attachments and complex rules of attachment at various stages in the policy lifecycle

Simpler, but large number of forms creates complexity

Simpler, generally extended with umbrella

Needed forms for Personal lines need to simply be added to the forms library, including their rules of attachment

Creation and management of a construct in which over 3,500 bureau related forms for 50 states, including their rules of attachment pertaining to the conditions by which they get attached and at what part in the workflow they get attached.

Creation of a construct in which bureau updates can be adopted that do not overwrite client specific deviations

(16)

A CL POLICY SYSTEM TO MANAGE PL

IMPACT ON RETROFITTING A PL POLICY SYSTEM TO A MANAGE CL

Lines. Lesser Regulated non-admitted (E&S) lines.

Bureau Changes Many Changes Many Changes Creation of a construct in which bureau updates can be adopted on a monthly basis that do not overwrite client specific deviations

Front End User Interaction Risks tend to be too large and complex for an insured to submit business independent of an insurance expert like an agent or broker.

In addition, many risks tend to be too complex to make them effective with a comparative rater.

Because of these

complexities, there tends to be a lot of underwriter judgment required

However, there is a push for Agents to have more self-serve capabilities similar to personal lines Highly automated:  Comparative rating  Immediate quoting  Policy self-service options

Creation of a simple Insured focused Portal that includes:

 On-line rating and binding directly by the insured.

 On-line insured focused self-service tools

Agent/Underwriter real-time on-line collaborative tools will need to be created, including the support of

 Application submission

 Creation, notification, and clearance of Underwriting subjectivities

Underwriting/Actuarial More expert knowledge, human

judgment, and theory used in

(17)

A CL POLICY SYSTEM TO MANAGE PL IMPACT ON RETROFITTING A PL POLICY SYSTEM TO A MANAGE CL decision making

Rate Setting/Actuarial Utilizing industry third party data such as ISO, NCCI, etc.

More centered on using company data for setting rates