A brief history of scripting for financial derivatives by Antoine Savine
Jesper Andreasen and I (Antoine Savine) are writing a book on scripting and applications to risk management and counterparty valuation management (CVA) and, more generally, regulatory calculations like FRTB (fundamental review of the trading book) or CCR (counterparty credit risk):
As an introduction, Jesper compiled a personal history of working with scripting, reproduced below.
I also posted a short presentation with some of the main themes covered in the book:
My life in scripting, by Jesper Andreasen
Antoine came to General Re Financial Products in London in 1998 with a lot of youthful spirit and many refreshing ideas. One of them was a financial payoff language called SynTech (Syntactic interpreter Technology). I am not sure that I was immediately convinced but when he connected it to a real model and priced some structures that we made up on the fly, I was hooked. I learned SynTech in hours but it took me months to figure out how it was put together. A process that forced me to learn structured programming in general and C plus plus in particular.
As always, it was a general struggle to keep up with the financial innovation, and constant re-coding of new payoffs was a painful and error prone process. We had been toying with a cocktail of Visual Basic for scripting of the payoffs, and scenarios of future prices generated by C plus plus programs. However, the implementation was slow, model specific, hard to use, and generally more elephant than elegant.
SynTech, on the other hand, was easy to use with a readable simple Python like syntax, and thoroughly built for speed and versatility. Scripts were pre-processed to cache and index static information for maximum pricing speed, and its API allowed a seamless hook-up with any dynamic model in our library. In fact, it took Antoine very little time to hook up SynTech to our then newly developed Libor Market Model.
Further, it was clear that SynTech could be extended to perform various life cycle tasks such as fixings and payments to limit the manual burden on the back office in the handling of exotic trades. SynTech implemented a clear separation between instrument and model.
From then on, I have only used scripting languages as the interfaces for all the models I have developed. And when I need to price something I rarely use anything else than naked scripting. The scripting language that I have used and developed have all had a syntax very close to the original SynTech. The developments that I have done have mainly been underneath. Remarkably, SynTech’s original 50 keywords still cover the ground.
SynTech was inspired by developments Antoine had seen at previous occupations, most notably the GRFN system at Paribas. Other young quants spread out from Paribas and seeded ideas and developments of scripting languages at other institutions. For example at UBS, Commerzbank, Nikko-Salomon, Citi and Reech Capital.
Paribas’ GRFN developed by Guillaume Amblard and Societe Generale’s OptIt by Jean-Marc Eber were as far as we know the first scripting languages that were used on an industrial scale. Jean-Marc Eber went on to set up the company Lexifi which to this date supplies the industry with scripting technology.
GRFN and OptIt emerged in the mid 1990s. There were, for sure, other earlier attempts to develop scripting languages, most notably various uses of the LEX-YACC suite of tools for creating languages. Emmanuel Derman mentions such efforts in passing in My Life as a Quant and I have heard of similar experiments at JP Morgan. However, to my knowledge, none of these made it to large scale production.
In 2001, I went to Bank of America in London, where I ganged up with James Pfeffer and developed Thor. The main innovation of Thor was the use of the visitor pattern technology which later was instrumental in using scripting as the back bone for XVA and regulatory calculations. The main idea of the visitor pattern is to have visitors that visit the cash flows for different purposes: pre-processing, valuation, dependency graph generation, compression, decoration, etc. The diverse use of visitors shows that development of your own scripting language is necessary. Python or C\# can not be visited.
In 2002–2005 I worked for Nordea in Copenhagen where we developed a scripting language called Loke. The main innovation during this period was the integration of American Monte-Carlo techniques with Loke, including upper bound techniques implemented by Ove Scavenius.
2005–2008 I was back with Bank of America, where I found the Thor language to be heavily used by the structured interest rate and equity desks. Often they used a macro language called Sif, developed by Mohan Namasivayam, to generate Thor scripts.
At Danske Bank that I joined in 2008 and left in 2018, the scripting language is called Jive. Jive is used for everything traded at Danske Bank: from vanilla swaps to mortgage bonds to equity exotics to regulatory capital. Jive is even used in the yield curve calibration. This is the only bank that I know of that uses a scripting language so consistently. Developments have mainly concentrated around aggregation, compression and decoration used for XVA and regulatory calculations. Here, we have heavily leveraged on the visitor pattern technology. But we have also done significant work on Automatic Adjoint Differentiation (AAD), multi threading, and fuzzy logic to stabilize risk calculations. Antoine joined Danske in 2013, and since then he has played a key role in these developments. In 2015, we received Risk Magazine’s In-House Risk System of the Year award for our XVA system. The AAD and the speed of the calculations achieved by the XVA system have received a lot of attention in the quant community, but the scripting and visitor pattern technologies are actually the unsung heroes that have made all of this possible.
To document how we did XVA on an iPad Mini without thoroughly describing our approach to scripting would be wrong and not give the reader the full picture. I was therefore very happy when Antoine told me he was going to write a book on scripting. This would give us the opportunity to finally get our work on scripting languages documented, and pave the way for fully documenting our XVA system.
There is a number of reasons why the story of scripting has not been told before. Among these:
- It’s not mathematics, but software design. Which is actually something that we do every day but not something that we usually write about.
- It’s a complex and relatively long and winding story that can not easily be summoned in a few punch lines. On top of this it contains subjects that most people haven’t even heard about such as visitors and pre-processors.
- It’s a hard sell to change conventional wisdom that scripting is only for exotics and has no relevance in post crisis finance. Actually, scripting is more relevant now than ever, because banks are under tough regulatory and cost pressures.
- It’s very C plus plus and as such not following the current trend of lighter languages such as Matlab and Python backed by GPUs running parallel instructions in C.
- The subject is still very much alive: whenever we start documenting our efforts, we always get new ideas that we can do with scripting. Which in turn tends to take away focus from documenting past glories.
My next employer is Saxo Bank and the scripting language there will be daWord.
Jesper Andreasen, June 2018