1 Introduction

1.1 Motivation

Wall Street has a history of failed derivatives systems projects. Several investment banks have lost millions of dollars in the development of systems that turned out not to fullfil the users’ requirements. Why did this happen? Tom Groenfeldt [Groenfeldt97] claims that the critical problem is vision. Systems are started being built without first designing an architecture and often initial designs do not provide foundation for later developments. The problems stem from the pace and competitiveness of the financial markets. Once an opportunity for a new financial instrument is perceived, the traders instantaneously demand adequate software support for their immediate needs. If the Information Technology (IT) department is not able to deliver, the traders put together their own programs. As a matter of fact, many in-house systems originate with a group of traders getting together and writing a quick solution that is later being expanded. The lack of well-designed architecture causes the resulting systems to be inflexible and hard to maintain.

The current approach to tackle these problems is to have two separate systems running in parallel: One is a full-fledged application developed and maintained by the IT department; the other consists of spreadsheets under control of the users. Whenever a dealer starts trading a new type of instrument (an exotic instrument) he can quickly get software support by extending his spreadsheets. Once an instrument becomes more commonly traded (a plain vanilla instrument) the IT department can build it into their system without being under an unreasonable time pressure. Unfortunately, this approach does not really solve the problems discussed above. It is not efficient to maintain two separate systems and it is troublesome to consolidate the risk management data from different sources.

Past experience [Eggenschwiler92] shows that object technology has the potential to meet the challenges posed to developers of financial applications. The recommended approach focuses on frameworks and design patterns. A framework is a reusable, domain specific skeleton that can be customized to the particular needs of an application [Johnson92]. Frameworks often use standard design patterns [Gamma95] to make aspects of the application flexible. The patterns have been documented and cataloged and so are a form of design reuse. While design patterns are patterns that arise because you are trying to build reusable object-oriented programs, analysis patterns [Fowler97a] arise because of the problem you are working on. In this paper, patterns are distinguished with bold type.

I argue that by making use of frameworks and patterns it is possible to build applications for financial derivatives that are flexible enough to keep up with the pace of the markets. Considering the economic importance of derivatives and the urgent need for risk management tools, especially after the huge losses suffered by several companies in derivatives trading over the last couple of years, there is a pressing need to research this issue.

1.2 Objectives

This thesis describes analysis and design of a risk management system for derivative instruments that has been built in an effort to understand what a good architecture for such systems involves. My main focus was on creating a system that is as flexible as possible in order to be easily extendable to support new instruments, pricing models, and risk management methodologies. Another objective was to determine which analysis and design patterns are most useful in the financial engineering domain.

The next chapter provides some background in finance needed to understand the rest of the paper. It is not necessary for readers who are well acquainted with the domain. The third chapter describes the system from the user’s point of view, while the following chapter discusses design trade-offs. Chapter five gives an overview of relevant patterns. The final chapter suggests possible future work on this topic.

Top | TOC | Main | Home | Contact Me