Keywords

1 The Problem

In the 1970s many financial markets suffered under increasing volumes of securities and increasing trading volumes. The paper handling of bonds and their interest coupons resulted in very high costs:

  • Issuing of certificates.

  • Safekeeping.

  • Asset servicing: cutting coupons, counting (and recounting), redemptions (drawings) and the resulting payments.

The deliveries and payments resulting from securities trading were the main problems. Trading volumes resulted in large delays, and the volume of unsettled trades had reached a level where The Danish Central Bank and major participants regarded it as a systemic risk: something had to be done. High level discussions went on for years and years. These were difficult discussions, because many competitive issues were buried in the design of the solution.

In 1980 – after more than a decade of discussions and negotiations – legislation was approved by the Danish Parliament: As the first country in the world Denmark would abolish paper securities. A private organization, Værdipapircentralen (VP), should be created. VP’s main functions should be:

  • to register all exchange traded bonds

  • to register ownership (and other rights, e.g. pledge) to those bonds

  • to settle trades in bonds (delivery and payments) and

  • to make other payments in connection with the lifecycle of the bonds (interest and redemption payments).

The legislation had effect from July 1st 1980. And then the process of building the organization and the necessary IT-systems could begin (Fig. 1).

Fig. 1.
figure 1

Replacing 46 million certificates with registration in VP - a central securities depository (CSD)

Full size image

2 Prelude

2.1 The Planning Secretariat

Once the legislation was in place the new organization – VP – would have to bootstrap itself: a lot of parallel development should start:

  • Office and production facilities for VP.

  • Rules, regulations and statutes for VP.

  • Organization and staffing – procedures and standards.

  • IT-installation.

  • Application development.

  • User contracts and user training.

  • Information to the general public.

Therefore - prior to 1980 - a small (4 persons) secretariat had analyzed and planned all aspects of the future organization. A set of plans and contracts were drafted, so that the board of the new organization could get things moving very quickly, after the new law on VP had been passed by Danish Parliament.

Two cornerstones in the planning process were the organizational profile for VP (see Sect. 2.2) and the VP Utopia for systems development (Sect. 2.3).

One of the major issues in the planning process was evaluation and selection of the DBMS for the VP database, as this was the heart of the VP applications. Could a standard DBMS do the job? With the help from consultants a number of DBMS systems were evaluated. System 2000 (a hierarchical DBMS from Intel) was selected, and a full scale prototype of the future VP system under System 2000 was tested in the IBM labs in Munich.

2.2 The Organizational Profile of VP

VP would have contact with all parts of the Danish financial sector:

  • Mortgage Credit institutes (as issuers of bonds).

  • Banks and savings banks (as custodians of bonds and as traders of bonds).

  • Stockbrokers (as traders of bonds).

  • The Danish Central Bank (as issuer of government bonds and as operator of the central cash clearing system).

  • Insurance companies and other institutional investors.

  • We did not want the individual investors (1 million) to have direct contact with VP. That would have a dramatic impact on the profile of the organization. We wanted VP to be a “technical machine”, operating “behind the curtain”, helping the financial institutions to service their customers (much) safer and cheaper than before. To handle this structure we created the concept of “account controller”. The customer would keep his relationship with his local bank:

  • It would be transparent to the customer that some of the processing in connection with his safe custody account had moved to a “back office” in VP.

  • It would be easy to explain the transition (from certificates to electronic securities) to the customer.

We wanted VP to be “lean and mean” – an organization with aggressive use of IT in all functions, so that we could keep the size of the organization down (100 persons was our estimate). We wanted to avoid unnecessary bureaucracy. We wanted to create very high security awareness in the VP staff. VP should be considered safe beyond any doubt. The parliament was quite nervous about this abolition of millions of documents, and the legislation was clear: If anything goes wrong, the system must pay!

We did not want VP to be a traditional banking data center (state of the art in 1980 was transactions input during the day and truckloads of paper output to the branches at the end of a long night).

We wanted the VP system to communicate, not only with a number of terminals but with the host systems of the user organizations. We wanted peer to peer communication using standard communication software and protocols. IBM at the time considered this request highly unusual! An additional problem was that there were a lot of different systems out there: Large IBM mainframes in the banks and in the savings banks data center and a very large variety of medium size systems in the brokerage community. In the end: 29 host systems and 500 terminals would be connected to the VP system (Fig. 2).

