Press "Enter" to skip to content

Developing a Real Life Fully Automated Trading Algorithm Using Interactive Brokers and Python

In this article I will describe how our backtested algorithm can be used in live algorithmic trading. My broker provides me with the TWS (Trader WorkStation) API which is the solution that I use to build my trading application, obtain market and view account details such as open positions and available cash.

The basic idea of my trading strategy is to rank hundreds of stocks by value (value = \frac{1}{(PB \times PE)}) in descending order. That way a company with a high PB and PE ratio will land at the bottom. I then short the bottom ranking 30 stocks and go long the top ranking 30 stocks. The algorithm will check if rebalancing is needed and will do so using an interactive mode as a precautionary measure every time it runs. How often it runs is up to you. You can reschedule it to run daily, monthly or quarterly using a simple cron job.

For the value factor I need price and fundamental data. The price data I request from my broker. I have a market data subscription for that. For fundamental data such as earnings and equity I use my own data source. For the later stay tuned as I will be making this fundamental data available sometime in the future.

I used Python to develop this strategy. You might need to signup for a paper account at your broker and make sure they are using TWS. For a full TWS API please refer to the official documentation.

The TWS API Architecture

I will not go into all the API details since the official documentation describes everything pretty well. But I believe it is good to at least describe the idea behind the TWS API architecture. Some of the text below is taken straight out of the official documentation.

First you need to start TWS on your machine to allow for incoming connections. TWS acts as a server to receive requests from the API application (our Python client/strategy) and responds by taking appropriate actions. The first step is for the API client to initiate a connection to TWS on a socket port where TWS is already listening.

Once the TWS is up and running and actively listening for incoming connections we are ready to write our code. We have to implement TWS API’s two major interfaces: EWrapper interface and the EClientSocket.

The EWrapper interface is the mechanism through which the TWS delivers information to the API client application (our strategy). By implementing this interface the client application will be able to receive and handle the information coming from the TWS.

The class used to send messages to TWS is EClientSocket. Unlike EWrapper, this class is not overriden as the provided functions in EClientSocket are invoked to send messages to TWS. To use EClientSocket, first it may be necessary to implement the EWrapper interface as part of its constructor parameters so that the application can handle all returned messages. Messages sent from TWS as a response to function calls in EClientSocket require a EWrapper implementation so they can processed to meet the needs of the API client.

TWS API programs always have at least two threads of execution. One thread is used for sending messages to TWS, and another thread is used for reading returned messages. The second thread uses the API EReader class to read from the socket and add messages to a queue. Every time a new message is added to the message queue, a notification flag is triggered to let other threads know that there is a message waiting to be processed. In the two-thread design of an API program, the message queue is also processed by the first thread.  The thread responsible for the message queue will decode messages and invoke the appropriate functions in EWrapper.

In Python TWS API the EReader thread is automatically started upon connection to TWS. There is no need for user to start the reader.

Let us go ahead and implement the EWrapper interface first since that is where the data from TWS will be coming in. The code snippet below does not contain all the methods implemented for EWrapper as my intention is to illustrate the basic idea. The full implementation will be listed at the end of this article.

It is important to understand that the methods implemented in EWrapper will be called when the respective data (e.g.: account summary) that has been requested by the client will become available. Depending on the data requested the method might get called repeatedly as can be the case with tick data or it can be called as low as once. For the later the end is usually signaled using the counterpart *End method.

Let’s look at our EClient subclass that will be requesting our data from TWS. Again I am not showing the entire client implementation at this stage.

Notice how the client receives an EWrapper object in its constructor. In the above snippet see how we are calling the TWS API methods using the keyword self(e.g.: self.reqAccountSummary(...)) from within our methods (e.g.: get_portfolio_value(...)). The API methods are available to us since our client is a subclass of EClient. In order to make it easier to read the code and distinguish between API provided methods and method written by me I will use snake_case as my naming convention for my methods.

Finally we create a new class called Strategy that is both an EClient and EWrapper that will be connecting to TWS.

