Modern Computational Finance. Antoine Savine

They cannot be pre‐processed, queried, or transformed. Such a framework may have merit for the risk management of exotics (if performance and operational risk are not an issue), but it is not suitable for our purpose. This is actually the exact opposite of our design, whose purpose is to provide a representation of cash‐flows that is transparent to all kinds of visitors across a system.

We also made the choice to develop a self‐contained implementation in standard C++11. We find it unnecessary to recourse to third‐party libraries to parse, represent, or visit scripts. Self‐contained code offers better control over the algorithms and makes it easier to maintain and extend the code without having to rely on another party. Further, automatic adjoint differentiation (AAD), a technique used to obtain derivative sensitivities with amazing speed, is best implemented when the source code is available. This in itself is reason enough to refrain from using third‐party black boxes. Furthermore, once the fundamental designs and algorithms are well understood, it is natural and relatively painless to produce elegant, efficient, self‐contained C++ code, especially with the modern facilities offered by C++11. In particular, we demonstrate in the appendix to section I that the parser (part of the code that turns text scripts into expression trees) is implemented in standard C++ without major difficulty or the recourse to a third‐party library. The source code is provided in our repository.

      AAD is covered in detail in our publication [27], together with professional C++ code.

1.7 SCRIPT TEMPLATES

      Scripting languages are designed to facilitate the description of any derivatives transaction, and, indeed, all transactions must be scripted to benefit from a common representation within a derivatives system. That means that the pricing, booking, and otherwise manipulation of every transaction, down to vanilla swaps and European options, is conducted with scripts. Traders typically manipulate hundreds to thousands of vanilla swaps or European options every day. Although modern scripting is accessible and user‐friendly, it is still much easier, faster, and less error prone to fill a few fields on a form, like start and end dates, and a fixed coupon for a swap, than to write a script like:

STARTDATE	01Jun2020
ENDDATE	01Jun2030
FLFREQ	3m
FLBASIS	act/360
FLIDX	L3M
FIXFREQ	1y
FIXBASIS	30/360
CPN	2%
Start: STARTDATE End: ENDDATE Freq: FLFREQ Fixing: start‐2bd	swap pays ‐libor( StartPeriod, EndPeriod, FLBASIS, FLIDX) * cvg( StartPeriod, EndPeriod, FLBASIS) on EndPeriod
Start: STARTDATE End: ENDDATE Freq: FIXFREQ Fixing: start‐2bd	swap pays CPN * cvg( StartPeriod, EndPeriod, FIXBASIS) on EndPeriod

For those frequently traded products, it is practical to use templates, implemented on spreadsheets or higher level languages, that generate the script automatically out of a small number of inputs.

      Templates are typically used for vanilla swaps, European options or first‐generation exotics (short‐term forex barrier options). They combine the practicality of hard‐coded transactions with the benefits of scripting. Many transactions are also regarded as “almost” vanilla swaps, “almost” European, or “almost” standard barriers. In these cases, it is most practical to start with a template and modify the auto‐generated script by hand. Templates are also useful when some transactions are booked in a separate system, which is often the case for, say, vanilla swaps. To aggregate these transactions with the rest of a netting set for the calculation of an xVA, for example, those transactions can be scripted on the fly with template code.

      This logic may be pushed a step higher, with the design of GUIs, programmed in a language like C#, so that finance professionals without programming expertise, or customers, may build transactions by assembling blocks on a graphical representation of the transaction. This graphical representation is then automatically turned into the corresponding script.

      Writing templates is trivial and a template can be implemented directly in a spreadsheet without code. To write a GUI platform for the design of transactions and translate that graphical representation into a script is perhaps more advanced. It certainly requires an expertise in GUI design, something out of the scope of this publication but covered in many recent C# or Python textbooks.

NOTES

      1 1 Depending on scripting grammar, that barrier could also be written in functional form:STRIKE100BARRIER12001Jun2020append ( vFixings, spot())Start: 01Jun2020End: 01Jun2021append ( vFixings, spot())Freq: weekly01Jun2021opt pays (max( vFixings) < BARRIER) * max( 0, spot() ‐ STRIKE)We develop a classic, procedural scripting language in what follows, although readers can easily apply the logic and code of this book to design a functional scripting language like in the script above, or implement the grammar of their choice.

      2 2 We develop a scripting language similar to a high‐level language like Python, not a programming language like C++. Classic constructs like variables, loops, and conditions are part of the language, as well as special keywords for the description of cash‐flows, such as spot(), which references simulated market prices. Of course, this is one particular choice and different rules are implemented with minor modifications, for example, a C/C++ inspired syntax or a functional grammar without conditionals or variables.

      3 3 All transactions against a counterparty.

      4 4 Stochastic volatility models are covered in many textbooks, including [21] [13], [3], or our lecture notes [26].

      5 5 It is indeed relevant for calibration.

      6 6 We can accommodate step‐wise MC in a trivial, if memory‐inefficient manner: store the paths generated step‐wise and deliver them path‐wise to the script evaluator.

      7 7 The model also generates a value for the numeraire under which it performs the simulation, although that numeraire is a scalar value (per event date) that must be simulated and communicated in all circumstances.

      8 8 Any condition can be evidently expressed under one of these forms; for example, is obviously the same as with . We built a pre‐processor to transform all conditions under these canonical forms.