Commercial general liability (CGL) is a type of insurance policy that provides coverage to a business for bodily injury, personal injury and property damage caused by the business’ operations, products, or injury that occurs on the business’ premises. It is a very popular coverage for businesses and as such many Insurance Carriers offer this coverage. If you are a carrier wanting to provide this coverage or are porting over a legacy CGL product into a new system this can seem daunting considering all the data needed for rating CGL.
Insbridge is a best-of-breed enterprise rating engine provided by Oracle. It enables customers to quickly and easily create and deploy rating and rules programs using a codeless UI.
Second Phase was hired by a large (Tier 1) Insurance Carrier to port a legacy CGL product into Oracle Insurance Insbridge Enterprise Rating (Insbridge). We had to determine what was the best way to build a CGL rating program in Insbridge given the following high-level requirements (which are probably common to most insurance carriers):
• Need to produce Non-Discretionary Premium, Technical Premium (Benchmark), and Actual Premium for Base Coverages (Premises/Operations, Products).
• Need to produce premium for Additional Coverages (e.g. Product Withdrawal, Stop Gap coverage, etc.).
• Need to be able to support Experience Rating.
• Need to be able to support Schedule Rating.
• Need to be able to support Composite Rating.
• Need to be able to support versioning of logic by State.
Single vs Multiple Rating Programs
Since the rating solution needed to produce Non-Discretionary, Technical, and Actual premiums for the Base Coverages we had to determine if we needed to build separate Insbridge programs for these. After a detailed review of the three kinds of premiums, it was determined that Technical and Actual Premiums were calculated by simply applying a few additional factors to the Non-Discretionary Premium. As such, it was determined it was best to include the premiums for all three in one rating program. We built separate algorithms for Non-Discretionary, Technical, and Actual premiums.
We also had to determine if Experience Rating should be built separately from the rest of the rating logic. This was a more difficult decision but due to the fact that this logic did not need to be reused for other Lines of Business and there would be a small rating performance hit if we separated it (for Program to Program callout) we decided to not separate this out into its own program. Filtering was used to suppress this logic when not needed.
Category structure is extremely important in Insbridge as it determines relationships between rating objects and can dramatically effect rating performance as well as program maintenance. In addition to the requirements above we were also told that all premiums had to be calculated at the Class level (lowest granular level) and then rolled up to the Coverage, Location, State, and Policy levels. Another requirement was that the Additional Coverages had to be attached to the Headquarter location for reporting purposes. The carrier also wanted to be able to calculate 1 or more composite rates for certain groups of classes. Given these requirements we determined the best category structure for CGL was the following:
Policy/GL/State/Location/Additional Coverage/AC Class
The Coverage and Class categories were used for rating the base coverages. Coverage category and associated Result Variables were generically named as the calculation structure for the base coverages were very similar and this allowed us to reuse all logic and tables at those levels.
The Additional Coverage category and associated Result Variables were also generically named as there was some similarity between coverages. This also allowed us to easily sum up all the Additional Coverages on the policy. This also will allow for easier maintenance going forward if new Additional Coverages are added as new inputs and outputs will not be needed in most cases. Another option we considered was just reusing the Coverage category for the Additional Coverages. However, we decided there should be clearer delineation between these 2 groups of coverages so separate categories were created. We used filter rules to suppress logic when it was not applicable.
Composite Group category was added to allow us to sum up class premiums related to a particular Composite Group. We used unique Id’s provided at the Composite Group and Class level to accomplish this.
Prior Term and Claim categories were used for Experience Rating and for Technical Pricing. 5 Prior Terms were provided each with 0 or more Claims.
Schedule Rating was mainly handled by Policy Admin system as the values available to choose were not calculated but were agent discretion within a range. So, this just ended up being an input at the State level.
Performance testing was performed on the Insbridge Rating Engine after the CGL program was completed and the average rate time per policy was less than 1 second.
Versioning by State
CGL policies can cover a company's business operations that occur in multiple locations in various states. Each states rates are different and can change on different effective dates. We had to decide if it was best to build 50 separate programs or a single program. After completing the Business Requirements Document (BRD) we could see that the rating logic was almost the same across all states. It was just the rating factors, such as Loss Costs, that changed. Since it was just the rate tables that changed, we built a single program that used state and effective date as criteria in the various rate tables. When doing rate changes, we received the state changes in groups. This allowed us to implement a group of states in a new version of the CGL program with the version selection date being the earliest effective date within the group of states. The rate tables within the new version were updated using the effective dates for each state. See diagram below to illustrate relationship.
There were in depth discussions with the Policy Admin team regarding best category structure to use to ease integration with the rating engine. Based on those original discussions, the Additional Coverage category was originally a child of the GL category since those coverages were considered Policy or Line level coverages. However, we later discovered that a downstream system needed these coverages to be attached to a Headquarter location which caused some rework. We not only need to consider how the rating data will be shown on the rating and quoting screen we also need to consider how the rating results will be used and stored in other applications in the entire insurance workflow.
Building a new CGL program can appear challenging on the surface. However, using Insbridge with the category structure and table setup noted above allowed us to easily construct a program that tackled common concepts related CGL, allowed for ease of maintenance, as well as provide excellent rating performance.