Читать книгу Modern Computational Finance - Antoine Savine - Страница 10

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,⁵ 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.