Norway: Banking and the Nuclear Power Industry

It is said that, by learning another language we obtain a deeper understanding of our own. As such, a brief look at the nuclear power industry may help shed light on some of the issues surrounding the banking sector.

At the outset of this article, however, I have to make one thing absolutely clear. I'm not trying to establish some tenuous comparison between the nuclear power industry and the average bank. Nevertheless, the fact remains that, while on the outside these are two very different industries, there are significant analogies to be had between the processes of these apparently disparate businesses.

Consider the implications should the systems controlling the core cooling and heat transfer processes in a nuclear reactor cease to operate. Liquid metals, such as sodium, are used as heat-transfer fluids in nuclear reactors. From time to time, modifications may be needed to the sodium transporting pipe-work circuitry and critical system valves may also need replacing. Naturally, this work must be done to the highest quality assurance and safety standards.

Working with liquid sodium pipe-work and its contents is not easy. If we assume for example that a sodium pump indicates a fault, it will have to be replaced. Clearly, it cannot simply be disconnected from the pipe-work circuit - aside from the danger of leaks of this explosive material, the cooling of the core cannot be interrupted.

To effect this task as swiftly and easily as possible, and with forward planning and design, cooling pipe-work circuits incorporate a series of bypass valves, which are used to divert the coolant to an alternative replacement pump. The faulty pump is isolated and removed, and a new pump connected to the circuit. Throughout this process, the flow of sodium continues while the rectification takes place. Critically, the core does not over-heat and the fault is removed.

Now, let's move this analogy directly into the banking sector. According to Celent's Christine Barry, 'Legacy systems, often installed during the 1960s and 1970s, have proven extremely inefficient, costly to maintain, and no longer flexible enough to handle system changes and new applications necessary to meet the growing needs and requirements of the marketplace.' Now, while these are strong words in themselves, Barry is fully able to justify her position.

Systems have been constantly modified to keep the banking process active and modern. Downtime at the core of the bank would be a disaster for the bank, shareholders and customers alike. And, there is little doubt that virtually all banking IT support staff have - at some time in their careers - been exposed to this sort of issue.

Moreover, the arrival of 24x7 banking exacerbates these issues. Where weekend shutdowns could previously allow for new releases and changes to the software, systems now have to operate without interruption. The fact remains that, regardless of whether there are support teams within the bank, or even if the entire support service is outsourced, the old software seems to operate with a 'do not disturb' sign firmly attached to the outside.

Unfortunately, the banking world does not and cannot stand still. New banks, boasting highly advanced product and service offerings, are constantly appearing on the global horizon. Inevitably, these institutions are at the forefront of technology, taking advantage of Internet communications and every facility within their command to drive costs down. However, even these streamlined organisations remain subject to external market forces over which they have little if any control.

A prime example of this is the impending introduction of EU regulations governing charges for processing cross border payments. This external factor will have a far reaching effect on banking organisations, wholeheartedly affecting the charges that can be levied, and meaning that banks will have to be highly efficient, otherwise they will operate at a loss in that business sector.

When the nuclear power industry replaces its liquid sodium pumps, it takes the opportunity to introduce the latest technology, taking advantage of the chance to install a replacement that modernises the system and lowers maintenance costs in one go. Maybe it's time for the banking industry to adopt a similar strategy.

For example a Bank may want to experiment with giving access to only one customer to its own range of bank accounts. Installing a flexible interface with added functionality may allow the Bank to trial offering finely tuned services without the competition being aware. The analogy in the nuclear industry is perhaps a new liquid sodium pump having the ability to house new sensors and testing technology.

Banking systems have grown over the years to be integrated applications on multiple platforms. This makes it possible to replace critical systems and functions one at a time, using well-tried interface technology. The historical incremental enhancement of specific functions at a local level presently makes it difficult to support the end results of system integration. A properly designed application should have standardised functional components with clear definitions of role and scope. Functions are therefore not duplicated and cannot get "out of step" through spot changes. Today, technology is available which benefits in extensive re-use of code, ensuring that functionality is not repeated through disparate element of code.

The software used by the typical bank will have been modified and extended over the years following installation. Nevertheless, the core is usually still there - a clunky Cobol back end, with functionality stitched on to keep up with external requirements. Now, while this piecemeal approach is fine insofar as it goes, banks nowadays have to be globally competitive, and so operational costs and risks also have to be considered. As such, there may be little opportunity to introduce new products or services on the fly to keep ahead of competitors using older technology.

The global market in which banks operate dictates that they are subject to various forms of risk, including credit, equities and securities. Nonetheless, it is likely that the operational risk and cost attributed to changing the payments engine, for example, is so high, that this has not been addressed for over thirty years. More recently, however, operational resilience has become an acknowledged requirement of all major institutions, both as a duty to shareholders and as a route to adding stock value.

So, if we recognise that the bank cannot be shut down for the whole weekend when the time comes to install a complete new system, what can be done to smooth the upgrade process?

One solution is to apply re-usable robust code built in a component format. This method uses fully parameterised interfacing software to divert the data flow, rather like the valves in our nuclear power station. There must be resilience built into the code to enable efficient information transfer and high volume data flow.

Returning to our power station analogy once again, when the new components are introduced into the liquid sodium pipe-work, every advantage is taken to introduce updated sensors, risk management devices and other key components. These devices have to operate individually as well as when connected to other components, and exchanging them piecemeal reduces risk and allows for familiarisation and testing.

Back in the banking world, fully connected components and objects ought to be able to automate everyday financial tasks, such as payment processing. Individual common components should be able to utilise extra functionality such as IBAN control and BIC codes to assist with this automation. In fact, there is no reason why most of the International Banking databases and standards cannot be automatically connected. Just take a moment to consider the STP payment rate that could be achieved if all these factors could work together.

Even though international standards have been devised and released publicly, not all are adopted by every institution. However, if all systems did adopt the same international standards, that alone would provide a considerable saving in manpower and resources. Increasing automation in this way means lower costs and systems that are more manageable. Maintenance costs are correspondingly lower, while consultancy fees are effectively eliminated.

If we drill down even further, we can make a strong case to argue that middleware was invented to provide a layer between the 'untouchable core' and the external application - inevitably adding to the overall complexity and cost of processing banking transactions. Again, adopting international banking standards will often eliminate the need for extensive middleware, allowing simple transactional software to evolve instead.

When parts of the system are being replaced with individual components and objects, common sense has to prevail. Initial investigations into large to medium sized banks may discover hundreds of versions of software just calculating interest. Statistically some will be wrong. Imagine the same situation in the nuclear power plant - hundreds of different makes and models of valves controlling the flow of sodium. Such a scenario is a recipe for disaster, prone to costly breakdown and error, and subject to unsustainably high maintenance costs.

Using Java based component technology, standard objects can be developed for all common elements of banking operations, such as calculation of interest, commissions and fees, IBAN control, BIC Codes, bank holiday control, value dating, accounting transactions etc. Until recently, banks were concerned that this technology was not sufficiently proven, as every bank has a duty to minimise risk. However today this is not the case any longer, systems utilizing such technology are now well proven.

Again according to statistics from research company Celent Communications, the world's hundred largest financial institutions will spend more than $14 billion on replacing core banking systems by the end of 2005. Perhaps those astronomical costs can be shaved if the banks take a low risk by controlling the component replacement process. Just focusing on one banking process - the achievement of domestic and international STP payment rates of 90% - is not a technical challenge but a business one, and must be taken before the start of reactor melt down.