At Corvil, we live and breathe network data as a source of insight into high-performance business processes such as electronic trading. However, recently, we undertook an exercise to explore how much insight it is possible to achieve without network data, and just using application-based instrumentation.
In particular, the goal was to start from the FIX logs taken from a trading system undertaking an aggressive liquidity-taking strategy. The strategy was largely successful in the trades it targeted, but experienced some patches of significantly lower fill-rates.
The FIX logs enable a two-step analysis: first of all, the outcome of each order the strategy issued is captured in the corresponding ExecutionReport in the OrdStatus tag 39. Since the strategy only issued fill-or-kill instructions, the only values of OrdStatus seen were 2=Filled (success) or 4=Canceled (failure), and the analysis is very straightforward. The fill-rate, defined as the proportion of successful orders as a percentage of the total number of orders issued, quantifies a measure of the overall success of the strategy. The raw percentage does not directly reveal profitability, and any TCA (transaction cost analysis) would need to take into account the details of the executed price and quantities, as well as fees and rebates. However, the fill-rate correlates very strongly with profitability and the overall business outcome.
With a raw, albeit indirect, quantification of the business success available directly from the FIX logs, the second step of the analysis is to seek to explain the drops in fill-rate using the same logs (we know WHAT happened, but not WHY or how to address it). The performance of the trading infrastructure, and in particular the speed of execution it affords, is revealed only through the timestamps available in the FIX messages. There are just three available:
Since the TransactTime is provided by the execution venue system, whose clock has an unknown relationship to the clock of our trading system, we ignore it for our exercise.
This leaves the overall execution latency, quantified as the elapsed time between SendingTime in an order to the log-time of the corresponding ExecutionReport carrying the outcome of the order. That is, we ignore the acknowledgment with ExecType=0, and look for the log-time of the ExecutionReport with a matching ClOrdID (tag 11) and an OrdStatus of either 2 or 4.
In this particular instance, the results were quite clear: the periods of lower fill-rate were characterized by significant increases in execution-time latency.
The story told by the FIX logs stops there: by themselves, they can provide no further insight into the causes of the spikes in execution latency. For example, higher execution times might be driven by packet loss on the local network causing TCP retransmissions, or it might be due to spikes in market activity causing queuing at the exchange. The actions to be taken are completely different: in the first case, the local network needs to be fixed but, in the second case, the trading strategy needs to be modified to accommodate unavoidable changes in the execution environment. FIX logs provide no guidance on the correct course of action to optimize trade plant performance.
For complete insight into correlated trading and underlying technology performance, we need to move beyond FIX logs, and instead, start capturing and analyzing network data.
The relationship between trading outcome and infrastructure performance is typically complex and often entangled with other compounding factors such as market microstructure and trends, seasonal changes, and macroeconomic events. A broader analysis is often required to fully disentangle the factors that determine execution outcome and quality, a challenge which Corvil's data science team is addressing with innovative machine-learning solutions. Watch this space for more details!
Download FIX Performance: Mechanisms, Measurements, and Management eBook for a deeper dive into FIX logs, network analysis and trade plant optimization.