main-content

## Über dieses Buch

Many introductory books on mathematical finance also outline some com­ puter algorithms. My goal is to contribute a closer look at algorithmic issues that arise from complex forms of the underlying pricing models-issues many practitioners need to solve sooner or later in their careers. This book takes such a close look at uncertain volatility models, an exten­ sion of Black-Scholes theory.It discusses applications to exotic option portfo­ lios with barriers and early exercise features. It describes an object-oriented C++ solution, included in source code on the accompanying CD. Practitioners and students who need to build analytic software libraries may benefit from reading this book and studying the software. The book focuses on a family of mathematical models, while in the field one encounters greater variation in instrument properties. In both cases mathematical and financial knowledge must be complemented by good programming skills to produce the best system. Analytic software needs design-a central message of the later chapters of this book. This book has come out of my Ph.D. thesis. I am very grateful to my academic advisor, Marco Avellaneda of New York University, who taught me mathematical finance and uncertain volatility. Computational finance be­ came exciting for me because Marco encouraged an algorithmic approach to uncertain volatility. I thank Afshin Bayrooti, Vladimir Finkelstein, and Antonio Paras for giving valuable feedback. Antonio is the co-inventor of the original uncertain volatility model, A-UVM. Richard Holmes has found a crucial bug in an early implementation of the software.

## Inhaltsverzeichnis

### 1. Introduction

Abstract
There is a growing collection of literature on standard derivative pricing mod- els that, to a more or lesser degree, contain recipes on how these models are implemented on a computer. In many cases recipes are explained on a very high level or focus on only one link in the chain of components that make up a software system for derivatives pricing.
Robert Buff

### 2. Notation and Basic Definitions

Abstract
ℕ denotes the nonnegative integers. ℝ denotes the real numbers. ℝ+ denotes the nonnegative real numbers. ℝ++ denotes the strictly positive real numbers.
Robert Buff

### 3. Continuous Time Finance

Abstract
This chapter gives a brief survey of continuous time finance. We categorize diffusion models according to the nature of their volatility coefficient. Models whose volatility coefficient does not exhibit randomness are treated in Sect. 3.1. Models whose volatility coefficient follows a stochastic process are discussed in Sect. 3.2.
Robert Buff

### 4. Scenario-Based Evaluation and Uncertainty

Abstract
The following problems arise in practice:
• A concrete instance of the selected equity, FX or interest rate model must be chosen, by instantiating its volatility and other coefficients with plausi- ble values. For example, the Black-Scholes model dSS t +∂dW might be instantiated to dS = 0.05 S t + 0.3 dW.
• Once instantiated, models often prove too weak to represent the market dynamics adequately; in the case of Black-Scholes, this deficiency shows itself in the often cited implied volatility smile.
Robert Buff

### 5. A Lattice Framework

Abstract
Nonlinear Black-Scholes models for worst-case scenarios require two kinds of algorithmic techniques:
1.
Finite difference methods combined with dynamic programming are used to solve individual PDEs of type (4.9).

2.
A collection of PDEs needs to be solved in the right order if exotic options with barrier or American features are involved. Solutions of subordinate PDEs serve as boundary data for PDEs higher up in the hierarchy. (There is only one PDE if the portfolio under consideration contains only vanilla options.)

Robert Buff

### 6. Algorithms for Vanilla Options

Abstract
Vanilla options are standard European calls and puts on the underlying asset. Before we discuss algorithms for barrier and American options we illustrate uncertain volatility for portfolios of vanilla options with an example.
Robert Buff

### 7. Algorithms for Barrier Options

Abstract
We consider barrier options that knock out the first time the price S t of the underlying asset crosses a predetermined knock-out barrier b. This is one flavor of barrier options; a timing feature is added in [29], where options loose a fraction of their value for every day they spend above (or below) b.
Robert Buff

### 8. Algorithms for American Options

