Archive for the 'ATS' Category

Trading System Framework

Published on November 22, 2010 in ATS, auto trading system, Automated Trading, C#, Interactive Brokers, optimization, Software Development and trading. 9 Comments

The core of our architecture rests on a universal trading system framework. This framework abstracts all of the basic market interfaces, allowing us to write generic strategies that run on any market, including simulation.

2010-11-22 Trading System Framework

As you can see in the above central box, our trading system abstracts several core functionalities.

  • Settings Management – the entire trading system is configured via a straightforward xml configuration file. The actual storage and management of this is abstracted by the particular profile. For live running, these settings are version controlled and managed in a central replicated sql database. For simulation, these are stored as a simple file provided to a console based simulator. For optimization purposes, these files serve as the basis for chromosomes in the genetic optimizer (with an optimization file providing the constraints for the search space). At the end of the day, develop a simple generic settings management system that can be abstracted for different targets.
  • Contract Manager / Base Contract – The core component of any system is the instrument that you are trading / measuring. The contract manager provides position management and risk management abstractions, as well as contract locating functionalities. Ultimately any object that requires a contract, goes through the contract manager, and is given an abstraction of a base contract. The base contract can be a futures contract, equity, bond etc. This provides for a universal interface to subscribe to market data, and issue / monitor orders.
  • Strategy Engine / Base Strategies – The strategy engine is the very heart of any trading system. This basic class subscribes to message pumps and processes the messages to handle orders. It is the most versatile object in the trading system, allowing for nearly any type of strategy.
  • Charting – Few systems put enough emphasis on thorough charting, but I find it critical for visualizing the results of a simulation, as well as determining what is happening during live trading. All contracts and strategies implement a simple IChartable interface that allows them to output highly configurable charts, right down to the Graphics handles. This allows the charts to be presented in a live windows forms view, or painted to a Bitmap class for saving to disk.
  • Logging – At the end of the day, traceability is critical. Every trade made needs to be serialized to disk / database in order to reconcile with your clearing house. Furthermore, every strategy needs to output useful tracing information to aid in debugging. Beyond the obvious tracing, strategies also need to implement a reporting interface to provide live state information to the user interface in order to determine how it is behaving, and if necessary to modify its parameter set, or to debug the strategy. This again is abstracted, just like settings and charting to go to different destinations based on the target of the trading engine. For simulation it outputs to the simulation results, whereas in live trading we work against easily queried database engines.

Next up I want to cut into application design and multithreading. There is a lot to cover, and I am swamped, so expect the articles to continue to appear as I have time. And if you have any questions feel free to email email hidden; JavaScript is required.

Six Pillars of Automated Trading

Published on November 5, 2010 in ATS, auto trading system, Automated Trading, Software Development and trading. 1 Comment

There are six major components to an automated trading system.2010-11-04 Automated Trading Overview

  • Live Trading Engine – Any given system will start with the live trading engine. This is the piece of software which runs in real time and actually places orders and reacts to market data.
  • Simulation Engine – When developing strategies, you often need to back test them. In an ideal world back testing would demonstrate profitability, but in reality it is just used to verify that your strategy does what you think it does. The key to a good simulation engine is that you run the exact same code in simulation as you do in production. I can’t understate that last sentence, so I’ll state it again – the key to a good simulation engine is that you run the exact same code in simulation as you do in production.
  • Historical Service – this runs hand in hand with the simulation engine. You need a tick database for simulation. This is the backbone of all research applications, from back testing strategies to developing market models, you need a thorough, indexed, tick database. You can also build bar data from ticks, but you better have ticks available for simulation.
  • Optimization Engine – All of your automated strategies require parameterization. Generally speaking these are best optimized by hand through selection of sensible variables. Sometimes however, you need to parameterize a simple strategy for a large number of symbols, in which case you want an automated system for optimization. Our system uses a cloud computing service to distribute instances of our simulation engine which run chromosomes from a centralized genetic optimization engine.
  • Analytics – You need to ruthlessly track your trading performance. At the core of any solid trading engine is a solid analytics engine which tracks your various strategies.
  • Reconciler – This was the biggest surprise coming from retail brokers to institutional brokers, but everyone makes mistakes. Sometimes the exchange will fail to tell your clearing house about trades you made, other times your clearing house will accidentally include another clients trades in your account. At the end of every day you need to reconcile every fill you think you made with the statements you receive from your clearing house and immediately reconcile any errors with your clearing house and the exchange.

Next up, I will cover the major components of the Trading Engine.

Automated Trading 101

Published on October 30, 2010 in ATS, Automated Trading and Interactive Brokers. 5 Comments

