Since banking and insurance both financial services, it stands to reason that the information technology needs of each would be similar. They are in many ways. Both industries use much of the same hardware and much of the same system software. It’s at the point of application software that the differences between the two industries become very apparent.
The most graphic way to illustrate the difference is to lay a check next to an insurance policy. One is short, with few data elements, all in the same location on the document. The other is multiple pages of legal size paper with variable data elements showing up in the variety of places. This is emblematic of the true reason banking and insurance technology have so far proven resistant to integration. That true reason? Banking is generally regulated by the federal government while insurance is regulated by the 50 states.
Because banking is regulated nationally (I know there is some state regulation of banking but it is nothing to compare with insurance), banking technology and outsourcing can be scale games. If your application software can process a bank deposit in Missouri, then you can market in California and New York just as easily as in St. Louis. Insurance is a vastly different matter. Just because your software can issue an auto policy in Missouri does not mean it will work for Illinois or Kansas, never mind California or New York. The differences in auto insurance from state to state may be minor (e.g. length of notice time before being able to cancel a policy), but they add up and slow down the building up of scale for a service provider. Moreover, we’ve just been talking about auto insurance. Now figure you have to do the same thing for Homeowners policies. And then there are Businessowners policies. And we haven’t even mentioned life and health insurance. Every line of business requires accommodation to 50 different state insurance departments. Now go back and compare that to processing a check or a debit card transaction. It’s the epitome of complexity versus simplicity.
The fifty-state regulatory burden, however, is not the only way that insurance is a more complex business to automate than banking. Think of it this way: The insurance industry can be divided into three different sectors: Property and Casualty, Life and Annuities, and Health. Moreover, most insurance companies outsource their distribution so that agents and brokers are distinct entities from the companies that write the insurance. Therefore, there are six different permutations and a technology service provider usually has to choose which of those sectors to serve – at least in the beginning – because the software for one will not do much good for the other five, without significant modification. The only comparable issue in banking is the difference between commercial banks and credit unions. That is, the software for the one generally will not work in the work, without significant modification.
None of this is to say that automation in banking is easy, or that very sophisticated and complex problems don’t exist there. Of course they do. Having worked in that arena, I know firsthand how challenging it can be. My point here is that insurance has some additional mountains to climb because of its regulatory environment in the U.S. If you wanted to identify an even deeper root cause, consider the product itself and ask, “How much do most folks understand about their bank accounts?” and then ask “How much do most folks understand about their insurance?”
Fiserv and Jack Henry didn’t throw in the towel because they’re weak, dumb, or incompetent. They are the opposite of all those things. They threw in the towel because insurance and banking are different enough to require separate focus.
