Trading Application: What’s Inside?

Almost any application that implements a trading strategy has a number of more or less standard components. Let’s first have a quick look at a somewhat generalized architecture of a typical trading application and then go into greater detail on specific points related to the development of a trading strategy using Python.

In Chapter 1, Developing Trading Strategies – Why They Are Different, we saw a very generalized diagram of a typical trading application. Now, we are going to consider its blocks in greater detail. We will learn how to connect our application to data sources and trading venues, how to retrieve data and check its consistency, and consider important points about trading logic and orders.

By the end of this chapter, you will understand how to develop the main components of a trading application that is efficient, maintainable, and scalable, and how to avoid typical serious problems that arise due to incorrect...

Technical requirements

You will need Python 3.9 or above to run the code in this chapter.

Have your app talk to the world – the gloomy world of communication protocols

Well, actually, in this section, I could just say, “in the world of FX automated trading every setup is unique, so go ask your broker.” Of course, I am not going to do this but when it comes to connecting your app to a market maker, electronic communication network (ECN), or any other trading venue, always keep in mind what I said at the beginning of this section.

As you remember from the previous chapter, the FX market is still the most fragmented one from the trading standpoint; so there should be no surprise that its computerized infrastructure is also very fragmented. Even though there’s a standard for exchanging financial information, many trading venues use their own dialects, which simply means extra work in cases where you want to use your application with a different broker. At the same time, many trading venues offer their own APIs and protocols not compatible with...

Retrieving data – garbage in, garbage out

The FIX protocol is universal by design and thus can be used not only for ordering but also for data retrieval. However, in most cases, it is not actually used for market data transfer; instead, trading venues provide their own proprietary APIs to retrieve data from there.

As always, in this gloomy world of communication protocols, everything is individual and each trading venue offers its own API. However, in general, all broker APIs are implemented as REST or Websockets. The former is convenient for occasional requests for quotes, while the latter is best for continuous subscriptions that allow receiving real-time market data.

The following examples I provide are taken from the API of LMAX, one of the key ECNs in the FX market. They are not only great because of their openness to any client, big or small, but also because they are one of the very few trading venues that publicly disseminate real-time market data – and...

Trading logic – this is where a small mistake may cost a fortune

Trading logic is obviously the core of the entire trading app. It is the very component that analyzes the market data in search of any pre-defined price-time patterns (sometimes other data such as volume and open interest is included, but this data is typically not available for the spot market) and generates orders. Almost all of the rest of the book will be dedicated to trading logic and various approaches to developing trading algorithms but we can’t really move on without considering one very typical mistake that already costs many traders millions, if not billions, of dollars. I mean the peek ahead issue.

The phenomenon of peeking ahead is specific to only the development phase of the project when the trading algorithm is optimized or trained using past market data, which is called historical data. As you remember from the previous section, historical data is something pre-recorded either by yourself...

Risk management – your safety belt

After your algorithm has generated a trading signal, it should go past risk management. While trading logic answers the question to trade or not to trade, risk management answers another question: how much should be put at stake?

In basic terms, risk management involves analysis of the potential maximum adverse excursion per trade, account size, leverage and margin as financial components of risk, and macro-economic factors and political events as external and non-market risk. Just to give you an example, it would be wise to just switch off trading before the Swiss National Bank decision in January 2015 or the presidential elections in the US in 2016.

The topic of risk management is really vast and we will go into detail on this later in Chapter 10, Types of Orders and Their Simulation in Python, after we have learned more about types of trading strategies and orders.

Ordering – make sure you are understood correctly

Last, but by far not least, your trading application will have an ordering module. This module performs the following functions:

• It maintains the connection to the execution server keeping it alive.
• It transforms trading signals passed by the risk management module into actual orders – using FIX or any proprietary API.
• It handles all types of responses from the broker or trading venue. These responses range from just OK to partial fills and rejects.
• It decides what to do in cases where your order was rejected or filled partially.
• It resubmits orders, full or in parts, in case it is favored by the trading logic.

You may have noticed that one of the responsibilities of the ordering module is maintaining connections – quite like the data handling module. Yes, there’s no mistake here, it is absolutely normal that a trading app uses different connections for data and for orders....

Summary

In this chapter, we learned how to connect to a broker or data vendor, retrieve live market data, understand the requirements for the quality of this data, and know all the five core logical blocks of which our future trading application will consist.

In the next chapter, we will move on to discuss the specifics of how we can efficiently handle historical market data because this is exactly what is required for the research and development phase.