Home

Going functional on exotic trades

Simon Frankau, Diomidis Spinellis, Nick Nassuphis, Christoph Burgard. Going functional on exotic trades. JFP 19(01):27-45.

The Functional Payout Framework (fpf) is a Haskell application that uses an embedded domain-specific functional language to represent and process exotic financial derivatives. Whereas scripting languages for pricing exotic derivatives are common in banking, fpf uses multiple interpretations to not only price such trades, but also to analyse the scripts to provide lifecycle support and more. This paper discusses fpf in relation to the wider trading workflow and our experiences in using a functional language in such a system as both an implementation language and a domain-specific language.

Section 3 is a nice discussion of why Haskell was chosen. Section 4 illustrates one of the major benefits of using DSLs, namely that different backends can be applied to programs written in the DSL, allowing various types of runtime behavior and analysis without the need to re-code each program for each purpose (thus n+m, rather than n*m programs).

Another topic that may be worth discussing is the authors' dislike of point free style.

What we really need, of course, are DSLs for financial regulation (and possibly for specifying various definitions of honesty), but that's a separate issue...

By Ehud Lamm at 2009-05-31 05:55 | DSL | Functional | other blogs | 35180 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Note, by the way, that if

Note, by the way, that if all these instruments and contracts were specified using standardized DSLs, it would have been possible to analyze the state of the financial market using static analysis...

By Ehud Lamm at Sun, 2009-05-31 06:28 | login or register to post comments

Only if all of the

Only if all of the instruments were public. While the contracts on the underlying assets would be public information (from the exchange that handled them), there is no reason to assume that people would disclose the connections between those contracts in the form of these instruments. In particular many traders would not want to disclose their trading strategy.

Analysing the state of the overall market would be an interesting problem if all trades / contracts were expressed as programs. But the first question would be what to analyse? The obvious desire would be to calculate some level of "stability" for the market, but this would be an intrinsically hard problem. Any solution would depend in some parts on analysing the numerical stability of the various algorithms at work in the market place, and in other parts on computing the equilibrium of games between the traders.

It would be interesting to know what other analyses could be attempted. After the recent financial crisis it is intriguing to wonder if we could have analysed "Who has lost their shirt after event X, or in circumstance Y?" A bigger question for the regulators would have been which institutions X & Y have correlations between their assets / positions that depend upon each other?

By Andrew Moss at Sun, 2009-05-31 11:30 | login or register to post comments

You are right, of course.

You are right, of course. There are many additional complications. My basic point is that auditing is hard, and automatic auditing is a great improvement. I am not suggesting that all the data be public (though some of the important data is public as it is), but rather that government regulators can gain access to private data (if the law so demands), and that if this data is specified in languages that allow automatic auditing, so much the better.

By Ehud Lamm at Sun, 2009-05-31 21:46 | login or register to post comments

There is an interesting

There is an interesting parallel between specifying financial transactions as programs, and expressing each action that a business takes as a program in some language. I certainly agree that company reports would have a lot more meaning to regulators if they were in an executable format. Instead they manage to hide what they are up to in 900 pages of natural language. I have a vague memory of a story here on such a language, but I can't remember enough search terms to make Google agree with me.

By Andrew Moss at Sun, 2009-05-31 21:55 | login or register to post comments

Are you thinking of XBRL?

Are you thinking of XBRL?

By Ehud Lamm at Sun, 2009-05-31 23:07 | login or register to post comments

At a guess...

Perhaps you're referring to Nick Szabo's contract language, or my follow-up on Luke Palmer's "Dana" effort.

By Paul Snively at Mon, 2009-06-01 00:17 | login or register to post comments

Yes, this sounds more likley.

Yes, this sounds more likley.

By Ehud Lamm at Mon, 2009-06-01 00:43 | login or register to post comments

Actually I was thinking of

Actually I was thinking of XBRL, but Nick's language is much more interesting and I missed the link to his paper first time round :)

By Andrew Moss at Mon, 2009-06-01 08:51 | login or register to post comments

Still not sure the automatic auditing would have helped, but...

A key problem was that valuation was based on complex models. Straightforward auditing did not help, because the books showed the valuations provided by the models. Beyond that, most market participants did value-at-risk calculations to show how changes in various environmental parameters would affect valuations. Automating the entire process (which likely was done in some cases) only would have given the same results more quickly.
That said, having a consistent DSL may have made a difference, in that it would have made underlying assumptions behind the models clearer. The root of the collapse of the banks was that they all used similar models using (in hindsight at least) very unreasonable assumptions (e.g., continuing long-term growth in housing prices.
By Michael Wax at Tue, 2009-06-02 23:41 | login or register to post comments

Static analysis is not the only possibility

If all instruments and contracts are specified in a standardized executable form that regulators can access, static analysis is not the only way to search for possible cracks in the system. In the short term running simulations is probably a more tractable avenue. Financial firms already seem to be doing this in routine basis (see what we write in section 1.3); all that is needed for more effective regulation could be standardization, transparency, and analysis resources.

By Diomidis Spinellis at Mon, 2009-06-01 06:42 | login or register to post comments

I was baiting you with the

I was baiting you with the static analysis suggestion...

But seriously, do you think what you suggest in your last sentence is practical?

By Ehud Lamm at Mon, 2009-06-01 07:00 | login or register to post comments

Practicality

I'm ashamed to admit that the bait worked amazingly well!

Regarding the practicality of the approach I suggested, I very much doubt it can be put in place; no global system similar in scale and complexity to the proposed one has ever been put into work. Currently, organizations that work on a global scale, say the World Health Organization or the European Aviation Safety Agency, work with aggregate data from countries or industries or with specific incidents. However, this approach isn't suitable for regulating financial markets at a global scale, because, as we've recently witnessed, these can operate chaotically: rising mortgage defaults in Denver can bankrupt banks in Iceland.

Proposing a global system that could monitor this complexity is an interesting academic exercise. However, its realization will be difficult and its efficacy uncertain: remember that the sophisticated risk management systems of many financial institutions failed to protect them from collapse. One could counter this argument by saying that a complete global view could take into account risks that the systems of individual institutions couldn't know. Still, the currently suggested self-stabilizing measures, like dynamically adjusted capital requirements, seem a much more practical way forward.

By Diomidis Spinellis at Mon, 2009-06-01 14:14 | login or register to post comments

Point free style and ESN

I view the distinction between point free and pointed styles as analogous to the difference between coordinate-invariant notation and Einstein summation notation in tensor math. I would like the final result in invariant notation for purposes of cleanliness, compactness, etc., but I find it almost impossible to prove any nontrivial result without descending to coordinates for the intermediate computation. This is because most of the transformation laws one needs (such as http://en.wikipedia.org/wiki/Vector_calculus_identities) are trivial in coordinates, and performing the analogous calculation without introducing coordinates would essentially require memorizing all necessary identities.

I think the best examples of the this issue in programming come from array languages like matlab, python+numpy, etc., where programmers have to jump through elaborate hoops in order to express calculations in array notation for speed.

Another example is the issue of currying for partial application vs. Scala's underscore language construct: "flip (-) x" vs. "x - _". I'd be curious to here other people's opinions about which of these they prefer (I often wish I had both, but don't like the parsing ambiguities associated with _).

By Geoffrey Irving at Sun, 2009-05-31 14:50 | login or register to post comments