Fig. 2.
figure 2

User online communication connections to VP

Full size image

2.3 The VP Utopia

Quite often large IT development projects fail. And we knew from beginning that project risk must be at our focus as the main problem. Project size and project complexity was our main concerns. But many other risk factors were present: New organization, complex and competitive user environment, supervisory authorities etc.

We knew from our initial investigations, that buying an application was not an option. We would have to develop the solution.

Out of our planning discussions grew our VP Utopia:

  • Keep the project size down by using existing infrastructure (PBS money transfer system for interest and redemption payments – the Central Bank clearing system for delivery versus payment for all professional trades).

  • Keep the size down by using standard software wherever possible:

    • A central data dictionary to control all documentation.

    • A DBMS to control all databases.

    • A programming language that supported our modular approach.

    • A terminal development system.

    • A text editor to create user documentation based on extracts from the data dictionary

    • A standard communications system.

    • A library system for all programs.

    • An automated production management system.

  • Small project groups with systematic coordination and quality control mechanisms.

  • Rapid implementation strategy based on a prototyping strategy.

  • Development methodology, based on structured analysis, data modelling, structured design and programming.

  • Heavy training of all persons (we used Yourdon inc. to do this part, not because we believed them to have “a magic bullet”, but because they tended to agree with us in most matters).

  • High user acceptance through strong interaction during the development period.

The main reasoning behind the VP Utopia can be seen in the book by VPs head of systems development: H. Dines Hansen: Up & Running [1].

3 Milestone Management of the VP Project

3.1 Milestone 0, March 1981: The Starting Point

The preliminary plan (and prototype) from the planning secretariat divided the application development into 4 projects with well defined interfaces between the projects:

  • Communications.

  • Conversion.

  • Daily clearing and settlement.

  • Asset servicing (interest payments and redemptions).

Even the 4 projects were too large to be manageable, so each project had to be divided into smaller projects: 160 in total.

By November 1980 the key persons, data manager and database manager and all project managers had been hired. After initial training in VP development strategies they had to revise and refine the plan and hire their own staff. This second wave started working on February 1st 1980 and – after training – helped produce the Milestone 0: The plan for a two year development, with project charters and visible operational goals for every three months.

The plan was presented to the user organization in a number of seminars. For every milestone the plan focused on:

  • The visible results from VP to the users.

  • The visible results from the users to VP (very little initially – more and more as the process progressed).

Later we also made a milestone plan listing the deliveries from the VP board and from the supervisory authorities. And both parties accepted their part of the overall plan.

3.2 Milestone 1, July 1981: The First Small Results: Test Conversions

The conversion strategy was based on the fact that most bonds were already in the systems. The issuers had all information about exiting documents, and the custodian banks had information about the documents in their custody.

The first milestone was a relatively easy one, but it was important to show all 29 data centers that the process had started. Nobody had expected to hear from us until 1983. The participants had to send all their information on bonds to VP in a specified format. VP would then validate the information:

  • Technical validation.

  • Were all holdings valid from the issuer’s point of view?

  • Were there duplications, where two banks said that they had the same document (synchronization problems).

The first test conversion also gave us vital live information for our modelling of the VP database structure.

This process of test conversions was repeated for every milestone, gradually reducing the number of errors, so that the final conversion had more than a 99.9 % success rate. Only very few conversions had to be handled manually.

The second – and most important - result was that the milestone plan was approved by the participants. Not without discussion: The traditionalists claimed: “You can’t make the plan before you know all the details”. Finally everybody agreed to the plan (probably because everybody believed VP to be late).

Finally the third wave of EDP-professionals had arrived, been trained and started working. By now VP was up to 75 % capacity. The new VP building had been finished, everybody had moved to the new offices, and two of the three IBM computers had been installed.

3.3 Milestone 2, September 1981: A First Implemented Prototype of All Major Functions

Milestone 2 was the first serious test for the new organization’s ability to produce acceptable results. All major teams and groups in VP had deliveries to this milestone:

  • A comprehensive description of user requirements.

  • Business policies: criteria for validation and updates.

  • Physical layouts of the main databases as well as data flow diagrams and minispecs for functions in the DFDs.

