top of page
Chris Sparrow

Best Execution: Analytics in Context

Updated: Feb 11, 2022

November 2020


Transaction cost analysis (TCA) is the quantitative framework underpinning Best Execution, but it can be difficult to determine from a TCA analysis whether the results are ‘good’ or ‘bad’. Why is this? Put simply, it is because a lot of TCA lacks context.


What do we mean by context? An example helps to illustrate the point. Imagine that we execute two orders of the same notional value, one in a very volatile environment and another in a more stable environment. Now suppose both these orders had an arrival cost of 10 basis points. Our CIO asks whether we had good or bad performance.


How do we answer? We could say that we had equal performance because both orders cost 10 bps to implement. But this response completely ignores what the context of the order was. To give a more fulsome response, we would need to take into consideration the instructions and constraints placed on the order and the market conditions in which we executed the order. If we include the context of the volatility and other liquidity characteristics we could answer the CIO’s question much more accurately by telling them how good or bad the performance was.


The mental model we have for TCA is that of an agent operating in an environment. The environment can be described by the liquidity of the security we are trading which is determined by the aggregate behaviour of other market participants.


The liquidity environment of a security can be characterized along multiple dimensions including the spread of the stock, the depth of passive orders available on visible order books, the volatility of the stock, the frequency of trades and quotes and the transacted volume. The environment also depends on other macro factors that affect the overall market and can impact each security to varying degrees. Just to keep us on our toes, all the liquidity factors, indeed the entire liquidity environment, changes through time.


The agent takes instructions and has constraints that accompany the order. The agent implements the order by interacting with the liquidity environment in a way consistent with the instructions and constraints. So why do we report a number like 10 bps that is the (signed) difference between the arrival price and the average price achieved by the order without reference to the context, i.e. liquidity environment, in which the order was executed? The answer is because it is simple to compute and easy to report.


How can we do better? Consider an analogy. Imagine our goal is to choose a jacket to wear on our morning commute. We have been given instructions that we must walk to work, and the constraint is that we can only choose between 4 jackets. We can set up a routine where each day we randomly choose a jacket, write down which jacket we chose and then measure our comfort level during the walk.


Our comfort level is defined as our change from normal body temperature. If we choose a winter jacket on a hot summer day, we will overheat and sweat. If we choose a summer jacket on a cold winter day, we will get cold and shiver. If we choose a light jacket on a mild spring day, we will be perfect.

Next, imagine that we keep a record of which jacket we wore each day and what our corresponding comfort level was. Would we have enough info to determine the optimal jacket to choose? No!


What is missing from our analysis? We have made no reference to the most important factor – we have ignored the weather. Realizing this, we change our analysis to include what the outside temperature, wind and humidity are before we step outside on our way to work. We quickly realize that we can choose the best jacket by first checking the weather. If it is very cold, we reach for the parka and if it is hot, we will take a wind breaker. By observing the environment, we put our choice into context, and we can make decisions that lead to more comfortable outcomes.


Now if we want to make a prediction machine to recommend a jacket for tomorrow’s commute, we could look at a weather report and based on the expected weather and knowing our past comfort levels we felt in similar weather conditions, we can choose the jacket that will be most comfortable. Clearly we can do a better job of predicting our comfort level if we consider the weather as an input to our jacket recommendation model.


By recording the context, we can gain greater insights into the problem at hand.

It is also apparent, that we are going to make better predictions if we record the prevailing weather (that we walked through) than if we recorded the average temperature over the past 30 days. What impacts our comfort is the weather we experience on our walk, if there is a mild spell in February after a cold snap, we would want the wind breaker rather than the parka.


Figure 1 Dashboard to simultaneously monitor both performance and liquidity. The panel on the left shows how well or poorly we are performing along several dimensions while the panel on the right characterizes the environment we are trading in. The bullet charts allow us to add ranges to indicate where the current level of the metric is relative to historical levels, providing relative performance to augment the absolute performance measurements.



In a TCA approach, the market ‘weather’ is often ignored. By comparing orders without reference to the prevailing liquidity environment, we miss important details about the context of the order implementation. While it may seem rather silly to think that you can choose the proper jacket without first looking outside to check the weather, many TCA analyses do not factor in the liquidity conditions prevailing during the life of the order. It does not have to be this way.


Because we have all the market trades and quotes, we have details of the prevailing liquidity environment during the life of our order. These liquidity analytics can be combined with the performance analytics to provide context that allows for more meaningful insights into how to optimize our ‘comfort level’. For example, when we measure performance versus a benchmark, we can incorporate the volatility, spread, velocity of trading and participation rate into the analysis to put each order into context.


By doing so, we construct benchmarks that measure performance relative to the overall market, as opposed to absolute measures of performance, that don’t consider the liquidity environment an order was exposed to. Measuring the difference between an order’s average price and a benchmark like VWAP does not consider the prevailing liquidity as we executed our order – our participation rate may have been 20% or 0.2%, the spread may have been $1 or $0.01, etc... It is as if we measure the jacket and our resulting comfort level without any reference to the weather. We can refine our analysis so that we consider the environment and weight our performance accordingly. We described an example in a previous post (VWAP Performance: Was it Good or Bad).


There are tens of thousands of listed securities. Each has a unique, time-dependent liquidity environment. Some factors affect the liquidity of all stocks while other factors may only impact a particular security. Despite this, traditional TCA measures such as adverse selection apply the same methodology to ultra-liquid securities that may trade many times a second as is applied to low-liquidity stocks that trade a few times a day. There is usually no consideration of the specific nature of the underlying security’s environment when determining the time horizon over which to measure the price moves associated with adverse selection.


How can we really expect to draw meaningful insights when we don’t account for these vast differences in market liquidity? A metric like adverse selection is very useful to have, but measuring the mid-point 50 milliseconds after an execution in a stock that trades 100 times a second is very different than doing so for a stock that trades once an hour. Yet, in many TCA systems, overall performance is computed as value weighted averages without regard for these differences in liquidity.


TCA involves combining tick level market data with client order and fill data. Traditional TCA metrics like arrival price, interval VWAP and adverse selection are derived from this market data. However, there is much more information in the market data that can be gained. The velocity of trading, spread and volatility can easily be computed from the same data sets that are used to compute an interval VWAP or adverse selection.


The good news is that we can address the deficiencies in traditional TCA approaches by providing the context we need to derive more meaningful insights. In the same way we recorded the weather as part of our analysis of which jacket is best to wear for our walk to the coffee shop, we can use liquidity characteristics to help determine the best implementation strategy for our order.


We need to recognize that stocks all have their own unique liquidity characteristics. This recognition allows us to construct superior analyses that incorporate these unique features to put our orders in context. We can then determine whether our performance was ‘good’ or ‘bad’. In many cases we can determine how good or how bad.


Historically TCA has used benchmarks that measure absolute performance – it is simple and easy, but we are not limited to using only these ‘traditional’ benchmarks. By constructing new context-aware benchmarks we can gain deeper insights into order performance and improve our ability to achieve Best Execution.


This analysis can also play a key role for improving future performance. In the same way that we check the weather when we choose our jacket in the morning, we should be checking the market liquidity conditions during our order. We can make much better choices when we understand the environment we are operating in. This is how Spacetime.io delivers better than best practice.

Chris Sparrow

Director of Research and Data Science

chris.sparrow@spacetime.io

Copyright © 2020 Spacetime.io Inc.

solutions@spacetime.io | spacetime.io | @spacetime.io

316 views0 comments

Comments


bottom of page