Implementing rating for a new line of business

If you use the pattern of the built-in default rating engine, your main task is to modify the built-in rating engine classes or write your own one based on AbstractRatingEngine. The plugin contains the code that actually instantiates the rating engine objects. If you make your own rating engine subclasses, be sure to modify the rating plugin to create the correct rating engine subclass based on the line of business. This topic goes into further detail about what cost data objects and how to subclass AbstractRatingEngine.

The easiest approach is to use the built-in structure of CostData subclasses rather than directly producing Cost entities.

Your rating code can split, merge, prorate, and sum these CostData objects until your rating calculations finish. At that point, a built-in method of the AbstractRatingEngine class takes the list of CostData objects that each rating engine produces and compares them with what is in the database. This code alters the Cost entity instances in the database for this line of business. This code may do some combination of adding, modifying, splitting, and removing cost entity instances as appropriate. This is difficult code to write safely, and hence the benefit in abstracting the costs into the cost data objects.

Most built-in rating engine subclasses (although not all) implement rating using the following algorithm, implemented in part by the AbstractRatingEngine class.

  1. Find all dates on which anything changes in the branch. In other words, find any entity that starts or ends in effective time. The AbstractRatingEngine class constructor implements this and sets the internal instance variable _effectiveDates. The method rateSlice uses this information variable’s contents.
  2. At each of those dates, traverse down the tree (graph). As the code traverses down the tree, it produces costs for everything that can be rated in slice mode. Slice mode changes includes the common things like personal auto coverage and building costs. The resulting costs are not prorated and span from the slice date to the next slice date. The AbstractRatingEngine class method rateSlice implements this.
  3. The rating engine rates each slice-mode cost. The AbstractRatingEngine class method rateSlice implements this. Your rating engine can override this method to rate each slice.
  4. The rating engine merges back together any costs that are adjacent in effective time and which are equivalent, which means they have the same rates. There are methods in the base class AbstractRatingEngine that perform this task.
  5. Your rating engine prorates costs that do not yet have an actual amount in the ActualAmount property.
  6. Rate window-mode costs (like discounts and taxes) that might depend on sums of the prior costs.
  7. Take the resulting set of cost data objects and adjust Cost rows in the database to match them.

This approach is used by all built-in rating engines other than the built-in workers’ compensation rating engine.

You could describe this approach as rating down each slice and then merging costs back together. Think of this as the down-each-slice-and-merge approach. A theoretical alternative is to find all effective-dated split dates, or at least all relevant splits (this would be harder to determine). Next, rate across each object, such as a vehicle or coverage, calculating rates at each relevant point and then splitting off new CostData rows when the rates change. Such an approach avoids the need to remerge costs back together. However, it is more difficult to write easy-to-improve and easy-to-maintain code using this approach. As a result, PolicyCenter takes the down-each-slice-and-merge approach instead of the across-each-object-and-split-on-differences approach.

The logic for rating each particular type of object tends to share a common pattern. For rate-scalable types, the computation usually looks like the following operations.

  1. Set the base rate to the result of some lookup. The lookup result might be based on coverage terms, date, state.
  2. Set the adjusted rate to the base rate multiplied by various other factors. The other factors might include the underwriting company, driver ages, vehicle cost, and modifiers.
  3. Set the term amount to the adjusted rate multiplied by the basis. Typically, the basis is 1.
  4. Set the amount to the value of the following formula.
    (the_term_amount) * (number_of_days_this_cost_spans / number_of_days_the_rates_are_for)

    The amount computation happens during the proration phase mentioned above, not during the actual initial rating. For basis-scalable costs, the algorithm is similar. However, the basis is generally not 1 and the rating engine simply sets the amount to the term amount rather than prorated based on time.

See also