Once the client is connected, an EReader thread will be automatically created to handle incoming messages and put the messages into a message queue for further process. If you are using the TWS API with other programming languages you might need to pass an EReaderSignal object to the EClientSocket's constructor. This object is used to signal that a message is ready for processing in the queue. In Python the Queue class handles this task directly so we don’t have to pass in any EReaderSignal objects to our client’s constructor.

Looking inside the EClient's connect(..) method we see that the EReader thread is created for us. This thread is used to read from the socket and add messages to the queue.

We also need to trigger Client::run(), where the message queue is processed in an infinite loop and the EWrapper call-back functions are then called. Let us briefly look inside the run() implementation of EClient. You don’t have to worry about this since this is already made available to you.

In order for the client to be able to trigger EWrapper call-back functions we need to provide it with a concrete EWrapper implementation – a Strategy instance in our case. We do that using constructor dependency injection.

The wrapper methods are then triggered in the infinite loop listed in the run() method above using the Decoder object as soon as a message is available in the queue:

The decoder interprets the fields and knows what method to call on the EWrapper object.

That is basically the high level overview of the TWS API architecture. Next we will be focusing on the concrete trading strategy.

The Strategy

The first thing to do is instantiate a new Strategy and connect to TWS:

Next we will be fetching some stocks from our database that we will be processing:

Fundamentals is my proprietary API that communicates with my fundamentals database. I am currently working on making this publicly available in the future. But for now you can assume that this returns a list of StockProfile objects from a MySQL database. Each StockProfile represents a company and has properties such as price_earning, price_book and industry. year() and last_quarter() just return the current year and quarter and are passed in get_stock_profiles(...) to fetch fundamental data for that reporting period.

We will now request the latest close prices for each stock in our list from TWS:

Filter out companies for which we don’t have enough data and companies whose industry is either Financials or Utilities:

Once we have filtered out all the unwanted companies we proceed with ranking them by value in descending order and fetching the top and bottom stocks for which we want to place an order:

Next we calculate the weights that will be used to rebalance our portfolio later. We want the top ranking stocks to have a heavier weight in our long position and for the shorts we want the lowest ranking companies to carry a greater weight. That is, we buy more stocks of our top companies and sell more of our worst companies. Notice also that I don’t check a stock’s liquidity or if I can actually trade a particular stock. It is probably a good idea to do that in order to diminish market impact. It might also be a good idea to invest less in stocks with very low liquidity. I don’t do that here for the sake of simplicity.

Before we go about rebalancing our portfolio we will be exiting any positions that we have in companies that are not included in our ranking.

As you can see I am storing any potential orders in a list called order_book and don’t actually place them yet. The reason for that is that I want to display them on screen and ask the user to confirm them before sending them off to TWS for execution. I also don’t want this strategy to continue running if there are any open orders still existent. I do this as a precautionary measure:

Strategy asking user to confirm order execution

Once I have exited all my unwanted positions I go ahead and calculate any adjustments that I need to undertake on any current positions and prepare the order for any new positions. Again I am storing any orders in the order_book list and ask the user to confirm them before sending the off to TWS:

In the above code snippet you can see that I am also storing whether a particular trade is caused by a new position or adjustment. It might have been more simple to just exit all positions in my current portfolio and then just go long the top and short the bottom companies but if a position doesn’t change or just needs a minor adjustment this would lead to unnecessary transaction costs. You might even ignore an adjustment if it is too small.

Finally, I again do some checking for any open orders and ask the user to confirm the new portfolio before placing the orders with my broker:

The Full Strategy Code

Below you will find the full code for the strategy. You simply have to run it using:

Disclaimer: this is a very basic algorithm to illustrate how to interact with the IB API using Python in order to build a fully automated trading algorithm. Please do not invest any real money with this algorithm. Algorithmic trading involves a substantial risk of loss and is not appropriate for everyone.  No representation is being made that utilizing the algorithmic trading strategy will result in profitable trading or be free of risk of loss.