The milestone results were presented in a series of seminars for user organizations and their data centers, and after one month we had received 180 proposals and change requests.

One of the important roles in creating documentation standards and coordinating between project groups was the data manager. He was responsible for the data dictionary, which proved to be an indispensable tool for ensuring quality of data and data definitions. The data dictionary was the source for program documentation as well as user documentation.

The milestone 2 results were impressive since it was the first major demonstration that the new organization (with an average employment of 6 months) could work as a team.

3.4 Milestone 3, December 1981: A Revised Prototype of All Major Functions

Milestone 3 contained more or less the same main functions as Milestone 2, but it contained more than one hundred changes to business policies and database definitions. We were careful to respond quickly to all proposals and change requests. This was a major test to our development and documentation strategies. VP proved able to respond to the users as well direct and control the process. For some organizations this was a wakeup call: The train was moving and the milestone plan should be taken seriously. Other organizations gave the project high priority and saw a potential competitive advantage in being ready from day one. They would not accept any delays.

Internally everybody was extremely busy with their own detailed parts. Therefore the main challenge was to focus on quality control and coordination. We had to focus everybody’s attention and commitment to the total result.

As part of Milestone 3 VP presented the detailed plans for the rest of the project: Final date for the conversion: January 24th, 1983 for the pilot conversion and April 5th, 1983 for the total conversion and full scale operations.

3.5 Milestone 4, March 1982: All Functions Frozen

At milestone 4 VP changed pace to a more conservative implementation strategy. From this point on only obvious mistakes, errors and inconsistencies were corrected. This change of pace happened for two reasons: firstly to give all the data centers a chance to do their part of the development against a known, stable background, and secondly because we had entered a period where all users were to sign legal contracts with VP.

The project groups began tuning the system in order to estimate the necessary production capacity. A full user manual was presented, and end user training could begin.

The presentation to the data centers showed that several of them could need extra time. We decided against this: both external and internal morale was dependent on the fact that the milestones were to be taken seriously. A minor delay would postpone the entire project at least one year! From this point it was clear that a single user organization would not be allowed to change the project’s objectives or schedule.

3.6 Milestone 5, July 1982: All Functions Implemented and Tested

Milestone 5 presented a tuned production environment to be used for systems testing. Users were presented with plan and procedures for the testing. The first phase of testing (October) was recommended but not mandatory. The second phase (until December 15th, 1982) was mandatory. Minimum requirements per functions were defined for all users, and users that had not fulfilled the test requirement would only be allowed to participate in the VP system through a standard VP terminal. This interface to VP was defined as a “Plan B” for users that were delayed in their internal development. The VP terminal also served as an important interface in the initial systems testing.

3.7 Milestone 6, September 1982: Fully Implemented Communications Network

The full communications system was implemented only one month before systems testing started. This might seem a bit implemented (Systems Network Interconnect). VP was one of the first organizations worldwide to implement this functionality.

An important definition phase followed: each user should specify the type of output he wanted: printed output, edited and non-edited output or CICS-print via the online system. Only after this had been specified could the testing begin. In total VP had to handle 23.000 output/address combinations. This was only possible because of a standard spooling system.

Internally a special test coordination group was established with detailed procedures in order to handle effective problem and change management and prioritizing as well as quick and effective communication with the users.

3.8 Milestone 7, November 1982: Full Scale User Testing

The general public was informed about the proposed change through all major newspaper and National Broadcasting TV.

Internally all major functions had been tested since Milestone 4. By Milestone 7 the entire VP system was approved for external testing as described above.

During external testing 681 problems were registered (and all were solved except 50 uncritical problems).

The test plan had measurable criteria for the acceptance of the 29 data center systems. 10 out of the 29 data centers had more than five outstanding problems at the end of testing. These data centers were granted until January 14th, 1983 to correct the problems.

3.9 Milestone 8, January 1983: Conversion and Pilot Operations for a Limited Bond Volume

On January 4th The VP board evaluated the results and status from the testing phase and approved to start actual production on January 24th, 1983.

During the weekend of January 8th and 9th 600.000 investor accounts were converted to the new system.

