Rotten to the core

Celent’s Bart Narter examines the state of core banking systems in North America.

Core banking systems at many North American banks are getting long in the tooth. Developed in the 1970s and 1980s using traditional mainframe technology, COBOL, assembly and other ‘write only’ languages, many banks have remained with these systems. But why is this the case? And should banks be moving to a modern architecture or remaining with their tried and true systems?

When we talk about core banking systems, we are referring to those back-end systems that do the day-to-day transaction processing, statement generation and reporting for the bank. These systems include the direct deposit account (DDA), personal lending, commercial lending, mortgage, credit card, payments, etc. These don’t include teller and platform systems that might be core to the banks’ function, but are front-ends rather than back-end transaction processors.

Like a fine wine or a bad apple?
These systems tend to be written in COBOL, perhaps with a bit of assembler thrown in to optimize batch runs. They run in batch mode, so that transactions are posted nightly. They have been running at the bank for 20 or 30 years – yet the fact that they have been running for so many years is both a blessing and a curse. The blessing is that they are scalable, reliable, stable systems, with some rare exceptions. Whatever else people might say about their core systems, they do the job day in and day out. The curse is that they are saddled with old technology that make the systems very inflexible, hard to communicate with and difficult to maintain.

Banks think a bit differently about the DDA core and other core systems. The DDA system is the very heart of the bank. This system must support thousands of transactions an hour, or maybe even every minute, and must do so during the course of the entire business day across multiple time zones. If this system goes down for an hour during the day, chaos ensues. Customers can’t access their cash, make deposits, cash checks, etc. If this system goes down for a day, the consequences are beyond contemplation. Changing out a DDA system is a brave task. Therefore we find that today’s DDA core systems are more than likely yesterday’s core systems. If it ain’t broke, don’t fix it.

Other core systems are much less transaction intensive and less risky to change. Not surprisingly bankers are more likely to change them. But why change them at all?

The brittle business
Older technology is much less flexible. There may be some features required from the core that are simply too difficult to add to the existing technology. One bank wanted to take the lead in syndications of commercial loans. It was very difficult for their commercial lending system to manage this, and the line of business (LOB) decided to acquire a new commercial lending system in order to gain that capability.

These older systems also have decades of customizations applied to them. Many of the authors of these customizations have retired, leaving younger programmers to decipher the ‘write-only’ code that older languages are sometimes called. When it is time to upgrade to a newer version of the purchased system, the customizations need to be understood, migrated to the new system and tested. This is an expensive and daunting prospect. Adding new features and customizations also requires that every implication of existing customization is well understood and tested before any changes are made. These implications can be in systems other than the one being changed. With customization on top of a workaround on top of a base of COBOL, any changes to the system are a technical challenge. If you picture the core banking engine as a bunch of gears, the customizations and workarounds are like molasses in the gears, making the process of change slower and more cumbersome.

Change the channel: integration issues
Another challenge with this older technology is communicating with the myriad systems that now require information. When these systems were built in the 1970s, bankers were content with a green screen interface that highly trained tellers could operate. They knew the transaction code for a cash deposit was 163, and that was enough. Today, we have channel proliferation where the core DDA system is likely to communicate with the ATM, contact center, interactive voice response (IVR), teller, platform, internet banking, debit card and automated clearing house (ACH).

IT departments have had to create lots of custom code to enable these core systems to communicate with the front-end and back-end systems that have proliferated in the last 30 years. This becomes more and more expensive as the channels proliferate. When a new product is added to the core, new code must be written for each interface to manage the new product. We’ve just added more molasses to the system.

There are two solutions to this problem. The more popular solution is to create a middleware layer that abstracts out the core system and provides a service-oriented architecture to the front-end. The other is to modernize core systems so that they will have exposed application program interfaces (APIs) or service-oriented architectures (SOA) front-ends built into them.

The time is now
Banking is moving faster and faster. ACH deposits can hit an account any time of day, as can debit card transactions. We have made it easier for customers to check their balances any time of day via the internet, IVR, ATM, the call center and the teller. They want the same answer across all channels; bankers want a single version of the truth. All this leads to a painful realization that batch processing is no longer the best way to handle transactions on a DDA system. Banks have created a number of workarounds to give the appearance of real-time transactions such as memo posting and maintaining yesterday’s core balance and today’s transactions in a middle layer. These are computationally intensive and logically complex solutions to a simple problem: real-time balances for real-time transactions in the core.

