Commercial Auto Insurance can be used to help pay to repair physical Damage to vehicles driven for business purposes if they are damaged by theft, weather events, or collisions. It can cover lawsuit costs associated with accidents, such as medical expenses and legal fees.
A Commercial Auto Insurance policy usually offers four major types of protection:
• Auto Liability coverage pays for property damage or bodily injury caused.
• Medical Payment coverage covers medical bills if you or your passenger are injured in a car crash.
• Physical Damage and Collision Coverage which pays for repairs if the vehicle is damaged by something other than a car accident. This may include theft, vandalism, or weather-related events.
• Uninsured and Underinsured motorist coverage covers damage to your car or bodily injuries suffered if someone who doesn’t have insurance (or not a particular coverage) hits the vehicle.
In addition to the above major types of coverages, some carriers also offer Hired and non-Owned Auto insurance in case your business is held liable for accidents that happen during company errands.
We were assigned to a Commercial Auto project that offered all four major types of coverages as well as Hired Auto Coverages, Non-Owned Coverages, and Garage Keepers Insurance. The carrier offered a nationwide list of coverages. We had had to determine the best way to build the rating program given the following high-level requirements:
Need to produce Actual Premium for annual and Term Premium for all vehicle coverages offered.
Need to produce Premium for all state level coverages
Need to produce State Deviations rating by Jurisdiction
Implement State specific coverages
Implement Manually rated coverages
Implement Experience Modification Rules
Before implementing any coverage, one has to understand the flow between rating objects at different category levels. Then, a category structure that works with that flow has to be set up. It is also important to remember that performance can also be impacted based on the category structure. It is therefore very important to have a category structure that works very efficiently. We were told that there were going to be 3 levels at which coverages needed to produce the premium at.
- State Level: There were state level coverages with multiple occurrences at the Jurisdiction level (i.e. State Level).
- Location Level: We were told that a Jurisdiction could have multiple locations and that there were coverages that could be added multiple times for each location.
- Vehicle Level: Multiple vehicles could be added for each location. Additionally, there needed to be vehicle coverages for each vehicle included on a specific policy.
In addition to the information above, we were told that we needed to build eligibility and calculation rules for the Experience Modification factor and it’s use in the determination of the different types of premiums used for actuarial purposes. In order to do so, we were told that we needed information from prior term claims and losses. Given these requirements, we determined the best category structure for the Commercial Auto Line was the following:
Prior Term and Claim categories were used for Experience eligibility and experience Rating. 5 Prior Terms were provided each with 0 or more Claims.
Schedule Rating was mainly handled by Policy Admin system. The values available to choose were not calculated by Insbridge but were entered at the user’s discretion within a range. So, this just ended up being an input.
- Multiple Programs and Sequencing
One of the toughest decisions we had to make was to decide whether we could implement all the necessary calculations in a single program or if we had to separate programs.
First, we had to determine if the Experience Rating should be built separately from the rest of the rating logic. We were told that there needed to be 2 rate passes in order to execute the experience rating. We had to execute a first-rate pass with an experience modification factor of “1” and produce the basic limit premium. Then, we were supposed to make an experience rating eligibility check with specific rules and apply the experience the modification factor if it was eligible. Finally, we had to make a second-rate pass where we generated new premiums with the new experience modification factor calculated during the Experience rating. This made us realize that we had to have at least 2 separate programs. One that would execute the rating logic for the first and the second pass and another one that would be used to execute the experience rating logic.
Secondly, we had to decide if implementing the rating logic in one program was the right decision. The requirements from the Business showed that there were countrywide requirements that applied to all states. However, some states had state deviations from those countrywide requirements. State deviation included different rate tables, additional factors applied, different logic, etc. Additionally, some states had state specific coverages, which were not included in the countrywide requirements. Since we had almost as many state deviation and state specific requirements as countrywide requirements, we decide to separate the Countrywide program and the state specific programs. The split of the programs gave us more pros than cons. One the pro side, each program was easier to read and comprehend. It was easier to test and fix bugs. It also provided better versioning capabilities. For maintenance purposes, it is important to be able to update rating in a timely manner. Having one big program would have caused multiple issues going forward. For example, if a countrywide rate change happened on the first week of March, and a state specific change happened in the second week, what would be the best course of action? Deploying both changes at the same time? Deploying the first one and immediately deploy the second one? By separating the programs, we were able to deploy each program independently and more efficiently.
We also had to create an additional program for additional rules and coverages. This program would run after all the state rating programs had run. The purpose of this program was to execute rules connected to all states and calculate premiums for coverages with countrywide requirements but had to run after all other premiums had been calculated. It was the most complex program of all as it was aggregating all the data from all the other programs.
On the con side, there would be a small rating performance hit if we separated the programs (for Program to Program callout). After looking at both advantages and disadvantages, we decided to separate the programs. The hit in rating performance was very small. For example, we tested a scenario with more than 700+ vehicles with multiple locations and 115 claims and produced a rating time of 3 seconds.
See diagram below to illustrate relationship between programs.
Legend: CW = Countrywide || Addl Rules and Cov = Additional Rules and Coverages || EMOD = Experience Modifier
As we can see there is a controller program which was used to manage the program to program callout and create the flow of the rating.
Building a commercial Auto Rating program (or programs) may appear challenging. However, these complexities were reduced once we understood the overall design of the rating. First, we had to understand what was the best category structure to be used. Secondly, we had to determine if we could implement the rating in one program. Once we saw it was not possible, we went back on the drawing board and created the most understandable and maintenance-friendly design that would also be performing efficiently. Using Insbridge, we were able to construct the sequencing of the program to program callout noted above and provide ease of maintenance as well as excellent rating performance.