So you’ve just signed up for your Interactive Brokers account, downloaded my C# interface to Ib, and are ready to begin automated trading… what else is there? A LOT.

Because of this website, nearly every automated trader I have met has started this way:

  1. Manual trading with interactive brokers
  2. Seeing a strange phenomena in the market
  3. Building a simple widget to hook up to Ib
  4. Exploiting the mispricing until their trading volume grows and they realize Ib does not negotiate fees and on a bum day auto liquidates your account without any notice.
  5. Decides they need to go the institutional route, and figure out what their other options are.

This is exactly how I got started, and it is only after developing a full institutional system that I appreciated how good Interactive Brokers is, and why they can charge such a premium.

If you are still in steps 1 – 3, then you will want to stick with IB (in fact after step 5, for many people, sticking with IB will still be the right call). For those who have gotten to step 5, my next series of posts will cover your basic decision space.

Your first step is to get your requirements figured out. What contracts do you trade? Equities, Options, Futures, Bonds? Interactive Brokers is incredible in their support for cross asset class trading in a single account. Starting with them, it seems trivial to expect all clearing houses to let you short shares on the ASX and use your acquired buying power to buy futures on Eurex. This is simply not the case. Interactive Brokers provides both clearing services, and execution services. In institutional land these services are broken up, and the most important piece is partnering with the right clearing house.

Your clearing house determines which exchanges you can trade. They establish relationships with each exchange, and guarantee your trades. If you place a loosing bet in a leveraged account, you stand to loose more money than you have in the account, and if the clearing house mistakenly allows you to do this, they will have to cover your losses. I mentioned you have to choose your products, this is because if you want to trade futures on the LME and NYMEX, you will have to find a clearing house with relationships to both exchanges. Likewise if you would like to trade equities, you will need a clearing house that specializes in equities. Generally, clearing houses do not support all asset classes, and execution platforms certainly don’t. Example clearing houses are Advantage Futures, MF Global, NewEdge, Goldman Sachs etc.

So if clearing houses are the first piece of the puzzle, then execution platforms are the second. The clearing house will clear your trades and manage your account on behalf of an exchange, but to actually place trades, you will need an execution platform. For interactive brokers, this is their Trader Workstation front end, and their timberhill backend. In the futures market, there are a few major players, Trading Technologies, RTS (Real Time Systems Group), CQG, and Pats. These are the interfaces you will use to actually trade, and are generally all supported by the major clearing houses and exchanges, so you can use the same execution platform regardless of who you clear with.

image

The above diagram generally illustrates the basic relationship between the parties. What you will notice is that the only time money exchanges hands is at night. Intraday there is no relationship between your cash and your maximum position. That is strictly a risk management function of your clearing house. This is where your clearing house relationship becomes incredibly important. It is not uncommon for clearing houses to let you have much lower intraday margins than required by the exchange (how do you think velocity futures gives out $500 margin on intraday e-minis), but at night time the clearing house has to settle with the exchange. Here again, the clearing house will frequently lend you money to increase your margin , but in general over night is dangerous enough, no reason to over leverage it.

There is a lot more to this, but I want to cut to the technology. If you are going through this process, and want a lot more detail on the various fee structures and technology tradeoffs, please email hidden; JavaScript is required. I have worked with or thoroughly researched nearly every major futures clearing house and execution platform, as well as most of the equities options.

My next posts are going to continue to be overview posts, but I am particularly excited to cut to the technical / code, so stay tuned.

Automated Trading System Development

Published on October 29, 2010 in ATS, Software Development and trading. 0 Comments

It has been a long time since I have done a series of blog posts on the various automated trading technologies, but after two years of developing our in house trading system, I’d like to cover some of the basics of automated trading systems and hopefully open a dialog with other automated traders.

I’d like to break these up into three major pieces:

  1. Vendors and Organization – this includes clearing houses, execution platforms etc, fees etc.
  2. Technology – These are your basic platform decisions, Windows vs *nix, x86 vs x64 etc.
  3. Software – the meat of our system – cover the various components required to build a fully functional ATS, as well as a research system.

My next post will be an overview of what is required to do automated trading.

Stay Tuned…

9.64 Release

Published on July 14, 2010 in ATS, Interactive Brokers and Software Development. 4 Comments

Library version 9.6.4.16 is out! It corresponds to the Ib 9.64 api, and fixes numerous issues, most pressingly the decimal parsing for invariant cultures – no more expecting 9,23 as 9.23!

If you have any problems, email hidden; JavaScript is required.

Download the release here, or go to the utilities page.