payoff written on the sum of all the cash‐flows of all the transactions in a netting set. This is however still an option, and as such, it can be scripted like any other transaction. Scripting is ideally suited in this context, both for the representation of the cash‐flow of the underlying transactions and the description of the value adjustments themselves. We explore the details in part V and will extend that discussion in our upcoming publication dedicated to xVA.
As exotic transactions fell out of favor in the aftermaths of the 2008 global crisis, some practitioners believe that scripting lost relevance. That could not be more wrong. From the reasons enumerated, scripting is more relevant now than ever, not only for exotics but more importantly today as the centerpiece of correctly designed systems for the calculation of risks, value adjustments, and capital charges for large heterogeneous portfolios.
We therefore believe that scripting is not limited to an external interface for users to conveniently create transactions on the fly. Scripting does offer such convenience, but its main purpose is to represent transactions internally as collections of cash‐flows consistently accessible to all components in a system. Code (actually, visitors that are part of the code) can “see” the cash‐flows and manipulate them in a number of ways. Evaluation is just one such manipulation. The design of our scripting library in part I is driven by such considerations.
1.2 SCRIPTING IS FOR CASH‐FLOWS NOT PAYOFFS
What did lose relevance is scripting for exotics only. Scripting must be rethought today, no longer as a means of valuing complex transactions but as a way to represent cash‐flows so that these cash‐flows may be visited from various components of system and analyzed and modified in various ways, including, but not limited to, valuation. For this purpose, it is essential that it is the actual cash‐flows that are scripted and not option payoffs.
For example, a receiver swaption with physical settlement would frequently be represented as a European option on the PV of the underlying swap at the exercise date. This would produce a script resembling:
| exerciseDate | swaption pays max( 0, swapPv (startDate, endDate, fixCpn, fixFreq, fixBasis, floatRef)) |
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 15 and, more extensively, in our upcoming, dedicated publication.
| Start: start DateEnd: end DateFreq: float FreqFixing: start‐2bd | if vAlive = 1 then swaption pays ‐libor( StartPeriod, EndPeriod, floatBasis, floatRef) * cvg( StartPeriod, EndPeriod, floatBasis) on EndPeriod endIf |
| Start: startDate End: endDate Freq: fixFreq Fixing: start‐2bd | if vAlive = 1 then swaption pays fixCpn * cvg( StartPeriod, EndPeriod, fixBasis) on EndPeriod |
| tradeDate | vAlive = 0 |
| exerciseDate | if PV( swaption) > 0 then vAlive = 1 endIf |
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.
1.3 SIMULATION MODELS
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
