Realtime Good, Batch Bad

Four Legs Good:

“Four legs good, two legs bad” is the political slogan around which the farmyard creatures in George Orwell’s “Animal Farm” rally and revolt.  The slogan is of course famously reversed later in the book when following their successful revolution the animals find themselves working for new, non-human masters who come to imitate their predecessors.

Sloganeering, political or otherwise, tends to simplify issues and polarize positions. We are given to sloganeering of our own.  One of my favorites is:  Real time good, batch bad.  You won’t necessarily hear this explicitly stated but it is there in much of our technology thinking.  The problem, as with any other slogan, is not that it is right or wrong (it is both) but that it is a binary formulation of a non-binary issue.

Unlike stock trading or airline reservations, insurance is not a real time business.  In the area of business acquisition - quoting, binding and issuance - real time processing is highly desirable and can create competitive advantage.  For endorsement processing real time is a nice to have.  For renewal processing real time is unnecessary and even inappropriate.

In insurance we have two basic types of transactions: event driven and date driven.  Event driven transactions tend to be best executed in real time.  They are triggered by events in the real world – the purchase of a car, a kitchen fire – and have the characteristic of requiring something to be done “now”.  The ability to respond to event driven transactions in real time enhances customer service and is a good thing.  By contrast, date driven transactions don’t happen “now”, they happen “then”.  Then being some arbitrary future date based on choices instanciated in rules.  In most of these later instances – a policy renewal, the generation of a billing statement, the cancellation of a policy for non-payment – batch processing is probably a better solution than real time processing.  Batch processing is well suited to situations where a large volume of records are processed at the same time and similar transactions are triggered by automated rules sets.

Big Yellow Taxi:

Let’s consider the humble unattended renewal, an important transaction in the policy lifecycle.  The vast majority of P&C policies can, should be and are renewed automatically in batch cycles.  The basic mechanism is simple:  each night (most batch processing is restricted to nighttime for operational reasons) a daemon process kicks of a search of the database of records which represents the in-force book of business.  The daemon looks for policies with an expiration date within a given time horizon (which varies based on line of business and regulation).  When it finds such a policy, assuming there are no “underwriting flags” to be dealt with by a human actor, the daemon creates a new version of the policy which represents the upcoming policy term.  This process is a perfect application for batch processing and is a vital part of the business operation.  Billing systems are even more batch appropriate.  If you take out the initial setup and exception condition processing billing cycles are essentially date driven batch cycles.  Most everything that happens in billing happens because it is time for it to happen – send a statement, send a reminder, send a cancellation notice.  Claims administration it should be noted is more event driven than policy and billing but still relies on batch processing for periodic check generation, accounting reconciliation and various reminders and follow ups based on predefined claim workflows .

And yet most of the RFPs and RFIs for core insurance application systems that I see pay little attention to the issue of batch processing.  After all, its not flashy, its not new and for the young buck Java and .Net UI guys its just not very interesting.  Batch is associated with the mainframe, it is old and ugly and bad.  Further, the business folks tend to focus on what they can see and touch, like the web UI and the rules configurator.  So batch just doesn’t get the attention it deserves; until of course it becomes conspicuous by its absence. I have unfortunately witnessed situations where carriers have purchased new insurance administration systems only to find that the new system inadequately supports the business’ batch processing requirements. Batch processing is like Joni Mitchell’s Big Yellow Taxi: “Don’t it always seem to go, That you don't know what you've got, Till it's gone”. 

Comments

[Andy Labrot]

Completely agree that batch, especially in Policy Processing is a key, yet unheralded aspect of any successful system. If we look at the processing that takes place during a policy's effective term, anywhere from 75-80% of all processing done to a policy is in batch. This includes billing, automated underwriting reviews and the renewal process which may start 90 days after policy issuance. It is also imperative that batch perform well, given the volumes in some carriers, as they may have restricted windows to run batch due to interfacing system requirements and underlying technologies.

The key to ensuring that the same rules are applied in batch as are applied during any online transaction (e.g. endorsement, billing adjustments etc.) is to adopt and implement a services approach that allows for the same rules and software to be executed from either batch or on-line. This then eliminates duplication of maintenance, ensures regulatory and jurisdictional changes can be made in one place as well as any product or rating modifications.

[James Taylor]

Quite right. It is particularly disconcerting to see batch ignored when the rules and decisions need to be consistent between batch and real-time. The rules used to decide about renewal are also used in new policy writing. Failure to consider both will result in poor reuse of rules and thus compliance issues.
Part of the problem could also be that people don't believe they can make their batch systems smart enough and so they think they must replace them. Nothing could be further from the truth. Check out my forthcoming book Smart (Enough) Systems (http://www.smartenoughsystems.com).
JT
http://www.edmblog.com