[Chris Oakley's Home Page]

Trading systems and object orientation

The jump from being able to price a single transaction to being able to reliably manage the risk on a diverse portfolio is not trivial. For portfolios consisting solely of securities and futures, both of which can normally be marked to market, the valuation is an easy problem and many systems exist for managing portfolios of these. The valuation of OTC derivatives, on the other hand, generally involves complex mathematics, and none of the existing systems are equipped to deal with new types of trade without extra work being required to extend the software. Banks respond to this problem in one of three ways:

(i) They do not do OTC derivatives that they cannot value with their existing systems. This is understandable, but limits the usefulness of the mathematicians employed by the desk. It is also frustrating for salesmen and traders, especially as by the time the software is extended to cope with the new trade type the opportunity may well have gone.

(ii) They permit trades to be booked and risk-managed using makeshift systems, such as spreadsheets or interpreted languages such as APL. This scenario is a potential nightmare for the risk manager, and as some banks have found to their cost, it is very much open to human error or dishonesty.

(iii) They design a their risk management system in such a way that the mathematician whose devises the valuation model can easily produce a programmed code module that may be used by the system for managing this class of trades.

The latter option is obviously the most desirable, and the key to making it workable is to reduce the amount of work that the mathematician has to do to an absolute minimum. This is where the object-oriented approach becomes useful. Distributed objects, such as those one can get in a scheme like OLE or CORBA, make it even more useful, since the valuation may involve a lot of computing which can usefully be shared by multiple machines.

In object-speak, the trade is an object. It has data, such who dealt it, who with, when, when it matures, and so on, and it has methods, principally, calculating its worth (net present value). Once the trade is executed, then the information required of it will mostly be related to calculating its value in various circumstances. Examples of this are calculating the risk numbers (delta, gamma, vega, theta, etc.), or calculating the VAR (where we value the trade with historical rate values).

Although some of the deals executed by the derivatives desk of major investment banks have a complexity that falls little short of mind-mangling, the questions that need to be asked of each of these by the bookrunners are always the same, and extremely simple, principally, what is the deal worth and what is the exposure to market rates. This is a classic application of object-oriented technology as the simple questions can be methods in a generic trade object, whose answers are provided by derived classes appropriate to each specific trade type. If these are further implemented using CORBA or OLE, then objects can be distributed. Here, in outline, is a scheme that implements these concepts:

A scheme like this should greatly simplify the process of adding new trade types to the system. The work involved should be just creating the sub-classed Valuee methods, plus designing database tables, with the appropriate Save and Retrieve methods, and the risk-management of the trade is possible. Unlike the blotter and portfolio browser, which handle trades on at the level of the classes shown here, the trade pricing screens for new trades would be designed with the specific trade type in mind. There is no alternative to this, because details of the trade cannot be ignored at this level.