Louis Lovas
Mon, 08 Oct 2007 09:55:33 -0500
In the nascent work of CEP technology there are a lot of vendors beating their chests proclaiming they have the solution for Algorithmic trading in Capital Markets. In reviewing both marketing material and documentation of some of the vendors, I have to both laugh and shake my head. The scenarios and example code snippets tell me two things. 1) Many of the vendors are bluffing; they really don't know anything about Algo trading. 2) The examples are clearly pilfered from other, more established vendors.
Algorithmic trading is a very diverse and broad field, and I don't claim to be an expert in all aspects, no one person could make such a claim. With a focused lens, I'll briefly explore a few aspects of the algorithmic-driven trading strategies. Strategies loosely fall into two categories 1) �Alpha' or signal generation strategies and 2) Execution strategies. Alpha in this context means one very simple thing - to make money. Execution on the other hand is about submitting and managing orders in-the-market to minimize market impact. In reality, many Alpha strategies will leverage one or more Execution strategies when their Alpha-seeking logic detects a buy/sell signal, so they are not mutually exclusive.
The goal of minimizing market impact and finding liquidity means that Execution strategies can easily be as complex, if not more complex than their Alpha counterparts. From a software development viewpoint, one rather large requirement of Execution strategies is the need to manage state. That state is the status of the outstanding orders - what amount has been filled, timers on how long they've been in play, rejections, cancellations, amendments, simple exception handling and the like. In other words, you don't simply place an order in the market - you must continuously manage that order; that's fundamental to an algorithmic trading solution.
We call attention to this because a �pilfered' example of algorithmic trading logic was recently published by one vendor in an attempt to describe how their (SQL) CEP engine is well suited to algo trading. The narrative description, which by the way reads word-for-word from Apama marketing literature, describes an �Algo' that monitors the movement of two stocks: �If the price of MSFT moves by more than 2% beyond a 15 minute window of its VWAP and IBM moves up by 5% .... THEN BUY MSFT and SELL IBM�. Note that when we present this example it serves as a simple point of reference to illustrate the inherent logic flow and temporal nature of CEP and it is quickly followed by an expansion about how CEP must also be tied into the realities of the business scenario.
The reality is that in the case of trading, large volumes of shares are not simply dumped on the market. You don't just �buy� MSFT and �sell� IBM. In the real world, such trades are executed in the market using numerous execution or clipping strategies. Shares might be sold based on the historic volume curve of the last three weeks of activity, or by participating in the market flow for the current day. It could perform best-execution across an aggregate book comprised of multiple market makers and/or Exchanges. Or the Execution strategy could follow the bid price for a 30 minute time period, then re-price any remaining quantity (where re-pricing could be another mini-algo in itself). The point of this is to note that when a BUY/SELL signal is issued that marks the beginning not the end of the algorithmic trading strategy. The strategy must manage the state of each outstanding order responding to numerous conditions: the Exchange as it fills (or doesn't fill) an order, re-pricing if the market moves or as time-in-market expires, cancellations, etc.
Given the inherent complexity of state management in this situation, I fail to see how a query language such as SQL can manage the requisite �state' in such a circumstance. I'm sure with sufficient brain-power and developer effort, some arcane syntax for managing state can be contrived. But to paraphrase an old saying: �when all you have is SQL everything looks like a table�. Programmers building real world applications don't (and simply cannot) limit themselves to think in arcane �SELECT blah, blah, blah� syntax. Their thought processes rely on the core intrinsic capabilities of programming languages: �for� loops, �while� loops and good old �if-then-else� statements. Without them building many different iterations of such applications and evolving those iterations over time, will prove tremendously cumbersome.
Constructing a full CEP application, whether in trading or in any other problem space is no different and requires attention to all aspects of event management - from filtering to actual handling of complex event objects. Without a focus on the complete business requirements of the application, you may end up with content for a white paper, but you'll not be creating applications that customers can actually use.