Lambda the Ultimate

...is compliance, ensuring that a complex set of rules, imposed by the exchange and by law, are enforced. The rules are particularly hard to enforce, because some of them deal with such matters as ensuring that the execution of the trade respects certain of the interests of all the parties to a trade, and that executing a trade is very time-sensitive. The complexity of many orders reflects not just the general sophistication of the positions that traders at places such as hedge funds want to take, but also the complexity of the ways in which placing a trade might fail.

I'd love to know more than the little I do know about these issues, partly because I too think that they might be an excellent application for the kind of theory we care about here at LtU.

There has been a bit of discussion of order languages at LtU: cf. Easylanguage: domain specific language for trading stocks, which is widely used, and Forex trading with functional programming.

The literature around Peyton-Jones & Eber's How to write a financial contract seems the place to focus upon to begin with. Cf. the discussion at Combinators for contracts.

It is great to see interest to this topic.

Easylanguage seems to be running on the client-side, so to say, while orders are more like SQL sent to the server.
The difference is not only performance, but also, as you mentioned, compliance, which is much more difficult for distributed runtimes. The result of the trade begins to depend on network latency even more than now (will ISPs be forced to log every forwarder packet for purposes of equal-treatment audit?).

"Combinators for contracts" is one of sources that inspired my line of thinking about exchange DSLs, and one can certainly think about orders as contracts between the trader and the exchange. However, these contracts are very special in how they interact with their peers, so much that they may deserve a dedicated research. In other words, while other kinds of contracts deal with non-contractual values/observables, or probably lower-kinded contracts (e.g., options), exchange orders deal with each other (giving rise to an interesting problems in semantics - are matching rules confluent? are they fair? can they be efficiently implemented? what is the algorithmic complexity for opening/continuous matching? how easy it is to explain the system to the trader/PhD?).

Note that much of the (would-be) theory could be applicable to non-financial applications - think programs bidding for system resources, such as CPU time, memory, bandwidth, and information sources.

The concept of an exchange can be seen as an extension of the concept of money...

While there is a lot to be said about the analogy you make, what it is clear is that in both cases it is social practice that determine the value of money and exchange. While we are used to the notion that money-objects have value, and to their semantics, more advanced financial instruments highlight this fact. Larry Lessig is well known for arguing that code is law, a rather intuitive notion for most of us, I assume. Cases like the ones you describe highlight that "code" rather than being a simple category, that can explain constraints on social practices, is itself constrained not only by social norms, laws, etc. but also by the semantics used to specify it (of which there may be many alternatives).

Lexifi (a small french company) uses and develops an ocaml dialect related to these issues.

I even heard that there are using some static analysis techniques on financial orders.

Exchanges serving the same purpose as money is a very interesting observation.

Exchanges don't always share the same functionality. For example, some exchanges allow an order to be amended for price or size, many others don't. If an exchange is a platform which actually executes our 'program,' then different exchanges operate different 'instruction sets'. Since the speed of execution may be important, one also has to keep in mind that the exchanges operate at different clock speeds.

Most of us can't send orders directly to exchanges, they go through brokers. These brokers may have fancier instruction sets that let us do things like "execute order A only when order B is executed." The software on the desk of an investor may provide even more functionality. In other words, our orders--little programs--may go through different stages of execution. Sounds similar to translating a high level language to some smaller, core language, which is then executed by an interpreter or the machine.

What would make a good DSL for trading? At one level it obviously needs to provide the ability to buy or sell instruments (as well as posting bids/offers), cancelling/replacing orders, etc. (I'm sticking to the buy side here).

What about constructs such as : buy X when Y happens, sell A 10 minutes after B happens, sell C 100 times throughout the day, buy 10 of these when prices are right but don't spend more than K in total.

Would this DSL need the full power of various event calculi or temporal claculi?

Interesting, vast topic.

In business terms, SPJ's financial contracts paper is not directly related. The contracts paper shows how various financial instruments can be described, valued, checked for risk, etc.; however, Andris seems to be referring to the mechanics of actual orders executed by exchanges and the 'instructions' they carry with them.