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

While scripted payoffs are now part of the standard toolkit for the structuring of derivatives, it does not appear to be widely used yet in the wider context of xVA, CCR, VAR, FRTB, capital charges, or other related calculations. This is an unfortunate oversight. Market risk, value adjustments, and capital calculations over large heterogeneous portfolios of transactions are best conducted when all cash‐flows from all transactions are represented in a consistent manner, which the software can understand, analyze, and otherwise manipulate. This is exactly what scripting offers, for a small performance cost if implemented correctly.

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.