Two weeks later 1.5 million bonds with a nominal value of 24 Billion DKK were converted to the VP system. Only 3.000 bonds were rejected and had to go through manual control. During the first two weeks of pilot operations ten errors were reported and corrected immediately. During the rest of the pilot operation no errors were found. We are talking about hundreds of thousands of lines of code! Half of the problems related to the same part of the system – a part that was considered too large and too complicated. That part was quickly redesigned.

3.10 Milestone 9, April 1983: Conversion of 46 Million Bonds and Full Scale Operations

During the Easter holidays in 1983 the main conversion took place: 46 million certificates with a nominal value of 600 Billion DKK were converted into the VP database and registered on 1.045.000 investor accounts. VP could finally go into full scale production – on time and within budget. A 200 man-year project, involving 100 people, had come to an end.

The first months of operations were – as one might expect – a challenge. This was mainly because of changes in the financial markets. Market volumes were booming all over Europe, and the VP system was loaded way over the estimated capacity. The VP system proved rather robust, but delays were inevitable. Our neighbouring markets in Sweden and Norway were on the brink of catastrophe. This is the main reason that the VP system was later exported to Norway, and Sweden decided to copy the system (at far greater cost).

There was a problem in the business definitions: Banks had unlimited cash lines with The Central Bank, but brokers had limits on their cash available for settlement. We were told that the brokers (knowing their actual trades) would always have the cash in place in time for settlement (3 days after trade day). Actual operations told a different story since it was more expensive to fund a buffer on his credit line than to solve the problem when it occurred. This introduced a manual procedure in the operations (known as amber light/green light procedures) and it took a considerable while until the procedure could be automated.

4 Lessons Learned

4.1 Prototyping and Implementation Strategy

One could argue that leading edge technology and new application areas should call for a conservative implementation strategy. I would say application development and prototyping approach is especially useful in such circumstances. Such a strategy will give early warning of potential problems and ensure that vital systems components are tested early.

The problem through the 1980s and most of the 1990s is that every new generation of computer professionals came out of school or university well trained in sequential (waterfall) development models. The same goes for many of the development tools that were sold during these decades.

In our case the communications architecture was implemented rather late, but we accepted this as a fact of life. IBM was unable to deliver this solution earlier. We had to define a national communications address standard for the entire country – a standard that was approved by IBM. After a while IBM reported a problem: We needed a country code if one of the computers in the network (e.g. IBM’s own mainframe) had to address a computer in another country. This only to illustrate that everybody – including IBM – was in a learning mode.

4.2 IT Tools Wherever Possible: The VP Utopia

The VP Utopia and the aggressive use of standard software wherever possible can hardly be considered breaking news today. It is more or less what everybody is proposing. Our methods for analysis, data modelling and design greatly helped us in minimizing systems complexity.

We considered the VP Utopia a huge success at the time and gave presentations on the NordData conferences in 1984 and 1985 and a full day seminar on the NordData 1986 conference in Stockholm.

4.3 Milestone Management

The approach with very visible milestones proved to be an extremely powerful tool in managing the entire process with so many conflicting interests.

The total priority was sky high, and nobody wanted to be the one that delayed the entire project. In the end even the authorities came under the pressure of the milestones that they had initially accepted!

4.4 Operation Under Peak Volume

The market volumes in 1983 were mentioned above. But the VP system had removed a lot of paper from the stock exchange settlement. Therefore – over the first few years of operations - the total volumes went far beyond what would have been possible in the paper based settlement system.

4.5 A Flexible System Can Do More

A flexible system inspires the users: The VP system could with a single transaction do delivery (of traded securities) against payment (in Central Bank money). The very same transaction can provide liquidity against the movement of collateral for that same liquidity. So the VP system was used to remove a lot of the liquidity risk from the Danish financial sector.

The VP systems design proved robust and flexible: New types of securities could easily be added. Equities were introduced in 1986. Later VP was able to add a high speed link to Euroclear in order to handle the settlement of cross border trades. In 1985–1986 the system was modified and exported to Norway as described by Jan Hellstrøm on HiNC3 [2].

4.6 Zero-Defect Systems Development

There is no such thing as zero-defect development. But the systems development strategies and tools chosen brought the VP system very close to this ideal goal. The legislation stated that if anything went wrong, the VP system would have to pay. I never saw a single claim under this rule during my many years as managing director of VP (until 1999)!