Antoine Savine

Modern Computational Finance


Скачать книгу

target="_blank" rel="nofollow" href="#u7f9007e7-2d5e-54cd-b79b-ec2095ed583b">Part V introduces the application to xVA, which is further covered in our upcoming dedicated publication. The code for xVA calculations is not provided.

      Further, a CVA (similarly to other xVAs and other regulatory calculations) is a real option that a bank gives away any time it trades with a defaultable counterparty. That option is a put on the netting set, contingent to default. It is therefore an exotic option with a complex 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.

      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))

      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.

      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