## Stock exchanges: language design aspect

This post is marginally on topic, touching social and economical sides of language design.

Recently I discovered to myself that orders for stock exchanges are little programs written in little language.
The concept of an exchange can be seen as an extension of the concept of money - while money relieves parties from necessity of finding right resources in right quantity to perform barter trade, exchange relieves parties from necessity of finding each other.
This is achieved by delegation of parties' decisions to smart (or not so) agents - usually called orders.

Orders historically started out as very simple agents - like "buy X units of Y for Z$". These agents would then be executed by exchange (in this simplest case, matching equal buys with sells). With time, the DSL started to grow: "buy exactly X1 units of Y1 for up to Z$ by date D1 or else, buy up to X2 units of Y2 for the prevalent market price of date D2 but only if the prevalent market price of Y3 changed below Z3\$ since the order was placed".

I found it very intriguing that exchange orders are not (usually publicly) presented as programs.
This may explain lack of attention from language design folks.
This again may explain why orders' DSLs are so ad hoc - though I certainly recognize there are a lot of other reasons, organizational and technical.
Another intriguing thing is that a lot of people placing their orders are not aware of exact rules for "order matching" (operational semantics of these DSLs). "It is performed by _the system_, why should I care about these details?"

Could it be that one venue to educate general public about languages and semantics is via articles about stock exchanges? :)

So the question: is anyone aware of any research for "better" orders language and/or "better" execution semantics for them ("better" being any of more intuitive/efficient/expressive/transparent)?

## Comment viewing options

### The hard problem trading systems solve...

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

### Thanks!

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.

### Right

I just checked Nick's page you linked, it explicitly says (emphasis mine):

Our language can specify the output of a negotiation (which could be an auction, an exchange, or two parties drafting the contract, or one party drafting and the other agreeing to it, etc. ).

[on edit: an interesting idea would be to compare languages for auction agents and exchanges, to identify overlap, or maybe even propose a unification]

### Great topic!

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 uses an Ocaml dialect...

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.

### Fascinating subject!

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.

### Contracts Strongly Related

Andris seems to be referring to the mechanics of actual orders executed by exchanges and the 'instructions' they carry with them.

Exactly...

In business terms, SPJ's financial contracts paper is not directly related.

...but the main reason orders exist is to eventually engage in a contract! Every order upon completion (full or partial) creates a (half of a) binding contract. Order types are parametrized by contract types, but not always fully polymorphically. By that I mean that execution (matching) can be influenced by the type of contract to be created.
Note that as orders can be seen as contracts themselves, we can try and parametrize orders by orders, or orders by options on orders, etc.
Go figure what this means for business :)

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

One invariant most (all?) order types preserve today is a bound on the size of the contract (in count of traded resources, if not monetary amount). The orders may split, but the total count of instruments you will eventually contract for has an upper bound. If your order's DSL is Turing-complete, there is always risk of it engaging in more and more contracts ad infinitum (or until your credit runs dry). You would probably want to put a limiting cap on such agents. An interesting parallel in usual PLs is resource accounting, only in this case one does not limit CPU time or memory consumption, but monetary commitment.
[on edit: another, potentially blocker, issue with overly smart orders is protection of trade secrets. It is one thing to expose that you are interested in buying X units of Y for Z today, and completely another to upload your entire trading strategy for the next year.]

### [on edit: another,

[on edit: another, potentially blocker, issue with overly smart orders is protection of trade secrets. It is one thing to expose that you are interested in buying X units of Y for Z today, and completely another to upload your entire trading strategy for the next year.]

This is a good application for information flow systems, labelling systems, and capability systems.

### [OT] Dark pools

The desire not to make public one's trades has led to the creation of so-called "dark pools": off-exchange trading systems where positions are not made public. The Financial Times recently did a backgrounder on the relationship between exchanges and dark pools, Responding to liquidity pools, that does a good job of highlighting some of the issues.

### Language as a user interface

I was thinking of how traders might use some constructs from programming languages to interact with the market.

For example, many systems allow users to type in (or click through a ticket window) "b 100 msft" which sends a buy order of 100 shares of microsoft at the market price. These expression patterns are usually parsed through a regular expression or the GUI dialog boxes are fairly non-extensible.

In my experience, if a trader wants to do something unexpected, such as buy and sell two stocks at the same time, they usually either quickly enter the two tickets or have their IT write 'algorithms.'

I have not yet seen a system which allows the trader to encapsulate the two actions of buy and sell into a single action and using that single action: "trade msft orcl"

Languages such as EasyLanguage let one write 'rules' which are then 'started' or executed, but I'm thinking in terms of a read-eval-print-loop provided by some languages. Something simple enough that someone with basic familiarity with writing excel expression could use. More tech savvy users could introduce their own combinators and the trained programmers could make sure enough primitives are provided to get the job done, have them compose correctly, check them for potential errors (type errors as well as 'fat-finger' errors), etc.

Although I'm not a gamer, the few games I have played suffer from the same problem. Players can execute series of single actions: "get close enough to the target; shoot target; run in the opposite direction." However, I don't know of any systems which allow the player to easily turn the series of actions into a single executable 'function': "shoot-and-run target" and subsequently extend it as: "kill-boss = compose shoot-and-run find-most-dangerous-enemy." Once the player gets used to the game, they may start to explore rest of the power of their language: "map shoot-and-run find-all-enemies"