Insurers Grapple with Temporal Issues

“Max,” a business consultant and software engineer was recently flown to Nevada to upgrade one of his clients’ databases. Shortly before he completed the job, he fell violently ill and had to go to a hospital. He recovered, finished the job and then left Nevada, which is when his real problems started. The hospital kept calling him and sending him bills, which he would have only been too happy to pay, but each time the hospital called or faxed or emailed him, the amount he owed them changed. The amount he owed would go up and then down and then up again without reason, as far as Max could tell. Eventually, he paid the hospital what they told him was the entire amount he owed, but he still got letters telling him that he owed them money, that he hadn’t paid the entire amount.

In the insurance industry time-based data is especially important as an insurance contract is a relationship over time.

A big part of the hospital’s problem was the way its software kept track of time or, rather, didn’t keep track of time. This is a big problem in the insurance industry, where managing time-based data is especially important – an insurance contract is a relationship over time.

Most insurance companies get around this problem manually. Insight Decision Solutions’ software, specifically designed for the insurance industry, is built on data warehouse technology, contains a full range of analytic tools (management information, financial analysis, sales and operations) and, most important, a unique temporal model that insures that their customers, regulators and actuaries get the right information.

Neil Lund, senior vice president and chief actuary of Universal American Financial Corp., says the solution improved the firm’s functionality in a couple of ways.

“First is through management reporting. In our management reporting areas we are now able to examine claims information, persistency and sales information almost instantaneously and be able to slice and dice and take that down to a very detailed level, if needed and when needed,” he says. “And the second point is it has allowed us to change our relations with the regulators. We are able to dive deeply on questions that regulators have. More thoroughly answer their questions. And also provide them ancillary information.”

Considering that most software engineers can use a clock and a calendar, even if they can’t always meet a deadline, it is odd to find that most software handles time so badly. The hospital’s software was built to answer questions such as, “What does Max owe us?” It was not built to answer questions such as, “What did we think Max owed us the last time we talked?” These questions are the same if and only if we never change our mind. Unfortunately, even in relatively simple cases, such as a single bill, these questions are not always the same. In more complex cases, such as where someone lives, the facts can change, stay stable for a while and then change rapidly again and again.

A temporal database is a relational database with a built-in temporal model, a model designed to handle changes concerning time. In fact, Insight Decision’s perspective is that in insurance, simply having a time dimension will not necessarily support temporal queries. The firm identifies four types of temporal queries in insurance: A state duration query, for example, would look for the number of policies of a particular type that have been in force for a particular duration. A temporal selection query might look for the number of policies of a particular type that were active at a particular time. A transition detection query would look at policies that have changes, such as from premium paying to non-premium paying, during a particular year or time period. Finally, there is a multi-state identification query, which could, for example, find policies disabled in 1999 that have been disabled in the past and recovered. Insight Decision can handle all four of these queries.

Back to the Max example, “temporal model” sounds like it means that each observation has a time stamp. But most people who have thought about this issue believe that each observation must have four date-time attributes. Max walked into the hospital on, say, February 2, 2005 at 8pm. He walked out of the hospital on February 2, 2005 at 11pm. His bill was $800. The first two attributes are the start time and end time of his visit and bill. These attributes are called valid-time start-time and valid-time end-time. These times represent when the observation was represented in the real world. In Max’s case, the database had only one time attribute which recorded the date as February 2, 2005. This wouldn’t have been a problem except each time the hospital changed the amount he owed them, they overwrote the amount they last recorded. To make this problem go away, most experts on temporal databases believed the hospital needed a second set of time attributes, transaction-time start-time and end-time. Transaction-time records the time span during which the system’s user believes an observation is true.

Coping with Regulators
More industries have this problem than do not have it, typically in any form of CRM analysis. In insurance, relationships are complex, changing and, in some products, the time periods need to be measured in decades. The insurance industry is heavily regulated. For many lines of business, insurance companies have to request permission from state agencies before they can introduce new products or change rates on old ones. Before these agencies will give their permission, they want to see statistical reports of various kinds from the companies. Government agencies being run by people and people being what they are, the agencies will often request modifications or additional reports. If a report lacked a breakdown by age or sex or race, for example, the agency may ask for just such a breakdown. Every day that it takes the insurance company to prepare such a report costs them money. Less obviously, every day it takes the insurance company to prepare such a report, the database changes more. Every moment it takes to prepare such a report, it becomes more difficult to reconcile with the original.

Insurance companies have ways of producing such reports, of course–typically quite clumsy, time consuming and, worst of all, approximate. The fact that the numbers on the subsequent reports only approximates the numbers on the original reports may well produce more questions from the regulations and more reports and more delays.

Moving to Insight Decision Solutions’ temporal database means that subsequent reports can be produced faster and that there are no reconciliation problems. The regulators get the reports they want, reports they can now trust – almost instantaneously – and the insurance companies get to adjust their rates quickly.

Recall that Max’s problem with his hospital was with a single data point. But insurance companies and insurance regulators rarely work with single data points; they work with statistics, where the problems are greater by orders of magnitude. In the case of the additional breakdown above, it is a matter of making sure that the statistics are based on what was known at a specific time. More complex cases are typical. For example, insurance companies naturally want to understand the sources of their earnings. That means explaining earnings in terms of events and strategies.

Life Insurance Challenges
In the life insurance industry, this is a particularly nasty problem. A life insurance company receives premiums from their customers and then has to set up reserves to cover future payments to the beneficiaries. When someone dies, the benefit paid is offset by the reserve held on that policy; if someone surrenders their policy, reserves are released. A life insurance company’s actuaries determine the reserves needed to cover expected future liabilities. If more people die, lapse, than expected, then reserves will change. Unfortunately, reserve changes can swamp other sources of earnings.

Most life insurance companies use software that relies on brute force calculations, internal components of the reserves and, much worse, temporal data that the users have to add. As a result, their reports can only explain earnings on an aggregate basis and, even then, have large balancing items that cannot be explained. This is the financial equivalent of ‘Here be Dragons!’ These balancing items typically come from adjustments made in the general ledger, administration or computational errors, and flaws in the reserve methodology. But knowing that doesn’t help.

In contrast, Insight Decision Solutions uses a database architecture that centers on customers, rather than transactions, which allows it to end-run the unsolved problems that inhibit temporal database architectures. This architecture allows them to capture events and policy changes when the data is entered. Microsoft’s Business Intelligence stack, including SQL Server 2005, PerformancePoint 2007, Excel Services and the latest component of PerformancePoint, is the backbone of Insight Decision Solutions’ system. Changes to a contract or even an administrative error can impact reserves and may have a change event to explain it. Insurance executives now not only have a report; they have information they can use to plan.

Technorati