Abstract
Similar to barrier options, American options may be terminated prematurely sometime between the settlement and the face maturity date. This seems to make the techniques discussed in Chapters 5 and 7 apphcable to portfolios that contain American options as well.
Robert Buff

### 9. Exotic Volatility Scenarios

Abstract
In Chapters 7 and 8, algorithms have been discussed that compute (best) worst-case prices under uncertain volatility scenarios in which ∂(S t,t) and ∂S u,u) are independent for t≠u. In this chapter we extend the notion of uncertain volatility scenarios to include evolutions of the spot volatility that depend on its past history.
Robert Buff

### 10. The Architecture of Mtg

Abstract
Mtg is an experimental software system for the algorithms of Chapters 7, 8 and 9. It consists of components written in C++ and Java.
Robert Buff

### 11. The Class Hierarchy of MtgLib—External

Abstract
MtgLib classes that correspond directly to input parameters and have some intuitive “meaning” to the user are called external. Instances of these classes are defined in MtgLib’s scripting language MtgScript, as defined in Appendix B. The following categories of external classes exist:
• Instruments: Maturity, payoff policy, knock-out policy and early-exercise policy are the dominant orthogonal features of instruments. American/European options with or without knock-out boundaries and with linear of digit al payoff are standardized in MtgLib.
• Portfolios: Instruments are combined into portfolios which generalize some of their properties (the longest maturity, for instance).
• Models: Models consist of specifications of factors and model coefficients, possibly uncertain. A one-factor Black-Scholes model is used in most of this book.
• Model coefficients: They may have their own classes to allow term structure. At this time, piecewise constant volatility and drift coefficients are supported. The volatility coefficient may be uncertain.
• Scenarios: Models and their (uncertain) coefficient s are interpreted according to a prescribed scenario. We have discussed worst- case volatility and volatility scenarios. Some consistency between the model and the scenario is required: if the model incorporates uncertain model coefficients, the scenario must be able to resolve the uncertainty.
• Numerical methods: MtgLib supports explicit or mixed implicit/ explicit finite difference schemes as well as Monte-Carlo simulation. The requirements diverge: while finite difference schemes are based on a collection of lattice instances, Monte Carlo methods require path instances which are treat ed differently. In MtgLib, lattices and path spaces are indeed separate objects.
• Evaluators: At first objects are passively stored in a repository. Concrete pricing operations are only triggered by specifying an evaluator object which lives only while the particular portfolio/model/scenario combination is evaluated. Evalu ators format and output the result.
Robert Buff

### 12. The Class Hierarchy of MtgLib—Internal

Abstract
Most classes in MtgLib are internal—not visible through the scripting lan- guage, of which an example is given in Fig. 11.1. In this section, we discuss the most important category of internal classes: compute engines.
Robert Buff

### 13. Extensions for Monte-Carlo Pricing and Calibration

Abstract
Faithful to the theme of the book, the previous sections 11 and 12 have fo- cused on scenario-based pricing of portfolios of vanilla, barrier and American options for equity and FX Black-Scholes models.
Robert Buff

### A. The Network Application MtgClt / MtgSvr

Abstract
The accompanying CD contains t he network ap plicat ion MgtClt/MtgSvr, demonstrating the algorithms presented in this book. MtgClt is a Java program that is loaded from the command line shell or as an applet from an HTML page. MtgSvr is a server program based on the C++ library MtgLib to which MtgClt connects.
Robert Buff

### B. The Scripting Language MtgScript

Abstract
This chapter describes the syntax of Mtg’s own scripting language, MtgScript. MtgScript is used to describe external objects in the library MtgLib. (The existence of MtgScript is a bit unfortunate: a new implementation would rely on a format based on XML.)
Robert Buff

### C. Mathematica Extensions

Abstract
The component MtgMath consists of two parts:
• The external program MtgMath.exe contains MtgLib and Mathematica’s MathLink interface package.
• The add-on package MtgMath.m contains definitions of Mathematica functions that translate between Mathematica expressions and Mtg’s scripting language.
Robert Buff

### Backmatter

Weitere Informationen