In a previous post, I've explained that I have an interest in rating engines. In fact, I have more than an interest -- I have an opinion. And that opinion is: If you plan on writing code to calculate an insurance premium, it's often best to write a custom rating engine.

But before I can expound on this, I need to describe what a rating engine is. I'll start by describing the problem that a rating engine is supposed to solve. Insurance companies - more specifically, the actuaries - capture a lot of knowledge that is used to calculate an insurance premium. That knowledge has a few annoying characteristics: It is complex, it is large, and it subject to periodic, if not frequent, change.

You could just write source code to calculate an insurance premium based on that actuarial knowledge. But your code would have a few annoying characteristics: It would be complex, it would be large, and it would be subject to periodic, if not frequent, change. Or, if you were diligent enough to prevent the first two characteristics, your code would accrue another characteristic: It would be very costly.

So a rating engine should incorporate all of that actuarial knowledge to calculate a premium, but be neither too large nor too complex. It should deal with change gracefully. But still, what exactly does a rating engine do?

A rating engine has one primary function and a few supporting functions. Expressed as a use case, the primary function is to Calculate Premium for a proposed set of coverages.

But in order to calculate that premium, the user (let's call them Rate Consumers) needs to know how to assemble a valid set of proposed coverages. Insurance companies have lots of dependencies and constraints that describe what coverages and options can go together. This aspect of insurance - product design - involves capturing the knowledge of the product designer. The engine needs to expose this knowledge to the Rate Consumer in some way. We'll call this use case Get Coverage Catalog.

It only stands to reason that when a Rate Consumer asks for a premium, the engine should check whether the proposed coverages are valid according to the coverage catalog. This functionality is really part of the Calculate Premium use case, but to draw attention to it, we'll put it in its own use case, Validate Proposed Coverage.

Finally, there needs to be some way to transform the knowledge that exists in the heads of the actuaries and product designers into a form the rating engine can use. The actor responsible for doing this is a Rate Administrator. We'll call this use case Manage Coverage Catalog and Rates.