The DDA systems designed in the 1970s and 1980s are not real-time systems, but designed around nightly batches. The need to develop lots of code to create the illusion of real-time banking is yet another dollop of molasses slowing down development of new products and processes in the core banking engine.

Customer-centricity
Many banks are starting to rethink how they interact with their customers, moving from a product-centric view of the world to a customer-centric view. This is a dramatic departure from the past and continues to be a work-in-progress. The hierarchy of banks remains organized around lines of business, not customers. The banks’ technical and human resources continue to reflect that reality. As banks move towards a more customer-centric view of the world, their systems will need to reflect that. This customer-centric view will enable cross selling and relationship pricing, which retail bankers believe will help banks increase share of wallet, loyalty and customer profitability.

Mergers
The most common reason banks change DDA core is a merger or acquisition. Banks are unanimous in their thinking that duplicate systems should not exist. It requires double the resources to run two systems, whereas running twice as many accounts on a single system is much less expensive. If overlapping core systems exist, every new product must be developed for both systems to give all customers access to new products. This is an expensive undertaking that impedes product development adding more molasses to the core engine. Alternatively customers can be on multiple systems, which causes its own sets of problems. One Bank of America customer tried to access her Bank of America accounts from one state in another state. She couldn’t because they were on different systems. Corporate customers might find that they span two core systems of the merged bank and not receive consolidated services from the bank.

All these factors drive banks to move merged banks to a single system for each LOB. What usually happens is a ‘bake-off’ where each LOB will compare their respective core systems and select one as the merged bank standard. This is a complex multi-year process that can bring new product development to a halt as virtually all IT resources are consumed by this mega project. Nevertheless, most banks consider this a top priority as they would rather be on a single core system and focus development on that system rather than spread development teams over two systems, slowing down new product development for the duration of the duplicate systems. Most banks will bite the bullet and move forward with the consolidation with all due speed.

Acquisitions
When a larger bank acquires a significantly smaller one, the smaller bank is generally migrated to the larger bank’s system. If the bank is under a few billion in assets, it is likely to have outsourced the core system, whereas the larger bank would have this system in-house. This means that the smaller bank would have a very standardized system with well-understood logic. Incremental costs on the larger bank to absorb the customer base of the smaller bank are low.

So why are bankers still using old systems?
We’ve presented a collection of reasons why bankers should be migrating to more modern systems, including more flexibility; better integration; real-time capabilities; customer-centricity; mergers and acquisitions. So how could they possibly remain on these legacy systems?

First, the existing solutions still work. Bankers have seen their core systems work for them day-in and day-out. The saying is, “if it ain’t broke, don’t fix it.” While re-architecting the core might be a ‘nice-to-have’ on the list of IT priorities, there are many ‘must-haves’ on this list too.

Second, it’s very tough to create an ROI on this. The investment is quite clear, quite large and likely to be underestimated. The return is in cost-savings, process improvements and untested revenue-generating assumptions. There are many projects with far clearer ROIs than replacing the core banking system.

Third, it is a huge, risky, tough project with lots of downside for the sponsor. There are a number of failed core banking replacement projects that cost many a CIO his career as well as many banks tens or even hundreds of millions of dollars. These are long projects with long time horizons. The benefits come just in time for the CIO’s retirement!

Fourth, the technology used by these older systems is well proven. Mainframes were designed from the ground up to be secure, stable, transaction machines. More modern technologies such as Unix are much more flexible and communications-oriented, but don’t necessarily have the maturity in features such as security access, version control, provisioning and processing throughput. While the old technology has its limitations, it has its strengths as well, and they should not be discounted. The new technologies have not yet been demonstrated in North America on a large scale. Bankers are looking at a well-understood and proven technology versus something that isn’t quite as certain.

Finally, bankers are finding it much less risky to make an investment in middleware rather than the core systems to manage some of the problems the legacy core systems create. An SOA front-end to a core system can address the integration issues and middleware can integrate customer information across technology silos. Bankers are also using the middle layer to keep track of transactions in real-time, maintaining the current day’s transactions in a middle layer and using that to update information presented to the end-user.

Conclusion
So bankers have to continually balance the risks and rewards, and most continue to think that the risks outweigh the rewards. They are finding that investing in middleware to solve some of the problems of the old core systems is a viable alternative without so much risk to the bank or their own career. Celent forecasts that the world’s 100 largest financial institutions will spend in excess of US$14 billion on new core banking systems by the end of 2005. This spending will take place despite current economic uncertainties and cost-cutting pressures, as banks believe the benefits of replacement far outweigh the costs. First movers will catapult into the 21st century, positioning themselves years ahead of the competition.