Types of Orders and Their Simulation in Python

In the previous chapter, we considered a number of classical trading strategies usually employed in FX trading. All of them can be automated – that is, the decision to place a trade can be made based on quantitative data only, and placing a trade in the market can be done by an algorithm. So, we need now to find a proper way to place trades and control their execution.

We already mentioned (see Chapter 1, Developing Trading Strategies – Why They Are Different) that any trade, manual or automated, can be placed in the market by using an order: an instruction to the broker (or any other intermediary) to buy or sell. What could be simpler? However, the reality is always more complex. You may want to trade at a certain price, no worse than a certain price, no more than a specified amount of pips (points) from a certain price, and so on. Besides that, in the real market, there is real liquidity, which is always very far from...

Order ticket – what you send is what you get

Let’s start with drafting a prototype of a general order ticket – something that is sent to a trading venue.

Normally, orders are sent either as FIX messages (see Chapter 4, Trading Application – What’s Inside?) or in JSON format according to the venue’s specifications. As we also noted in Chapter 4, every venue has its own data and ordering interfaces, but the core properties of an order always remain the same.

Actually, the list of these properties is quite logical. Let’s prepare an empty form and fill in its fields one by one.

First, each order should go out with an ID. Otherwise, how do we or the trading venue refer to it? If we trade live, then the trading venue will generate an order ID that we receive, but if we run a backtest and want to modify orders that had been sent earlier, we need an internally generated order ID. Anyway, number one in our order form is Order ID:

...

Market orders – the way to get maximum control over transactional risk

Let’s start with the most simplistic (at least at first glance) type of order: the market order. A market order is an order to buy or sell a certain amount of an asset at a market price. By market price, we normally assume the best bid or the best ask (see Chapter 3, FX Market Overview from a Developer’s Standpoint, for the explanation of the best bid and ask), and most trading strategy developers test their ideas using only the best bid/ask historical data. So, we can add another record to our order ticket prototype, and this record represents the order type:

Figure 10.5 – Specifying the order type

We already saw (see again Chapter 3, FX Market Overview from a Developer’s Standpoint) that liquidity may have a substantial impact on how orders are executed in reality and it is considered quite a frequent situation when a single large order may move...

Limit orders – guaranteed price, but not execution

In general and brief, a limit order is an order to buy or sell the specified amount of the asset at the specified price or better.

What does better mean here?

This means that if I send a limit order to buy EURUSD at 1.0100, then any price below 1.0100 will match my order. On the contrary, if I send a limit order to sell EURUSD at 1.0100, then any price above this level will match. In other words, by using a limit order, I say that I am ready to buy or sell at any price no worse than the one specified in the order.

What happens if you send a limit order at a price that is better than the current market price? For example, a buy limit order at a price that is below the current ask? Well, it depends on the particular implementation of limit orders used by your broker or execution venue. If you trade at an exchange (for example, if you trade currency futures), then your order will be routed directly into the order book...

Time in force – better control over execution

The specifiers mentioned previously are normally called time in force conditions, although, as you will see a bit later in this chapter, for some of them, it is not really obvious or intuitive.

Important disambiguation

More often than not, these execution method specifiers are referred to as the type of order. This can be found not only in some brokers’ documentation but also in books on trading, and even academic research. So, be very careful when you encounter type of order or time in force in any documentation, and make sure you understand what exactly the author had in mind: the type of order as such (market, limit, stop, etc.), the time during which it is valid, or how the order should be executed liquidity-wise!

In the following subsections, we will consider different order specifiers in detail.

Immediate or cancel

An Immediate-or-Cancel (IOC) instruction attached to a market order means: I want to buy...

Stop orders – maximum uncontrolled risk

Essentially, a stop order is an order to buy or sell the specified amount of the asset at the specified price or worse.

You may ask at this point: why on Earth would I want to buy or sell at a price worse than I’d like to?

The answer is very simple: both better and worse are just references to where the order price is relative to the current market price.

For example, if the current price of EURUSD is 0.99673 and I send a buy-stop order at 0.9989, then my order will be executed at any price equal to or greater than 0.9989. Similar to limit orders, a stop order will reside in the broker’s order book until the market price touches the order price and then converted into a market order. Note that, unlike limit orders, stop orders are never sent to the order book immediately, even if you trade with an exchange. This is quite natural, in fact: if I send a limit order to the order book, then I improve the liquidity in...

Compound orders

Compound orders are those that assume a certain logical chain in their execution. That’s why they are also referred to as conditional orders. Strictly speaking, such an order is not a single order: it’s a sequence of orders that are triggered one by another.

As the most common example, let’s consider a stop-limit order. Unlike stop or limit orders, it requires two prices to be specified: stop and limit. If such an order is sent to the execution venue, first, the venue’s matching engine waits till the stop price of the order is touched by the market (best bid/ask) price. After that, the order is executed using its limit price exactly like when executing a limit order. So, a stop limit order is a combination of both.

For example, if the current price of EUR USD is 1.01015 and I want to buy it at 1.0102, I can use a stop order to enter the market – but I remember that during the execution of a stop order, I can get a potentially...

Summary

Now, we are familiar with orders of the three main types, and we know in which cases we prefer to use market, stop and limit orders, and in which cases we’d rather avoid using them. Besides that, from previous chapters, we remember how to receive and handle market data, and how to use technical analysis, and we remember the key risks and have at least some ideas on how to mitigate them. So, we are ready for the final, ultimate job of any algo trader in the research and development phase: we are about to start drafting a trading application, something that will receive data, process it, generate trading signals, convert them into orders, send the order to the broker, process the broker’s response, and collect the trading statistics, which can ultimately prove or disprove the trading idea. This is what we are going to do in the next chapter.