Litmus Tests

Whenever the nation considers the appointment of a new Supreme Court justice, which has happened twice in recent times, the notion of "litmus test issues" arises.  Litmus tests are those key issues which define the candidate for many people.  In the context of the Supreme Court these are weighty subjects like abortion and racial set asides.

In our own parochial world of insurance software something similar operates when carriers are assessing core insurance applications. There are litmus test requirements which act as proxies for the general maturity and completeness of the system being considered. The reasoning seems to go like this – if the system can do that function then it probably can (must be able) to do a whole raft of other lower level functions. Like the cherry at the top of a cake, the existence of the cherry presupposes the existence of the cake.

So what are these requirements and why are they important? Lets consider one each from the "big three" core applications.

Policy Administration: OOS

The dreaded out of sequence endorsement is the bane of many a poor Underwriting Tech's life. An OOS occurs when endorsements are applied in an incorrect time sequence. So for example I buy a new car on May 1st, then add my daughter to the same policy a month later, but the carrier adds my daughter without ever applying the new vehicle (happens all the time for various reasons). When the new vehicle transaction finally comes to light a series of one-at-a-time transactions is required to unwind the premium earning and transaction history of the policy back to the effective date of my new car endorsement and then wind the clock forward again in a series of careful steps that correctly reflect transaction history and the effect of those transactions on premium earnings. In most legacy environments only one transaction can be applied to a policy in any day, making what should be one change a week long process.

The solution of course is a system which supports the ability to identify and execute all the required transactions and to undertake them in one go. Not a trivial task. OOS is the top of the transactional food chain in the PAS world and indicates a higher level of sophistication on the part of the vendor and the system.

Claims: Split Assignment

Except for the simplest first party loss, claims usually invoke multiple coverages. A single loss event may consist of a number of different "features" or "coverages", for example where an auto accident, which is my fault, involves damage to my car, damage to a third party's car and bodily injury to the other driver. In this example it is common for a claims department to split the assignment of different parts of the claim to different adjusters based on their expertise. It is likely that the bodily injury will not be handled by the same adjuster who takes care of the collision damage on my car. But many legacy claims systems do not support the ability to have multiple adjusters work different parts of the same claim. This leads to unnatural acts of numbering and cross referencing in order to be able to have the claim handled appropriately while keeping track of what is in reality one loss event.

Billing: Account Bill

How many of you get separate bills for each of your insurance policies? I suspect the answer is many of you. The notion of an account bill is simple enough: you get one invoice which itemizes the separate policies you have and gives you a total cost for coverage for that time period. Account billing cuts down on paper, print and postage. It also minimizes customer irritation (assuming it is well done) and promotes customer retention (which is a major profit driver for P&C carriers). So, account bill is a good thing all round, but it is not easy to do. Like so many other billing concepts account bill is reasonably straight forward until it has to cope with exception conditions such as non-pay, late pay or under-payment. For example if I have a homeowners policy and I don't pay the bill (eventually) that policy will cancel; if I have an account bill and I don't pay or I underpay should the system allocate scarce finances equally or proportionally across the component policies? Should they all cancel at the same time? Should one policy be kept in force at the expense of another?

Again account billing is a more sophisticated capability than mono-line only functionality and is not available in all legacy environments.

Look for the Cherry, Check for the Cake:

So, in assessing core administration software it is perfectly appropriate to give some added focus to the litmus test requirements of interest to your organization. But there are a couple of watch outs. First the examples used here are not the only litmus tests, and may or may not be litmus test requirements for your organization. Second, as we noted earlier, a litmus test requirement is like a cherry on the top of a cake. So remember to check the cake as well.

Comments

[insurance administration software]

I recently came across your blog and have been reading about insurance administration software. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.