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:

Class Rates

A variable-length array of market rates, in the form [Mnemonic, Value]. The mnemonics are textual names identifying the rate that have meaning to the trade objects. The value may be a single number, a two-way price, a yield curve or an interpolation table (for a volatility curve or surface, or similar). The Rates object can be constructed so that it has slots for the sensitivities (deltas) of a trade or portfolio to each rate in turn.
Class Valuee

Something that can be valued; namely a Trade, a trade collection Trades, or a Portfolio.

Methods:

virtual ErrorCode MergeRates(Rates &RL, CCY Ccy) = 0

Ensures that the list of rates in the Rates object contains those required to value the trade or portfolio in the currency given by expanding the Rates object as necessary.

virtual ErrorCode NPV(double &Val, Rates &RL, CCY Ccy) = 0

Calculates the net present value of the trade or portfolio in the given currency. The Rates object must contain spot rates for currency conversion to the valuation currency if this is necessary.

virtual ErrorCode NPVwD(double &Val, Rates &RL, CCY Ccy)

Same as the foregoing except that the sensitivities are calculated and put into the slots contained in the rates object. This method is implemented at the top level by taking finite differences, but may be overriden if analytic deltas are possible.

Class Trade

Derived from Valuee. Contains data members for the trader, the counterparty, the trade number, the trade type, the maturity date, and if prematurely terminated, the cancellation date.

Methods: includes those of Valuee plus

virtual void Description(VarStr &VStr) = 0

Puts a textual description of the deal into the variable-length string object supplied. This is for the purposes of seeing the deal in a blotter, and should pack as much information into the one line as possible.

virtual ErrorCode Save(DbConn *DbC, unsigned short PortfolioID)

Save the trade in the given portfolio in the given database.
Retrieving from the database is however not done in the same way: sub-classed methods cannot be used until the object is already instantiated. Instead, in the implementation used, the class ID of the OLE wrapper object is stored in the database, and using CoCreateInstance, an OLE wrapper to the specific (sub-classed) Trade object is instantiated. The Retrieve method of the wrapper then fills in the Trade object from the database tables.

Class Collection

A generic collection of other objects, that may be connected to a database. If it is, then it generally maps to a single table, and the Add and Delete methods of the collection trigger SQL INSERT or DELETE operations. The data members include details of the audit trail if one is supplied and an optional function for use by qsort that maintains the order of elements in the collection.

Methods (amongst others):

ErrorCode Add(RefCountedObject *RCO)

Add in the correct place according to the order of the list, the new object.

ErrorCode Delete(unsigned long index)

Remove the given element.
Class Trades

Derived from Valuee and Collection. Just an array of Trade objects.
Class Portfolio

Also derived from Valuee and Collection, but is a self-collection, i.e. the components of the collection are themselves Portfolio objects. Contains a pointer to a Trades object as a data member. Other data members are the owner (a person) and the access type (read only, read/write, etc.).

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.