In order to understand how to improve the execution quality in the forex market, we need to understand the dynamics of these markets, the microstructure, how matching engines of ECNs works, the limit order book (LOB) dynamics and the behavior of every player in the market (takers vs makers vs liquidity providers).
Once you understand how all this infrastructure works and its dynamics, then you can think about how to implement your technology accordingly.
Basically, execution quality refers to how well orders are executed at the desired price without any slippages or other problems. This means that your order should be executed at the top of the book, or better.
The root of best execution lies in creating a robust framework under which to conduct execution. One must measure that execution against the execution framework and improve it where possible.
The better the execution quality, the lower the trading cost.
How to measure the execution quality?
Trading cost analysis, or TCA, is a way for traders to calculate the total cost of executing a trade in order to determine if it was executed at an acceptable price or not, and much more. We can get a lot of different statistics on how our orders are being handled by the different venues or ECNs.
But before we understand what TCA is, we need to define what exactly we want to measure.
- Execution Price: measure the percentage of volume for a certain currency, that is executed at prices better than the top of the book, i.e., either below the best offer for buys or above the best bid for sells. This also leads to the problem commonly known as “slippage”.
- Execution Latency: it is the average period between the time you send the order, and the ECN receives it for processing. Not only will being close to the ECN improve this, but also depends on how fast your systems send the actual order.
- Execution Speed: it is the average period between the time the ECN receives an order and the time of order execution. This varies between ECNs and their liquidity providers, and it is crucial measure to the execution quality because it’s out of your control. Either your ECN has a good execution or not. Moreover, in forex, liquidity providers have last look capabilities (a very controversial topic) and that could add up into this measure. More on the next point.
- Fill ratio: it measures the number of successfully filled orders versus rejections/cancels received. The higher the better. Bad fill ratios could be sending orders with missed prices (because market moved) or as stated in the previous point, the liquidity provider rejects it (last look).
- Spread: measures the distance from the midpoint of the market at the time when your order is entered to the execution price you receive. This value is doubled to capture the whole bid/offer spread. This amount captures both how often, and by how much, a broker-dealer improves the price of the currency.
From this, we can conclude that the execution quality will depend on the following:
- Fill ratio
- % Volume executed at top of book and slippages
- Latency between your system and the ECN
- Latency of your system (also known as tick-to-trade)
Based on this information, we can start to design our technology infrastructure to tackle each of these important measures and have a better understanding of our executions.
But before that, we need to understand how the matching engines work and the limit order book dynamics.
Matching Engines and Limit Order Book
Matching engines are the central component of ECN trading systems. They are responsible for executing orders from multiple sources, in a fair and efficient manner.
The core mechanic is to match up bids and offers to execute trades. It works by using one or more algorithms which keep a record of all open orders in a market and generate new trades if the two orders can be fulfilled by each other.
Matching engines in ECNs have three main functions:
- Matching orders
- Executing trades
- Keeping track of the order book
This engine is responsible for the price movement within the market by executing trades at the last executed prices.
The most popular matching algorithm is called ‘Price/time priority’. If multiple orders have the same price, the order that was submitted first will be filled first. This is the same principle as a First-In-First-Out (FIFO) system. When an order comes in, it is forwarded to the matching engine, which compares it with the “limited order book” (LOB). If there’s a match, there’ll be a trade. The book contains all limit orders for which no matches have been found yet. These are broken down into bid and ask side, with bids being sorted in ascending order and asks in descending order. If no matches can be found for a new order it will also be stored on the respective side.
A limit order book typically has these characteristics:
- Bid: The largest positive number that a sell order can be executed for.
- Ask: The lowest price at which a sell order can execute
- Spread: The lowest price is at the ask and the highest price is at the bid.
- Midpoint: The price halfway between the ask and the bid ((ask+bid)/2)
The bid is 99.90, while the ask is 100.00. The spread (ask-bid) is 0.10. The midpoint (ask+bid)/2) is then 99.95
Entering a Market Order
If you want to buy or sell a stock, one type of order you can enter is a market order. This will buy or sell the stock at the best available price in the market at the time the order arrives. With a market order, you are guaranteed that you will buy or sell; however, you are not sure of the price at which you will trade.
- A market buy will buy at the lowest ask price. If it buys all available shares at the lowest ask, the next ask above will become the new lowest ask, and that is where additional shares will be bought.
- A market sell will sell at the highest bid price. Similarly, if it sells all available shares at the highest bid, the next bid below will become the new highest bid, and that is where additional shares will be sold.
Use the app in the next slide to enter market orders and see the effect on the limit order book. On the left is the original book, and the right shows the book after the order is executed.
Entering a Limit Order
You can also buy or sell stock with a limit order. In this type of order, you specify the highest/lowest price at which you will buy/sell. With a limit order, you are guaranteed the price at which you will buy or sell (if the trade is executed); however, you are not guaranteed that you will actually trade.
Say you enter a limit order to buy at $99.98. Your order will sit in the limit order book until a sell order executes against your trade at $99.98.
Similarly, a limit sell will sit in the book until a buy order executes against your sell.
What if I enter a limit order to buy at $100.03 and the present ask is $100.00? Your broker will likely warn you, but if you enter the order, it will immediately trigger, turn into a market order, and execute at $100.00. It is going to be favorable to you (cheaper). A limit buy simply specifies the highest price at which you will trade – you will always get the best available price when transacting.
Now that we understand how the matching engines work and the LOB dynamic, our strategy is to handle this information from all the different venues we trade with and analyze it as one big block, which will give us a broad view of the market. The FX Aggregator will help with this.
Why you need an FX Aggregator and how to implement it
An FX aggregator, also known as the Foreign Exchange aggregator, is a software in Forex trading that is used in the execution of FX transactions in order to combine (aggregate) all the liquidity from different liquidity providers – hence the name.
They are usually used by institutional Forex traders to compare all prices that come from different liquidity locations as a way to get a realistic view of the current structure of the market. This can be from ECNs, global banks, market makers or sources like Hotspot FX, FXall, Currenex etc. – see Figure 2.
FX Aggregator implementation is complex as the technology needs to be fast (Latencies in microseconds) and flexible. Some institutions develop their own FX Aggregators and others buy existing products from technology vendors. Either way, is a very important piece to have. Having a broad view of the overall market and its depth will give you a better idea of where the liquidity is. If you can route your order(s) where the liquidity is, not only could you get better prices, but also make sure that you are sending your order to the best venue.
Technically, the aggregator needs to hold internal copies of each venue’s Limit Order Book, and then merge them into one global book, that will be available for your execution decisions.
So, the first step of the implementation is to read and hold the limit order book for each venue or ECN, and for that we need to decide what is the most efficient data-structure for the algorithm to process.
Assuming that you are already receiving the streaming of tick prices from the venue, we need to have the right data structure to hold it. And for that, we are going to use plain vectors. One to hold bids and the other for offers – see Figure 3.
And for the implementation, we will be creating a class “lob” to hold these values, but also to give the ability to add, update and remove price levels as we receive them from the venue. That way, we will keep the order book up to date in real-time – See Figure 4.
The class will hold two vectors, one for bids levels, and one for offers. And will have the ability to add/remove/update those levels, and sort them accordingly.
This is the most simplistic implementation, and there are tons of things to improve in terms of performance. For more details on this, please refer to my other articles related to high-performing programming techniques.
Also, note that, for simplicity’s sake, we are not making these classes thread-safe a must in a multi-threading environment like this.
Now that we have the limit order book implementation done, we need to make sure that we can have one data-structure of the “lob” class per each venue or ECN – See Figure 5. With this, we can implement an aggregated_lob class, that will give us the best bid/offer prices across the different venues/ECNs.
And the implementation of this aggregated book looks like Figure 6.
As you can see, we implemented two main methods:
- get_best_offer: to get the best offer across all venues.
- get_best_bid: to get the best bid across all venues.
This way, now our strategies and models can know where to better execute the buy/sell order into the best venue available. Of course, these are the most simplistic implementations, just to give you an idea.
We can start to add more advanced methods to do the following:
- Get best bid/offer depending on the size we are looking for: is not the same to execute a 100K order or $10M orders. Clearly, there’s going to be a “market impact”. So, we can make sure to split the order and execute across the different venues depending on their liquidity availability. This way, we can “lower” the market impact. Hence, improving our execution quality.
- Price discovery for a specific order size to minimize slippages: if we need to execute an order with a bigger size than the available on top o f the book, we will incur in a slippage. With this, we can know beforehand how much slippage we will have and decide on a better course of action.
- Implementation of a Smart Order Routing (SOR): it will allow us to be smarter in where and how to execute our orders across the market. More on this next.
Smart Order Routing – SOR
Smart Order Routers work to analyze the state of venues and place orders in the best way possible, according to your defined rules, configurations, and algorithms.
Usually, smart order routes are configured with a specific objective in mind.
Some organizations may be set in their ways and favor a given fill price rate over the fill speed. Keep in mind that your broker might not offer different order routes depending on which one you choose, but access to dark pools is dependent on the broker’s access.
So, based on the statistics you took, you can give more weight to some ECNs over others, even if they have the worst price. Because, maybe, they could have better fill ratio, less slippage or better latency.
Moreover, with all this data, your SOR could be even smarter, applying machine learning to have the most reliable execution. The algorithm could keep statistics of executions for every ECN and every currency, and based on that, decide what’s the best route.
One of the challenges, in particular, with the execution of many orders is determining what the optimal execution order is. This can be done by using a simple algorithm that identifies which order is better at achieving certain goals and then following it. In addition to benefiting from an optimized execution, your SOR will also benefit from being able to use this data to improve its execution strategy.
Lastly, in some special cases, these smart order routers can also implement special algos like
- VWAP (Volume Weighted Average Price)
- TWAP (Time Weighted Average Price)
- POV (Percentage of Volume)
- Many others
The execution quality is one of the most important things when we are trading quantitative strategies. It could be the difference between a successful trading operation or a plain failure, regardless of the strategy you use.
Especially in the Forex market, the best price is no longer the most important thing. Factors such as fill ratio, last look, latencies, and spreads could be far more important than just the price we see.
And here is where having technological tools like FX Aggregators, TCA analysis, etc, could improve how your orders are being executed.
All the code described in this article is publicly available in my repository https://github.com/silahian/fx_aggregator