Derivatives Algorithms

The following sections are included:

• Contents

In June 1994, I spent my last thousand dollars on two suits and a plane ticket to New York. I landed a job in Fixed Income Analytics at Bankers Trust; I had hoped for an offer fromEnron, but thatwas slowtomaterialize. I quickly realized that I had been hired to produce notmathematics but algorithms…

This is not a book about mathematical methods, nor does it explain any class of models in real detail. (For that purpose, consider the magnum opus of Leif Andersen and Vladimir Piterbarg, on Interest Rate Modeling.) Rather, it is an exposition of the methods needed to describe derivatives and structured financial products in a precise and flexible way, so that both their innate complexity and the complexity of the models for pricing and hedging them them can be controlled. Separation of concerns is a crucial part of this control, and one of our major aims is to demonstrate where this separation may best be accomplished. We also concentrate on the development of reusable components, so we can always understand a given program in terms of large and well-understood atoms; and on a style which encourages clear and concise expression of our intentions.

Some of the code we must produce is nearly independent of the task at hand: the jobs of translating inputs to our own formats, storing and fetching highlevel objects, and communicating error messages are all crucial (though each single instance of doing so is less than fascinating). Our first task is to create a supporting system to allow these jobs to be done well, with minimal unnecessary work and boilerplate code.

Linear algebra, especially matrix decompositions, and efficient computation with arrays are constant necessities. By carefully structuring the interfaces of these routines, we can write more flexible and safer code.

To support both debugging of complex tasks and distributed computing, we will need to provide object persistence – the ability to save an object or transfer it to a different process, generally by writing it to a file or database.

Some languages offer built-in support for this, or have a sufficiently simple object model that a general-purpose persistence library can be built. In the Python language, for example, any object is essentially a nested hash table, and the "pickle" module provides object-to-file conversions for most objects. Erlang goes even further, with built-in concurrency and little distinction between persisted and in-process data. However, partly because of the constraints required to support this universality, these languages are not really suitable for our purposes.

More general-purpose languages often come with libraries which support persistence of objects built within that library: examples include CL-STORE for LISP and MFC for C++.

However, there are significant advantages to writing our own persistence methods, which as far as I am aware have not been replicated in any widely available library. Foremost among these is the automatic maintenance of documentation, just as for our generated public interface. Also, serialization is nearly conceptually identical to inspection, and we will support both without duplicative code.

Like any large software project, our library will evolve through time and will need constant upkeep to remain reliable. In attempting to do more tasks with less code, we are inevitably forcing code to be used in many different contexts, so a bug will often only be manifest in some uncommon or unexpected use case. Also, testing of the interaction between high-level components requires a great deal of low-level work, even if the low-level components are known to be reliable.

Besides the vector and matrix computations discussed in Ch. 4, we require a good deal of other mathematical functionality, some of it quite specialized to the field of derivatives.

When we attempt to apply mathematical techniques to financial instruments, there is a constant tension between the “pure” mathematical regime – of continuously compounded rates, uniform daycounts, and so forth – and the idiosyncratic real world, with its profusion of entrenched conventions. This is particularly pronounced in fixed income, but is an issue for any underlying. The unifying goal of schedule code is to bridge this divide by providing to the mathematical side the tools to encapsulate these conventions and quarantine them so we can get on with our real work. We make no pretense that schedules are interesting, but they are crucial.

A derivative trade is a contractual agreement to exchange cashflows or other securities in the future, based on observed events in the market. To begin understanding the common features of such trades, we imagine ourselves in the far future, working out the payments to which each party is contractually bound.

Through this thought experiment, we see a clear distinction between the market events – which enter the public record as historical fixings – and the terms of the trade, which describe the computation of a payout based on these fixings. Such historical fixings are not one-time events, but periodic (usually daily) snapshots of some ongoing process, which we call an index.

Indices, defined in this way, have two crucial properties. First, they stand at the interface – to a large extent, they define the interface – between trades and models. Once a model can simulate the dynamics of indices and of discounting, it need give no further consideration to trades.

Second, indices are a bridge uniting past and future. The computation of a payout from a set of index fixings is defined by the termsheet of a trade, and we will perform the same steps whether we are testing a scenario of the future, performing a postmortem on the past, or pricing and administering a live trade.

We have displayed an array of tools underpinning the creation of trades, forward curves, models and numerical pricers. To put these pieces to use, we have to define the target. A trade, for example, will be useful if it does certain trade-like things: but what precisely are those?…

The fastest way to understand the protocols for numerical pricing is to look at a few trades, which of course will implement these protocols. We will return to pricing in those special cases where a closed form is available, in Ch. 14.

The word curve is a term of art, referring to a deterministic function of time used in pricing some set of trades. The prototypical example is the yield curve, originally referring to bond yields as a function of maturity but now used for forward Libor rates.

One subtle difference between these usages is worth noting. The bond yields are essentially "raw" market data, depending only on the quoted price in an unambiguous way. Forward rates fitted to some set of quoted instruments, however, are not directly quoted and not fully defined (also see Sec. 7.4). As a rule, we will focus on this latter type of curve.

To provide numerical pricing, models and their SDE's (see Sec. 10.2.1) must implement the protocols of Ch. 10. Much of this functionality can be provided by the base SDE_ class; or, if the implementation does not require access to private members, in supporting free functions. The latter approach, which separates functionality from the requirement for a particular sort of this pointer, is preferred.

Rather than plunge directly into these implementations, we explore the implementation of a specific simple model. In the process we will develop a mix of specific and general functionality; the latter should be easily recognizable, and will mainly be collected in ModelImp.cpp.

All our discussion so far has been centered on generic numerical pricing, where models and trades can communicate at arm's length. We now turn to specialized semianalytic methods, which use knowledge of both the trade and model to rapidly obtain the price, or a close approximation thereto.

For example, a lognormal price diffusion with deterministic interest rate and dividend yield leads to the Black-Scholes pricing formula for equity options; and we need solve no PDE in the process. If the deterministic dividend yield is replaced by a set of discrete payments, or a richer parametrization of the dividend curve, then moment-matching methods can yield an inexact but quite accurate price.

As the models grow richer, the semianalytic methods must be correspondingly more sophisticated and complex. This is the "high art" of the quant world. In this volume, we will focus more on the frame: how can we make these approximations available without sacrificing genericity?

To manage a derivatives book, we must measure its exposure to market prices and to less observable parameters – its risks – systematically and accurately. If we are to retain flexibility of models, or aggregate risks which are not all measured using the same models, we must ensure that risk is not mapped to model-specific parameters. Thus we emphasize the creation of uniform specifications of a change to a model, which describe a market rather than a model-specific change. Models have the responsibility of responding appropriately to changes thus described; we then think of risk computation as mostly a process of repeated valuation with a series of slightly different models.

The following is adapted from my prepared text for a speech to a plenary session of the ICBI Global Derivatives conference in 2012, an audience of quant practitioners and academics…

The following sections are included:

• Acknowledgements and Further Reading
• Index