A number of years back I was working with a client with a buy-side asset management business. They wanted to understand the impact of MIFID and the proliferation of multiple execution venues for equity trades. I prepared some thought leadership and sketched out a development plan for what needed to be done for a slow-time system to offer after the event analysis.
The basics of the system were:
- Access a copy of all equity FIX orders, amendment requests, cancellation requests and execution reports.
- For each execution report extract the contents of Tag 30 - Last Market
- For each execution report extract the contents of Tag 29 - Last Capacity
- For each execution report extract the contents of Tag 851 - Last Liquidity Indicator
- For each execution report extract the contents of Tag 60 - Transact Time
- For each execution report extract enough data to identify each instrument
That data was then to be loaded into a database, after which the raw data was to be normalised. The issue is that tag 30 is often transmitted as an ISO MIC but some brokers still send Reuters codes, others send Bloomberg codes. These different identifiers need to be normalised to a single scheme so that it's possible to see one code for each execution venue.
A little quirk is that at the time some venues would send the same ISO MIC for their lit market and their dark market - this is covered in a post on the FIX Trading Community discussion forum.
There is also a need to chain-link orders that have been amended. So an initial order will have an client order id in tag 11 and a broker order id will be supplied in execution reports. If this order is amended then the buy-side will send tag 11 (ClOrdId) and tag 41 (OrigClOrdId). The value in tag 41 for the amendment request will be the same as the value in tag 11 for the original order. And so this logic has to be followed to ensure that the correct order data is analysed at any time during the order life.
In the event of a broker busting an execution then a similar chain-linking has to be followed with tag 17 (ExecId) and tag 19 (ExecRefId). This chain-linking is essential to get the right data into your calculations.
Last capacity is a simple enumeration - extract from FIX 4.4 specification:
Broker capacity in order execution
Valid values:
1 = Agent
2 = Cross as agent
3 = Cross as principal
4 = Principal
Last Liquidity Indicator is also a simple enumeration - extract from FIX 4.4 specification:
Indicator to identify whether this fill was a result of a liquidity provider providing or liquidity taker taking the liquidity. Applicable only for OrdStatus of Partial or Filled.
Valid values:
1 = Added Liquidity
2 = Removed Liquidity
3 = Liquidity Routed Out
In May 2012, post release of FIX 4.4 a further value has been added 4=Auction - this can be seen in the "FPL Execution Venue Reporting Best Practices" document.
Tag 60 is simply a GMT timestamp. Since the datum for time is Greenwich, I see no need to refer to UTC, which is a compromise between the English "Universal Coordinated Time" and the French "Temps Universel Coordonné". Let's stick with GMT...
So, let's imagine that we have all of this data. We can conduct a simple analysis, check and see the broker capacity on an execution. We can also see the markets on which an order was executed.
All good but is that it?
No, the next step is where this gets messy. The desire is for the buy-side to understand more about what a broker order routing system is doing during the execution of an order. So in order to do that the buy-side needs to have access to a timestamped set of tick data from all of the relevant execution venues for the period around this order being executed. This is to allow the buy-side to reconstruct the order book at the time of execution.
Hold on though....
We only have the top level "parent" order that was sent by the buy-side to the broker. We have no knowledge of the "child" orders that were sent by the broker smart order router/algorithm engine to the execution venues. The problem here is that we are unable to see that data - since the broker does not supply that information and the market data supplied by an exchange does not identify the underlying client of the broker that sent an order to the order book and often does not identify the broker.
So, this analysis cannot provide much insight into the order routing decisions made by the broker. There is discussion under the FIX Trading Community umbrella of creating a standardised way for brokers to communicate information on these child orders to buy-sides but as far as I know (happy to be proven wrong in the comments) this is not in regular usage.
Given those limitations, what can this analysis show?
It should be able to see market executions at any time and compare to the top of book and overall depth of market in a consolidated book. This should provide the buy-side with some views on the efficiency of the sell-side order routing strategy but without really having insight. As with many types of analysis with an incomplete data set it's rather like driving a car by looking in the rear view mirror and sometimes having a quick look ahead. Better than having your eyes closed but not the optimal solution.
At a higher level it should show whether a broker is executing in different venues in line with the best bid/offer at the time. So, at a crude level, it should give guidance to a buy-side to see if a broker is creating routing decisions based upon the best price in the market or with one eye on rebates from maker/taker models of exchanges. This requirement to "know-your-broker" is an increasing area of concern to many buy-sides.
Thematically this post is linked to an earlier post "Buy-side analytics: beyond TCA". At a later date I will write up my viewpoint which can be summarised as "Holistic Analytics for the buy-side", a single system encompassing:
- Transaction Cost Analysis
- Execution Venue Analysis
- Performance Measurement and Attribution
- Behavioural Analytics
That's for another day...
Comments
Post a Comment