An integrated banking network system For banks to use computers economically, data must be collected from branches and processed centrally. Alan Duncan describes the network solution adopted by Barclays Bank.

In 19 74, the Barclays Bank computer network consisted o f three separate computer centres, each serving 600 - 900 branches. In the event o f a major catastrophe at any one centre, it would not have been possible to service the branches connected to it. The paper describes the Barclays Integrated Network System, which was developed to insure against such a situation. Further facilities that will be offered by the system when it is completed are also described.

Computer communications people fall into two classes, those who have found themselves with practical problems in digital data transmission which have had to be solved, and those who talk and argue at length about networks and protocols, inventing rounded problems and finding elegant solutions. The development in the use of computers by the big UK banks has led the banks inexorably from one com- puter communications problem to the next. There is no going back, only a need to move on, each step having to be based carefully on the previous steps.

D E V E L O P M E N T

Technical staff in the UK banks began grappling with com- puter communications problems in the early 1960s, when a processor cost a lot of money. The only way that the banks could use computers in a reasonably economical fashion was to collect work from several branches and to process it centrally. So it was that a need for communica- tion with the computer was established and the word 'tele- processing' was added to the language. Bit checks, batch total checks, sequence numbering of messages and restart procedures were developed and used to solve the day-to-day problems, experience led to improved design, and standards were identified.

On the operational side, a similar advance was taking place, and fast procedures were established for identifying line faults, terminal faults and modem faults. Natural dif- ferences between mainframe suppliers, the British Post Office and terminal suppliers were ironed out in the basic need to survive and to avoid the blanket disapproval of the remote user. To have 50 bank managers on their tele- phones demanding an explanation as to why their book-

Management Services Department, Barclays Bank Ltd., Radbroke Hall, Knutsford, Cheshire WA16 9EU, UK

keeping service has been cut off is a harrowing enough experience. The possibility of 500 managers jamming the telephone exchange should be more than sufficient to en- sure sound computer communications systems.

T E R M I N A L S

The first major point of argument about computer com- munications in the banks was the choice between intelligent terminals and nonintelligent terminals with concentrators. The main issue was reliability. The early computers had thermionic valves, and, from the beginning, the computer people were very conscious about possible breaks in the ser- vice. When only a handful of branches were online, one could be severed from the service by an indiscreet thrust of a labourer's spade in a hole in the pavement outside. The argument was that, with intelligent terminals, a branch could continue to keep its books without communication with the outside; whereas, with nonintelligent terminals and concentrators, if one lost the concentrator, there was no way in which the branches could keep even elementary books.

On the other hand, the use of concentrators made sig- nificant savings in line costs possible. As the records show, the banks were divided on the issue, and both systems were installed.

N E T W O R K S

By 1974, the big UK banks had linked all their accounting branches to computer centres as well as having other net- works serving other applications. At that time, the five major UK banks had about 10 0130 terminals continuously online. In Barclays Bank, networks supported the Barclay- card and foreign payments applications, as well as branch terminals.

The growth of computer communications had occurred quietly and without too much fuss. Impressive porticos with massive doors, especially in the City of London, aptly reflect the attention the banks pay to the security and soli- dity of their service to the public. In the early computer days, reliability was spoken about in terms of 'standby'. One sought 'standby' from the company next door who

94 computer communications

had a similar machine to one's own. It was not, however, until the banks had completed their large branch networks that possible external problems prompted them to look more deeply into contingency plans.

B A R C L A Y S SOLUTION

In Barclays Bank, it was realized that, to maintain a branch accounting service in the event of a major computer failure, the problem was not one of finding alternative processing capacity, but in collecting the data from branches for pro- cessing.

The Barclays branch network in 1974 was as shown in Figure 1. Three computer centres served 600-900 bran- ches, each branch having, on average, between one and two terminals. The branches were linked to their centres by 300 leased multidrop private 1 200 bit/s lines (GPO Tariff $3). Where a branch had more than one intelligent termin- al, the others were concatenated with the first so that only one modem was used per branch. Each centre had approx- imately 30 additional line ports to use on the 600 bit/s pub- lic switched telephone network (PSTN). From these figures it is clear that, in the event of a major catastrophe at any one centre, such as an extensive fire, it would have been impractical for its branches to be served even by all the PSTN ports at the other two centres. It was to solve this problem that Barclays Integrated Network System (BINS) was established.

BARCLAYS INTEGRATED NETWORK SYSTEM

The prime purpose of BINS was to enable data from any branch to be collected and processed at any centre. The principle of the solution was established by Davey Thomas and became known as the 'bunker' concept. In brief, it was

