Antoine Savine - Modern Computational Finance

Such shortcut may be relevant for valuation, 5 because it is sometimes economically equivalent to receive the PV of the cash‐flows on the exercise date, or become entitled to these cash‐flows, paid later on their respective payment dates. But this shortcut only works in particular contexts and with particular models. When credit risk is considered, it is no longer equivalent to exercise into the swap or to cash settle the option. In particular, this script is not correct in the context of CVA.

The correct script for a swaption must describe the schedule of the cash‐flows of the underlying swap and use a proxy to estimate the PV of the future cash‐flows of the swap at the exercise date to make an exercise decision. A proxy is an estimate of the transaction's value on the exercise date as a function of the model's state variables on that date. Proxies are typically produced by regression, in a process designed by Carriere [6] and Longstaff‐Schwartz [22], and discussed in chapter 15and, more extensively, in our upcoming, dedicated publication.

When we script payoffs, we lose the information of how they are pieced together out of the actual cash‐flows. That may seem irrelevant for valuation, so it may be tempting to script payoffs directly, and that may even be thought of as a performance improvement, but, in a wider context where it is necessary to read the actual cash‐flows and, for example, figure out how they are fixed and when they are paid, then such information is no longer available. Therefore, it is best practice, in modern finance, to always script the raw cash‐flows and leave the optimization to the implementation.

A well‐designed scripting implementation should provide facilities to extract information out of the scripted transactions, such as the dates when payments may occur, the collection of contingent and non‐contingent (deterministic) payments, the identification of European, path‐dependent and/or early exerciseable cash‐flows, the dependency of cash‐flows to underlying assets and market variables, the dependencies between different components of a transaction or portfolio, and much more. Such information may help optimize the setup of the model before it runs valuation. It can also be used for middle office processing, back‐testing, or forward‐testing like for FRTB or PRIIPS regulatory calculations. Smoothing with fuzzy logic ( part IV) requires access to raw cash‐flows and may fail if additional (sharp) logic is included in the script. Visitors may even modify the script after parsing, for example, to compress a large amount of heterogeneous cash‐flows into a “super‐swap” that pays the combined cash‐flows from multiple transactions on evenly spaced dates, or decorate a set of cash‐flows with the “payoff” of an xVA ( part V), but only if the actual, raw cash‐flows are scripted without additional shortcuts.

The key notion here is that a script is not a black box to be valued against scenarios, but a data structure that holds cash‐flows and is open to visitors . Valuation is only one form of visit among a multitude of others that extract information from cash‐flows and modify them in various ways. And for that purpose, it is necessary to script the raw cash‐flows only.

In a strict valuation context, the computation of the value and risk sensitivities of a script requires a model. Models are the primary focus of mathematical finance and are discussed in a vast number of textbooks, publications, and lectures. The clearest and most comprehensive description of the design and implementation of derivative models can be found in the three volumes of [20].

This publication is not about models. We develop a model agnostic scripting library that is written independently of models and designed to communicate with all models that satisfy an API discussed in section 3.7 (where we show that the API can also be added to some existing models with an adapter class). For our purpose, a model is anything that generates scenarios , also called paths in the context of Monte‐Carlo simulations, that is, the value of the relevant simulated variables (essentially, underlying asset prices) on the relevant event dates (when something meaningful is meant to happen for the transaction, like a fixing, a payment, an exercise, or the update of a path dependency). Our library consumes scenarios to evaluate payoffs, without concern of how those scenarios were produced.

Scripting libraries are also typically written to be usable with a number of numerical implementations, either by forward induction like Monte‐Carlo simulations or backward induction like finite difference grids. In order to avoid unnecessary confusion, our book focuses on forward induction with Monte‐Carlo simulations, by far the most frequently used valuation context today. To further simplify our approach, we only consider path‐wise simulations. This means that simulations are provided one path (for all event dates) at a time. The model is, to us, an abstract object that generates multiple scenarios (possible evolutions of the world) and communicates them sequentially for evaluation.

An alternative that we don't consider is step‐wise simulation, where all paths are computed simultaneously, date by date. The model first generates all the possible states of the world for the first event date, then moves on to the second event date, and so on until it reaches the final maturity. Step‐wise simulation is natural with particular random generators, control variates (when paths are modified after simulation so that the expectation of some function matches some target), and, more generally, calibration inside simulations as in the particle method of [16].

The concepts and code in this book apply to path‐wise Monte‐Carlo simulations, but they can be extended to support step‐wise Monte‐Carlo and backward induction algorithms. 6 This is however not discussed further. Note that path‐wise Monte‐Carlo includes deterministic models for linear products (these models generate a single path where all forwards are realized) and numerical integration for European options (where each path is a point in the integration scheme against the risk neutral probability distribution of the relevant market variable).

Monte‐Carlo simulations are explained in detail in [19] [15], and the dedicated chapters of [20], as well as our publication [27], which provides a framework and code in C++, and focuses on a parallel implementation.

We refer to the figure on page 15 for an illustration of the valuation process. The model produces a number of scenarios; every scenario is consumed by the evaluator to compute the payoff over that scenario. This is repeated over a number of paths, followed by an aggregation of the results. The evaluator is the object that computes payoffs (sums of cash flows normalized by the numeraire, which is also part of the scenarios, as described in chapter 5) as a function of the simulated scenarios. The evaluator conducts its work by traversal of the expression tree that represents the script, while maintaining an internal stack for the storage of intermediate results. We describe the evaluator in detail in section 3.6.