actual parsing (that turns a text script into a collection of expression trees) is left to the appendix.
Then, we introduce in chapter 3 the 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 5 and take this opportunity to illustrate how a core extension is made to the language.
NOTES
1 1 Continuous 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 2 This 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 3 We 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.
CHAPTER 1 Opening Remarks
INTRODUCTION
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:
| STRIKE | 100 |
| 01Jun2021 | opt pays max( 0, spot() ‐ STRIKE) |
for a 1y European call with strike 100, or
| STRIKE | 100 |
| BARRIER | 120 |
| 01Jun2020 | vAlive = 1 |
| Start: 01Jun2020 | |
| End: 01Jun2021 | if spot() > BARRIER then vAlive = 0 endIf |
| Freq: weekly | |
| 01Jun2021 | opt pays vAlive * max( 0, spot() ‐ STRIKE) |
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;