to set up an alternative front-end processor adjacent to, but outside, the 'disaster' area of each of the computer centres, and to connect these processors by high-speed lines to the other centres.

The merit of the bunker solution was that it did not require a massive rerouting of Post Office lines; it only required some duplicating of local wires in the area of the computer centres. (See Figure 2.)

There was no precedent and no information available in text books. The principle having been established, the question of the best systems solution was studied for 18 months. There were three possible solutions of varying costs and with different advantages and facilities.

The simplest solution was to use multiplexers. They could have provided a convenient and very reliable method of combining the data from several lines and transmitting it down one high-speed line.

The most complex solution was a store-and-forward system and the appropriate hardware and software.

The compromise solution was to use 'intelligent' switch- ing without a store-and-forward capability.

The decision to use the compromise solution was reached for two reasons: first, there was the need to imple- ment a standby system in a relatively short time (two years was set as the target), which made the store-and-forward solution probably unattainable; second, an intelligent swit- ching system offered a vehicle for the integrated develop- ment of future online systems in an orderly manner; the problems of the ad hoc development of multiple stand- alone networks were becoming apparent in 1973.

The intelligent switching system enabled the bank to convert its branch network from BTAM (Basic Telecom- munication Access method) to TCAM (Telecommunication Access method) without suffering the limitations IBM placed on TCAM's terminal handling (essential in a mixed- supplier installation such as in Barclays Bank). TCAM does, however, allow a standard online application programme interface to be produced, greatly simplifying the develop- ment of new applications.

Another benefit of the solution adopted was that all the bank's terminals and central computer systems were per- manently interconnected, enabling features such as inter- centre data transfer and terminal access of resources at more than one centre to be incorporated into the design of future systems.

SUPPLIERS

BINS was implemented with assistance from Control Data Ltd., UK, who supplied the dual Cyber 1000 front-end pro- cessors, and Logica Ltd., UK, a software house that special- izes in computer communications.

Figure 1. Barclays branch networks before BINS, showing the three centres with their separate networks

Opera, on

The main functions of the front-end processors are to handle the polling and control transmission. These func- tions were previously executed in the IBM 370/168 main- frames and 2703 Transmission Control Units. The system is data driven; the front-end processors can determine to which computer centre the data should be transmitted and also have a self-monitoring capability. As a matter of policy, it was decided that the front-end processors should be transparent to the application data.

vol 1 no 2 april 78 95

I 200 bit/s

PO exchonge . . . . ~ ~ " .~fch 48 kbit/s

To branches

,8 kbit/S

To branches I~Oblt~ \

Figure 2. Bunker scheme, with remote front~nd processors

Simulation

The whole design with the estimated traffic was simulated using the services of Comress (UK) Ltd. This was an inde- pendent and valuable check on the design calculations and on the suitability of the Cyber 1000.

DEVELOPMENT

BINS was planned to be developed in stages, the first con- cerned with branch terminals, its prime purpose being to provide a means of processing branch accounting at an alternative centre. The first stage was completed during the second half of 1975.

Future plans

Further stages will cover the introduction of new networks into BINS (including VDU-based systems operating a multi- point HDLC protocol), increased use of intercentre com-

munication, and making resources at all centres available to branches. This last stage involves changing branch-terminal input from implicit routing (known as Class A), where the front-end-processor tables define the destination of data received from terminals, to explicit routing (known as Class B), where the terminal tells the front-end processor the des- tination of the data.

It is only now that the implications of some aspects of network design are becoming clearer. A fundamental net- work question is how to ensure that no messages are lost or gained between two endpoints. Either the network must assume responsibility or the application external to the net- work must. This is a complex question, one stage removed from ensuring that the data within a message satisfies some parity checks.

In choosing a compromise solution with 'intelligent' switching, the bank had in mind the need to cater for pos- sible future needs such as the authorization and credit checking that would be required by online 'autotellers'. This was before such devices actually appeared on the market.

Similarly, the possibility of linking in point-of-sale ter- minals was borne in mind. It was also envisaged that the network, once in existence, would be used for the transfer- ence of files. This has indeed been the case, and the traffic has exceeded the estimates.

NETWORK TESTING

The problem of network testing was approached with special care. The project was divided into subprojects, and the early testing of the separate components was extensive, using hardware and software simulators, before they were submitted for stringent subproject acceptance tests. Once the subprojects had passed the acceptance tests, integrated testing was carried out before the final acceptance test of the whole system and before agreement was given for the system to go live. As a result, BINS has a very high relia- bility.

CONCLUSION

BINS is a step forward in network design that will provide Barclays Bank with a sound basis for their next step.

96 computer communications