Entertainment Commercial Package Policy in Insbridge

CASE STUDY

Introduction
The risks faced by the entertainment industry can be unique and vary widely. In order to cover those risks, Insurance carriers offer coverages with purely Entertainment Specific coverages. In Addition to those coverages, Insurance carriers will provide Commercial package policies that combine coverage for multiple perils, such as liability and property risk. As a result of this, we end up in an interesting situation as to how best implement this product.

This paper is intended to explain the complexity of the Entertainment Commercial Package Policy and provide methods of implementations that address potential issues.

Breaking Down one Line of Business in the Commercial Package Policy
The Entertainment Commercial Package Policy Product is a very unique product. It leverages existing lines of Businesses from the traditional Commercial Package Policy and expands those lines by offering proprietary Entertainment Rules.

One of the Lines of Businesses that is part of the Commercial Package Policy is the Business Auto Line. Usually, the Business Auto Line can be bought either as a monoline Policy or as a package policy with other lines of Businesses.

Second Phase Consulting was hired to implement the Entertainment Line of Business by a large Insurance carrier. The goal was to leverage their commercial package policy which had already been built in Insbridge by Second Phase previously. The Business Auto Line was part of the package policy lines that had been completed.

While implementing the Entertainment Business Auto Line, we had to consider various questions:

  1. Could the category structure of the Business Auto Line be leveraged and reused for the Entertainment Business Auto Line?
  2. Could both lines be built in the same program or was a separate program necessary?
  3. What items (Inputs, Outputs, Variables, etc.) needed to be created to fully implement the Entertainment Business Auto Line?

1. Category Structure
The Category structure is very important in Insbridge. it impacts the way the logic flows between rating objects at different category levels. It also impacts performance and should be thought about in terms of future maintenance. 3 clear reasons that made us keep the same category structure as the Business Auto Line:

  1. Half of the coverages supported in the Business Auto Line were going to stay identical (rating wise) to the Entertainment Business Auto Line. This means that all the inputs and outputs stayed the same. This allowed us to take the maximum advantage of what had been built.
  2. A fourth of the coverages were going to change rating, but would still need to have the same outputs as the coverage in the Business Auto Line. This means that for coverages with the same code, we would have 2 different rating structures, but should still be outputting the same premium. This gave us more clarity. Since we were going to be outputting the same generic premium at the same category level, we could be able to implement it with the existing category structure.
  3. Finally, the last fourth of the coverages were new coverages specific to entertainment. Those coverages did not require any rating from Insbridge and the premiums were to be entered in manually.
    The combination of the 3 items above gave us full confidence that we could reuse the same category structure.

2. New vs Existing Program
Since the rating solution needed to produce premiums for the Entertainment Line, we had to determine if a separate Program including only the Entertainment rating structure would be warranted. A program is a set of tables and instructions to be used for a specific entity such as a state, region, or product type. In our case, there was a risk in implementing both logical instructions in the same program as they could override each other. However, we decided to opt for a single program. There was one major reason that persuaded us, “maintenance”. Since both the Business Auto Line and the Entertainment Business Auto Line shared coverages and rating structure for specific coverages, creating a second program for Entertainment would have caused double maintenance work. The decision was easy to make as double maintenance is too risky once the Line was in production.

3. Implementation of the Entertainment New coverages and Rating

There were distinctive challenges implementing the entertainment requirements without creating new complication with the existing logic. Below is the way we decided to manage potential issues:

  1. We created a New flag for the Entertainment Line: A new input needed to be created to flag when an Entertainment policy was being rated. This new input was used for 2 different reasons:
    i. Create Entertainment Filter Rules at each level of category the filter needed to be used.
    ii. Create Non-Entertainment Filter Rules at each level of category level for items that should not execute for Entertainment policies.

Example of an Entertainment Filter Rule at the Class level.
pic-1

  1. We identified all new inputs that needed to be created specifically for the entertainment implementation. When naming these new Inputs, you want to assign a distinctive naming convention that will help identify Entertainment Specific inputs.
  2. We also created new Entertainment specific outputs and assigned a distinctive name that would help sort them out of the old ones.
  3. There were existing variables and algorithms that needed to be updated as we added new logic. We used the filter rules created at different category levels to make sure that only the logic pertaining to Entertainment would run when an Entertainment policy was being rated and conversely the Entertainment logic would not run when the quote was not for an Entertainment policy.
    In every project, it is difficult to assess the accuracy of one’s understanding of the rating requirements. This is why we also produced our version of the rating requirements in a format that could be accessible to the Business and useful for the rating design. During this project, we merged the Business Auto Line requirements and the Entertainment requirements to show how both instructions would be conducted sequentially and logically. Once, the Business partners signed off on these rating requirements document was ready, we had full confidence of our design.

Example of a generic requirement Document
pic-2
Note: This process may take several iterations of the rating requirements document and It is always important to keep track of the current version of the document.

Conclusion
The Entertainment industry faces unique perils. Implementing this unique rating structure can add a layer of complexity. However, these complexities can be significantly reduced by leveraging existing rating structures in the case of Commercial Package Policy and by using some of the tools Oracle Insbridge provides such as the filter rules. By using a single program, you can have more flexibility and control over the logic and avoid double program maintenance.

Comments

comments powered by Disqus