Established in 1993 on the formation of the Czech Republic, the Czech National Bank (CNB) has its roots in the long established central bank of Czechoslovakia. As the central bank of the new Republic, the CNB provides all clearing and settlement services for the 50 or so banks licensed to operate in the country. Business has grown rapidly over recent years; in 1998 the Bank handled a daily average of 750,000 transactions with an average daily value of over 300bn CZK – roughly US$10bn – almost four times the business handled by its predecessor in 1992 for Czechoslovakia as a whole. Growth is expected to continue at an annual rate of 15-20%.
Of the Bank’s 1400 employees, about 30 are IT specialists working at the Bank’s core – the Payment Systems Section. Here all the transactions undertaken by the country’s banks are processed on Unisys A16 and A18 mainframes, with the data held on a massive DMSII database. The CNB receives files of transaction data from the banks throughout each day – down the line or physically delivered to them – and processing is done effectively in real time, with data entered as soon as it is received. Relevant processing information and account details are relayed back to the participating banks electronically, via a daily statement, but if an individual bank wants to know the most up-to-date position on its account, it must phone the CNB.
Marek Fialka, Director of the Policy and Development Department in the Payment Systems Section, admits that this situation is far from ideal. “The banks rely on having good, up-to-date information from us to conduct their business efficiently. But the amount of data which we can pass to them over the phone is limited, and security is also a concern. Further, a phonebased system makes heavy demands on the CNB’s staff. We want to be able to give our customers the information they need in a more comprehensive, efficient and secure way. So, about 18 months ago, we set out to explore how we could use the latest information technologies to make this aim a reality.”
The first step was to establish a small Project Group to define the basic requirements of the desired new Information Service. After consultation with a number of their most active customers, representing a range of different types of bank, the CNB soon decided that the ideal way to get the information to their customers was to use an extranet. “We considered a client/server model” says Fialka, “but soon rejected it in favour of an extranet-based service. The client/server environment would require development, delivery and maintenance of the client side, which we were reluctant to take on, and participating banks would have to purchase special hardware and software which would have significantly reduced the attraction of the service for them. With an extranet based service all the banks would need was a Web browser and a connection to us, which all of them already have anyway, so there would be no additional cost to them.”
Another early decision was that, as far as possible, the Information Service should use off-the-shelf, rather than bespoke, components and software. Fialka again: “We felt that such an approach would maximise cost-effectiveness, both initially and in terms of subsequent maintenance, and would also more easily facilitate future developments.” The result of the Project Team’s deliberations was a two page document which formed the brief for the next stage of the project, a Definition Study. Since the CNB was committed to retaining its master database on its Unisys A Series machines, it asked Unisys to be the prime contractor for the Study, but Fialka is quick to point out that the work was a joint effort, with major input from up to 7 CNB staff, and from various subcontractors, as well as from Unisys. To provide continuity between the old and new systems the Bank staff involved were drawn from those responsible for maintaining and developing the existing clearing and settlement system, who carried out the work alongside their normal duties. This approach was important not just to make good use of existing knowledge but also because the Bank knew that the ultimate responsibility for maintaining and further developing the new Information System would lie with them, so it was vital that key staffwere closely involved from the beginning.
The Definition Study, which detailed how the whole system would work, what the individual components would be, how they would be integrated into the CNB environment, and how the project would be finally implemented, took almost 6 months to complete and ran to some 200 pages. In very simple terms the desired solution required the data to which the customer banks wanted frequent access to be replicated from the primary DMSII database onto an alternative platform and thence to a Web server. Crucially, the mechanism for replication had to facilitate rapid updating so that any changes in the relevant data in the DMSII would be rapidly transferred to the replicated database.
Initially two possible ways of effecting this replication were suggested, Unisys’ RDB and DATABridge from Attachmate. For CNB the choice was easy. Marek Fialka explains: “At an early stage in the project we decided that, whilst we wanted to keep our accounting system on the mainframe, we wanted the Information System to be on Windows NT and Oracle database platforms. In this way we would keep the reliability and security of the mainframe for our core transaction processing, but gain the benefits of an open environment, which would be less costly, more flexible and allow us a greater choice of suppliers, for the information delivery side. DATABridge would allow us to do this, whereas RDB works only from mainframe to mainframe, so Attachmate’s DATABridge was our choice.”
DATABridge selectively replicates DMSII data from an A Series host onto an alternative platform. Once the replication (target) database has been established, DATABridge tracks the DMSII audit files to determine records that have been modified, added or deleted and pulls any records which match the specifications for the target database, which is updated accordingly. The speed with which this happens depends on how frequently DATABridge is ‘asked’ to examine the DMSII audit files.
Once the Definition Study was accepted, and DATABridge chosen, implementation began and was completed in around ten months. Specified data is replicated to an Oracle database which is currently about 650MB of raw data. The CNB originally specified a maximum delay of 100 seconds between a change in the DMSII data and the corresponding change in the Oracle data. In practice the delay is rarely more than 50 seconds and can be as little as 30 seconds. Since the Bank anticipates continuing growth in the amount of data it will handle, capacity testing was done with 5 million daily transactions entering the primary database ie about 2.5 times the current maximum, and with the Oracle database full. The response time was not significantly changed, giving the CNB confidence that the system will easily cope with any future growth.
Once the data is replicated to the Oracle database it is a relatively straightforward matter to publish it to the CNB’s clearing and settlement centre extranet, for access by the banks via any standard Web browser. Security considerations prevent disclosure of the precise way this is achieved but, as with the rest of the system, 90% of the software used is off-the-shelf. Information is offered to the banks on a pre-defined set of screens, but within these are a number of parameters which each participating bank can alter to suit its own requirements, so a degree of customisation of the service is possible. And, as all this activity is taking place remote from the Bank’s mainframe, it can continue its essential transaction processing with no degradation in performance.
Security is obviously vital, and this is achieved by a combination of different approaches covering all levels – the CNB’s mainframe, the Web site, the network connection – and ending with proper login authentication of each user. In addition the legal agreements between the CNB and participating banks are being changed to cover the new service.
Reviewing progress with the project, Marek Fialka expresses satisfaction and notes that widescale adoption of the service will impact on the operations of the CNB itself. “With more automated data transmission we will be able to make more efficient use of our staff, but our operations will be much more exposed to our customers. They will know what is happening as it happens – from now on, if we have any malfunctions, all our customers will know about them. The new Information System will certainly keep us on our toes!”
But, according to Tomas Hladek, Executive Director of the Payment Systems Section, such a price is well worth paying for the improved service which the CNB can now offer its customers. “The Czech National Bank exists to support the nation’s banks in the services they provide for the people and businesses of the Czech Republic. We take pride in harnessing state-of-the- art technology, such as DATABridge, to enhance the services we offer. I am confident that the significantly improved detail, structure and quality of the data we can now provide to the banks will help them manage their businesses more effectively and efficiently and, in particular, better maintain their liquidity, to everyone’s advantage.”