Insurance Systems : What makes them unique?

I call myself as an "Insurance Technology Professional" and colleagues in the IT industry do tend to ask me as to what is so unique about Insurance Technology. Lets see if I can answer that question.

A little bit of history :
At one point (in the 60's , 70's) Insurance companies were the most savvy IT users. Similar to the world of Capital Markets today. These carriers purchased large Mainframe systems to maintain their policies. The sad part is that somewhere along the line they decided not to modernize their systems and even now a lot of the modernization they are doing keeps the Mainframe based backend while building smart front ends and somehow addressing relation processing needs using some Mainframe modernization technology. They never embraced Straight through processing like the Amazons or etrade's of the world.

Having set the context for the discussion , Here is how I characterize Insurance based systems :
1. Batch Job based Systems
The batch job oriented nature of Insurance Systems is as a result two reasons:
a) The Mainframe oriented nature of IT systems in the Insurance Industry that has led to batch processing to be a very core aspect of design.
b) A subscription based business model that triggers several processes based on date conditions.

2. Systems that have unique challenges related to handling of Date's.
The insurance product is a time sensitive product. The Effective Date of a policy , Effective Date of Govt related rate changes , age of customers etc can have significant impact on the premiums for the customers. Date related nuances combined with the batch based environment has a massive impact to the Software Development Life Cycle (SDLC) and the QA teams are affected the most by this uniqueness. The QA teams really have to think out of the box to perform efficient testing.

3. Generally a Legacy Mainframe based core business processing environment
This point has already been mentioned above but still am important point to have its own bullet.

4. Agent based environment
Carriers still sell a major junk of polices using agents. With an Agent driven environment you get into the need of standardizing your interfaces for communication and run into B2B situations. As a result of this there is a lot of push in the industry to move to standards like ACORD , SOA and webservices for integration.

What is a Business Rule - Part 2 Three Cases

Following my earlier blog entry regarding what is a business rule. I thought about elaborating this further by describing three cases of rule development.

1. Case 1 : Sure shot rule

Consider the following requirement:

The Work Allocation of the claims file happens based on the following set of rules.

If the type of Policy is a personal auto with no driver on the policy below 25 years of age and the claim amount if less then $1000 the allocate the claim to a claims rep

If the claim amount > $10,000 allocate the claim file to a supervisor

If the insured vehicle was parked in open parking lot allocate the claim to claims rep and notifying the supervisor. The claim has to be approved by the supervisor

………………
………………


The above set of rules describes allocation of a claims file to a role in the claims organization of the insurance carrier. This is a clearly a business rule set that needs to be in the BRMS tool. These are a set of rules that the business is interested in knowing about, viewing and potentially maintaining. This is a classic case of why someone purchases a rule engine.


2. Case 2 : Grey Area

Consider the following two requirements
a) Verify that the claim number or the policy number entered by the user on the screen is a valid number. If the number is valid then create a Claims file in the system with the information provided. If the claim is invalid then notify the customer to re-enter with a valid number

b) If a customer has as an excluded driver on the policy then shown the driver exclusion screen.

Requirement 2a) above is really business process requirement and describes how the system needs to be implemented. This is a scenario where some business users of the carriers organization might be very interested in knowing about it while others might not care about it at all saying that all that they care is that the claims file should be created and going to detail of error conditions in business process is not their problem.

The rule text could potentially be something like the following if we choose to write this as a rule in BRMS tool.

If
The claim number entered is “valid”
Then
Create a new Claims File
Else
Re-Enter the claim



Case 2b) is a screen navigation rule, generally implemented by the technologies used in developing the screens – example Structs web framework OR Flex based UI tool. But I have also seen cases (in large P&C carriers) where the architect has chosen to implement such rules in the BRMS tool.

In my opinion , these decision’s really boil down to the guidelines I had described in my earlier blog. There is frankly no right or wrong answer in this case. It is joint decision of the organization.


3. Case 3: Not really a business rule

Consider the following functional requirements
a) The Date entered by the user should be in the format dd/mm/yyyy
b) If the premium displayed to customer is less then the current premium paid then display the premium in Bold Green with blinking text.

These are clearly not business rules and should not be maintained in BRMS tool.

What is a Business Rule

On a rules project a few design decisions I see teams struggle are the following:

1. Is this rule a valid candidate to write in the Rule Engine?
2. The rule is never going to change , what is the point of writing this in the rule engine
3. Is every "if then else" in the system a business rules. Are things like page navigation rules , workflow rule candidates?

You have probabaly heard a theoretical definition of what is a business rule. While these definitions serve well for a new comer to this space who is trying to understand the concept , it does not necessary address the questions I have highligthed above. In the context of building a system a lot of other things also need to be considered.

I have tried to articulate my definition around this subject below.

The basic guideline I have been using to decide if the rule is a candidate for the BRMS tool are as follows:

1. Is this rule something that is core to the way the Enterprise operations works ? What this means is : Is the business interested in
• being aware of this rule
• viewing it and maintaining it
• Possibly enhancing this in the future


2. Identify if the rule is a candidate for the Rule Engine or is this rule better addressed as part of a product already in the solution (example : Struts Framework for GUI Navigation rules OR Filenet addressing BPM)

You also need to answer the question of how is the team viewing the BRMS tool. Is the BRMS tool a part of the solution or is it the solution itself ? This is an important question to ask as the answer will decide the granuality at which you want to use the rules engine in your solution.