AQTI Commentary: Designing Infrastructure for Automated Quantitative Trading

Discussion in 'RightEdge' started by hylt, Dec 28, 2008.

  1. http://www.aqticommentary.com/

    About
    This blog concentrates on the issues surrounding the design and development of infrastructure for automated quantitative trading. A wide view is taken regarding what constitutes quantitative trading, ranging from low-turnover portfolio management to ultra-high frequency market making applications. The common theme is that basic choices in software and infrastructure design will have an enormous effect on what any given trading operation can ultimately accomplish. The author, Brian Bunker, has extensive experience in all aspects of quantitative trading, with a focus on equities statistical arbitrage.
     
  2. Would you rather have a basis point or a millisecond?

    “Would you rather have a basis point or a millisecond?” This question summarizes a basic dilemma faced by anyone involved in quantitative trading who has to make resource allocation decisions. The ultimate goal is to develop one or more trading strategies which are the most favorable with regard to capacity, consistency and lasting profitability. Reaching this goal requires astute decision-making at the strategic level.

    One of the biggest issues when making technology decisions is that infrastructure which favors the highest trading performance - not P&L, but rather throughput, or similar measures - tends to resist effective use as a research platform. And, vice versa, platforms which favor effective workflow for researchers tend to have basic limitations when used directly as trading technology.

    This can be summarized, very heuristically, by the following graph.

    [​IMG]

    The premise is that you have a fixed amount of capital to dedicate to develop trading strategies. The capital can be dedicated to infrastructure, software development, and data, as well as personnel to conduct basic research and other functions. For simplicity, the assumption is that you choose a primary technology, either as a commercial product or as an in-house development effort. Of course, combinations of technologies are possible, and could be represented in the graph, but they are omitted for simplicity.

    The vertical axis is the performance of the developed strategy expressed as “speed”. There are many disagreements about how to measure this type of performance, and what it really means. However, particularly among traders for whom speed really matters, it is quoted in terms of latency, expressed in milliseconds or microseconds. Therefore, we’ll take “1/ms” as a proxy for the general concept of performance of this type.

    The horizontal axis is much harder to define. Research can be applied to any number of important problems which affect the performance and risk of the strategy. Research can also be anything from empirical data analysis to highly theoretical mathematical modeling. The tools needed to perform effective research vary by the goal and by the working style of the researcher.

    However as a general rule, a technology which is good at reacting to the market with minimal response time is not also going to be a technology built around the priorities of basic researchers attempting to originate the strategy and establish, prior to deployment, that it is worth committing to.

    We establish, as a crude label, “E(bp)”, or the expectation of the predictive edge for the strategy measured in basis points over some established time period, as shorthand for “general research effectiveness”, with full recognition that the concept can’t really be quantified.

    With this choice of axes, the fundamental allocation dilemma can be summarized as the “bp/ms question”: Would you rather have a basis point or a millisecond? The tradeoff is in fact so fundamental that most practitioners are not aware that they are making it. One may specialize, for example, in algorithmic trading or in portfolio management, but not credibly in both. The two areas are generally viewed as being completely compartmentalized relative to each other, even though practitioners in both areas would freely label themselves as “quantitative traders”. For the most part, the methodologies of quantitative trading - e.g. time series analysis, risk control, various widely applicable statistical methods - scale across orders of magnitude in the timescale of the underlying data. It’s largely the technology which prevents easy, fluid movement across these regimes.

    The basic theme of the blog is to develop a deeper understanding of how technology effects the space of possible strategies which can be realistically developed, and more importantly, how it can be improved to expand that space of potential outcomes. For the most part, the issues that come in to play are issues of software architecture.

    The arrow in the graph summarizes the premise that, by carefully working through the many logical issues and “gotchas” which ultimately limit the usefulness of the infrastructure, it’s possible to make significant progress toward improving both trading performance and research effectiveness. In other words, it’s possible to address the bp/ms question by moving the entire tradeoff curve away from the origin. There is no one technology or conceptual framework that makes this possible. It’s a matter of identifying and solving a collection of difficult, interrelated design problems.
     
  3. The asychronicity divide.

    In automated trading systems, data often has the structural property of being “aligned”, meaning that the timestamps associated with individual data are known in advance to be the same across more than one security, and typically across many securities. An example is daily market data. Another example is time-sliced intraday data derived from tick streams. Alternatively, financial data may be “asynchronous”, meaning that every data point has a timestamp associated with it, determined exogenously, and which bears no certain relationship with any other data point used in the system. A typical example is tick data for transactions or quotes. The distinction is very clear cut. Data is never partially aligned.

    Systems which work with either aligned or asynchronous data are like oil and vinegar. They don’t mix, taste different, and have completely different cooking properties. Nevertheless, it’s often useful to work with both at the same time: e.g. salad dressing. A fundamental principle of software design is that if a system has components which don’t “mix” — that is, they have very different structural and operational paradigms –then the components should be separated explicitly, and the nature of the interface between the components must be carefully designed. We refer to the separation and appropriate treatment of aligned and asynchronous components as the “asynchronicity divide”. It is the subject of this post.

    Sometimes in software design an important concept can be considered so obvious that it becomes an unspoken assumption. Practitioners implicitly decline to admit that, at a basic level, they are in fact making important assumptions which are guided by the concept. Such is the case with asynchronicity, and it shows in the fact that individual vendors will assume that you are working with either one or the other, aligned or asynchronous data, but never both. The vendors will then each present themselves as the proper solution for quantitative trading, and leave you to figure out that, in their world, your work must conform to seriously restrictive preconditions regarding what constitutes valid data.

    In reality, virtually anyone who works in quantitative trading will in fact work with both types of data. If you are a quantitative portfolio manager, you might be a candidate to use Clarifi®, a classically aligned product which assumes you are using daily equities data. The output of Clarifi is not a trade per se. It’s a list of trade decisions which the user must route on to execution vendors, human traders, etc. At the execution level, this information will be disaggregated and each daily trade will broken into much smaller pieces which are dealt with, ultimately, on a fully asynchronous basis. These activities inevitably happen, or else trading doesn’t get done. But these activities are not done by Clarifi, because Clarifi is an aligned engine. Effectively, Clarifi deals with the asynchronicity divide by ignoring it. If you want to deal with tick data, you are are on your own.

    At the other extreme, if you are an algorithmic equities trader, you would obviously never use Clarifi, but you might be a candidate to use any one of the many event processing engines such as StreamBase, Aleri, etc. As products which are geared to developers, rather than non-programming end users, event processing vendor actually seem to take a more credible approach to dealing with the asynchronicity divide. They supply connectivity and compatibility with arbitrary external systems (going well beyond integration with data vendors, which is a fairly universal feature across most platforms). Further, event processing engines do have facilities to “align” data, which seems to address the issue. But what does this really mean?

    “Alignment” for event engines means that one can define streams which share the same timestamp. It’s not enough for a system to be able to align data. It should also make the fact that it is aligned fully useful to you. This means that, for instance, that you should be able to access data as “portfolios” (i.e. as vectors across securities) or as “timeseries” (i.e. as vectors along timestamps) or both (i.e. as matrices), and easily perform arbitrary mathematical and statistical operations on data in this format, including looping through indices along any dimension, applying matrix operations, etc. And of course, the product of these operations must feed back into the system for use by downstream components.

    Most any quantitative trading operation will contain extensive operations of this type. Is it possible to implement them in event processing engines? Perhaps, in some cases. Is it remotely convenient? Definitely not. The topic of what you can and can’t do with event processing technology is extensive and interesting. Here, it’s enough to say that if you want to implement the algorithms in your favorite cointegration paper using StreamBase on five-minute time-sliced data, then you can expect to experience some significant misery. This will be particularly aggravating because the operational concepts you are trying to shoehorn into the system are not conceptually difficult, so the effort-to-idea ratio will be frustratingly high.

    Event processing engines are therefore similar to Clarifi in the sense that they assume that all data worth working with is of a particular type — in this case asynchronous. If you want to integrate aligned data into your system, then you are virtually on your own. In both cases, vendors handle the asynchronicity divide by acting as if it doesn’t exist.

    Ideally, a quantitative trading system should be able to move freely back and forth between aligned and asynchronous data, as appropriate for the underlying trading ideas which it implements. The remainder of this post deals with some of the principles involved in doing this successfully. The principles we put forth are: encapsulation, modularity, reconciliation, and commoditization.

    1) Encapsulation

    Encapsulation and modularity are bread-and-butter concepts. We deal with them here specifically with regard to the asynchronicity divide.

    Asynchronous and aligned data are appropriately handled by very different methods, and therefore should be explicitly separated, with transitions between the two handled by interfaces which hide the underlying data representation. This is encapsulation. Through standard interface methods, one should be able to convert aligned data to streaming data which can be picked up by a generic event-processing system. To the extent that one can align asynchronous data within an event processing system, it should be possible to route it into a system which is aware of, and makes maximal use of the alignment.

    2) Modularity

    We stress the principle of modularity mainly as an admonishment to designers of aligned systems because, at least in the space of commercial vendors, they tend not to pay much attention to it. Rather, there is a tendency to create monolithic systems which can only be operated in terms of a rather involved, pre-defined workflow, namely the “portfolio management pipeline” of data acquisition, signal generation, fitting, portfolio optimization, etc. This workflow is monolithic, and moreover, each of the components is predefined and monolithic. According to the principle of modularity, this serially dependent process could be broken into the tiniest conceivable chunks which would constitute an operation on aligned data - i.e. to receive data in aligned form, do something with it, and make the output available for downstream use. The portfolio management pipeline would then be created out of these small pieces, as one of many possible applications, rather than the only application. There should be no requirement that all data in the system be aligned in the same way with respect to same valid timestamps and valid securities.

    If these principles are followed, one should be able to “mix and match” between aligned and asynchronous data. An example of this would be an automated market-making system which uses predictive information at various horizons, along with inventory information, to guide whether to bias toward long or short positions. The predictive information is more appropriately treated as aligned data, arriving at predefined intervals not tied to any particular tick stream. This information would be derived, however, from asynchronous data which has been time-sliced by an event-driven asynchronous system. Finally the aligned predictive information would feed back into an asynchronous system to generate quotes in real time.

    3) Reconciliation

    This concept concerns the discipline for managing interactions between aligned and asynchronous systems - essentially that there should be a form of “accounting”, loosely speaking, for reconciling the expectations and actual outcomes of these interactions.

    In virtually all cases, the aligned system plays the role of controller, and invokes the asynchronous system, rather than the other way around. This is because the aligned system deals with data at a higher level of abstraction, and offers better system-wide control, whereas the asynchronous system is appropriately invoked when concrete actions such as specific trades or quotes are required by the aligned system. Other configurations are possible, but we will deal with this case exclusively here.

    The canonical example is an automated system (aligned) which at intervals makes trading decisions which are then routed to an algorithmic trading system (asynchronous) for execution. In this example, each delegation to the asynchronous system is a discrete unit which consists of an “aim trade” - i.e. a certain number of units of a particular security which the model hopes to execute prior to the next invocation. The key concept of “reconciliation” is that this unit should be managed so that the expected outcome of the aim trade, as generally handled by transaction cost models in backtest mode, can be precisely compared to the actual outcome in live trading, on a unit by unit basis, and as aggregated into system-wide statistical analysis.

    The basic architecture in this example system is ubiquitous - it is practiced by hundreds of trading operations — so it’s surprising that there is no absolutely standardized way to define the reconciliation. However, generally, the method is to break up possible shortfalls as “slippage”: the difference in expected and actual cost for shares actually executed, and “opportunity cost”: the cost due to the failure to fully execute the desired trade. Opportunity cost can be further analyzed by dividing it into the ongoing cost of carrying over previous shortfalls and the cost of shortfall for the current trade to be executed.

    However they are analyzed, it is critical that there be a relationship in the form of an exact accounting rule - i.e an accounting identity — which reconciles model expectations versus actual outcome. In this case it would be:

    (model P&L) - (slippage) - (opportunity cost) = (live P&L)

    The formulas defining each term must obey the identity for each granular invocation of the asychnronous system (execution) by the aligned system (trading strategy). Accomplishing this can become non-trivial, particular in the face of institutional details such as corporate actions. Exact formulae and a detailed discussion of the issues for equities will be the subject of future posts.

    The benefits of following this discipline include:
    ·The ability to use the same system for both research and live-trading (although there are many other issues required to accomplish this successfully).
    ·The ability to easily and accurately measure the performance of the live system relative to theoretial expectations.
    ·Ability to analyze behavior on a microscopic basis, and to aggregate that analysis in any way on the same basis up to a full performance analysis of the system over time.

    We have presented a simple case with a simple reconciliation identity. In more complicated systems, the process becomes more intricate but is equally necessary. For example, in a market-making strategy, the aligned system may consist only of predictive signals, but not actual trade decisions, and the execution systems may operate on a continuous basis with no clean separation into units of time over which individual requests and expectations can be defined by the aligned system. In this case, it is harder to quantify expectations and shortfalls of the aligned system. However it can be done. And by setting up an explicit reconciliation scheme with an exact accounting identity, the designer will bring a critical level of rationality to the system. This is the sort of design decision which distinguishes an industrial quality trading system from a collection of automated rules which are thrown at the market.

    4) Commoditization

    The concept of commoditization, like reconciliation, reflects the fact that aligned systems typically act as the controlling architecture, whereas asynchronous systems are invoked in order to accomplish specific, discrete objectives in the market. In other words, aligned systems invoke asychronous systems far more often than the other way around. Moreover, as a general design principle, the invocations of the asynchronous system should be broken into the tiniest discrete units possible and should be performed via the simplest possible common interface.

    Again we refer to the canonical example of an automated strategy which invokes an asynchronous system in order to execute aim trades. There are a vast array of options available to the trader to accomplish a desired trade: human and electronic brokers, direct market access systems with pre-packaged algorithms, direct access to multiple exchanges and ECN’s, etc. It’s bewildering to keep track of all the choices. They can disappear or become untenable at any time, and new ones can emerge at any time. They all accomplish exactly the same thing; there is nothing to distinguish one source from another except a few parameters which apply across all vendors. To wit, execution is a commodity, and there are great benefits to treating it as such. Most notably, it is critical to always maintain the option of switching to a source which can deliver better price or performance.

    This is accomplished by reducing the interaction between the aligned system and the asynchronous system(s) to a simple interface which effectively reflects and expresses the nature of the commodity; by reducing the granularity of the interaction to the smallest possible size; and by having facilities to create and assign ID’s to different sources within the aligned system, possibly dynamically, and to be able to aggregate performance analysis by ID. The aligned system then can and should contain algorithms which need not be explicitly aware of the details of any particular execution source as such, but which can select among them based on ongoing performance and other criteria.

    Again, in more complicated systems, the same principle applies. Asynchronous systems can usually be treated generically, with some initial effort, and can be swapped in and out at will, to the ultimate advantage of the trader. This is the case, in fact, even for asynchronous system vendors themselves. For example, many vendors supply basic event-driven methodologies. The links section on this blog provides a partial list. It would be unwise to lock in a particular event processing engine as the only possible asynchronous engine in a particular application. Therefore, interactions should be handled via an interface which works with the generic capabilities of event processing engines generally, so that any individual vendor’s product can be swapped in or out with minimal disruption.

    Conclusion

    Virtually all complete trading systems are in fact hybrid systems mixing aligned and asynchronous data. However, the hybrid nature is not handled well, or indeed at all, particularly by commercial vendors. The four concepts applied to the “asynchronicity divide” - encapsulation, modularity, reconciliation, and commoditization - are basically the principles of good software design applied to a particular architectural issue. However, they take significant forethought to implement well. If successfully implemented, they bring rationality and manageability to hybrid system, the components of which fundamentally don’t like to interact with each other.
     
  4. 那幅图将quants按照ms/bp进行分类,精辟。

    图中还标示了Matlab和R。:D