Antoine Savine - Modern Computational Finance

We split the implementation in five steps.

First, we describe in chapter 2the data structure for the internal representation of the script, ready for evaluation and other forms of visits. We will use expression trees as a data structure, and we describe these in detail. The discussion and code for the actual parsing (that turns a text script into a collection of expression trees) is left to the appendix.

Then, we introduce in chapter 3the evaluator that values expression trees during simulations, pre‐processors that optimize evaluation before simulations, and other visitors , objects that traverse expression trees and perform calculations and actions depending on the visited node, while maintaining internal state. We explain the visitor pattern , a common framework for all types of visitors, which encapsulates traversal logic and makes the development of specific visitors particularly simple.

Third, in chapter 4, we bring the pieces together and develop a (very) basic model to test the scripting library.

Fourth, we improve our framework with the addition of the keyword pays in chapter 5and take this opportunity to illustrate how a core extension is made to the language.

1 1Continuous barriers are somehow outside of this logic and require specific support that is not discussed. Support for early exercises is discussed in chapter 15.

2 2This is an overly simplified version of the autocallable product and one that is purposely structured to illustrate the implementation and application of scripting. It is significantly different from actual autocallable transactions, which can also be scripted with our language, but in a more complicated manner.

3 3We make some arbitrary choices regarding the syntax of our scripting language. Readers can easily implement their own preferred grammar once they are comfortable with the idioms explained here.

In the early stages of derivative markets, dedicated models were typically put together to value and risk manage new transaction types as they emerged. After Black and Scholes [5] published in 1973 a closed‐form formula for European options under a constant volatility assumption, alternative models—like the Cox‐Ross‐Rubinstein binomial tree [7] in 1979, later replaced by more efficient finite difference grids—were developed to value American options under the same assumptions.

As trading in derivatives matured, the range of complex transactions expanded and models increased in complexity so that numerical methods became necessary for all but the simplest vanilla products. Models were typically implemented in terms of finite difference grids for transactions with early exercise and Monte‐Carlo simulations for products with path‐dependency. Notably, models increased in dimension as they grew in complexity, making grids impractical in most cases, and Monte‐Carlo simulations became the norm, with early exercises typically supported by a version of the Longstaff‐Schwartz regression‐based algorithm [22]. Sophisticated models also had to be calibrated before they were used to value and risk manage exotics: their parameters were set to match the market prices of less complex, more liquid derivatives, typically European calls and puts.

Most of the steps involved—calibration, Monte‐Carlo path generation, backward induction through finite difference grids—were independent of the transactions being valued; therefore, it became best practice to implement models in terms of generic numerical algorithms, independently of products. Practitioners developed modular libraries, like the simulation library of our publication [27], where transactions were represented in separate code that interacted with models to produce values and risk sensitivities.

However, at that stage, dedicated code was still written for different families of transactions, and it was necessary in order to add a new product to the library, to hard code its payoff by hand, compile, test, debug, and release an updated software.

The modular logic could be pushed one step further with the introduction of scripting languages , where users create products dynamically at run time. The user describes the schedule of cash‐flows for a transaction with a dedicated language specifically designed for that purpose, for example:

for a 1y European call with strike 100, or

for the same call with a 120 (weekly monitored) knock‐out barrier. 1

The scripts are parsed into expression trees , and visited by an evaluator , a particular breed of visitor , who traverses the trees, while maintaining the internal state, to compute payoffs over the scenarios generated by a model:

All of this is explained in deep detail with words and code in part I.

With scripting, finance professionals were able to create and modify a product on the fly, while calculating its price and risk sensitivities in real time. The obvious benefits of such technology quickly made it a best practice among key derivatives players and greatly contributed in itself to the development of structured derivatives markets.

Early implementations, however, suffered from an excessive performance overhead and a somewhat obscure syntax that made scripting inaccessible to anyone but experienced quantitative analysts and traders. Later implementations fixed those flaws. The modern implementation in this publication comes with a natural syntax, is accessible to non‐programmers, 2 and its performance approaches hard‐coded payoffs.

This publication builds on the authors' experience to produce a scripting library with maximum scope, modularity, transparency, stability, scalability, and performance.

Importantly, our implementation transcends the context of valuation and sensitivities; it offers a consistent, visitable representation of cash‐flows that lends itself to a scalable production of risk, back‐testing, capital assessment, value adjustments, or even middle office processing for portfolios of heterogeneous financial transactions. We also focus on performance and introduce the key notion of pre‐processing , whereby a script is automatically analyzed, prior to its valuation or risk, to optimize the upcoming calculations. Our framework provides a representation of the cash‐flows and a way of working with them that facilitates not only valuation but also pre‐processing and any kind of query or transformation that we may want to conduct on the cash‐flows of a set of transactions.

Scripting makes a significant difference in the context of xVA, as explained in part V, and more generally, all regulatory calculations that deal with multiple derivatives transactions of various sophistication, written on many underlying assets belonging to different asset classes. Before xVA may be computed over a netting set, 3 all the transactions in the netting set must be aggregated. This raises a very practical challenge and a conundrum when the different transactions are booked in different systems and represented under different forms. Scripting offers a consistent representation of all the transactions, down to their cash‐flows. Scripted transactions are therefore naturally aggregated or manipulated in any way . A key benefit of scripted cash‐flows is that scripts are not black boxes. Our software (more precisely, the visitors implemented in the software) can “see” and analyze scripts, in order to aggregate, compress, or decorate transactions as explained in part V, extract information such as path‐dependence or non‐linearity and select the model accordingly, implement automatic risk smoothing ( part IV), or analyze a valuation problem to optimize its calculation. Our library is designed to facilitate all these manipulations, as well as those we haven't thought about yet .