Has the FIX Protocol given any guidance on the liquidity indicator that should be set for venues with periodic auctions (such as BATS)?
BATS has its own MIC code for fills done in the Periodic Auction “BATP” and on the exchange side sends us back a new liquidity indicator to say the fill was done in the periodic auction.
The liquidity indicators sent exchange side often don’t map directly to the Last Liquidity Indicator in FIX which supports the following (with the recent addition of the Turquoise 8/9):
Last Liquidity Indicator LastLiquidityInd (851) 1 = Added Liquidity
2 = Removed Liquidity
3 = Liquidity Routed Out
4 = Auction
8 = Turquoise Plato Block Discovery execution in Continuous Trading
9 = Turquoise Plato Block Discovery execution in Turquoise Plato Uncross
I would expect fills done in a periodic auction to be flagged as 851=4(Auction) and speaking with our trading desk they had the same assumption as me.
I wanted to check if the FIX Protocol had given any guidance on this as I don’t want us to implement a mapping to 4 to later find out that a new value was going to be introduced, e.g. 851=6 (Periodic Auction).
I’d appreciate anyone’s feedback on this.
Thanks,
James
LastLiquidityInd(851) only has 7(!) valid values as of EP240, the Turquoise specific values you mention above are not part of the FIX standard. The business requirement from the Turquoise “Block Discovery Service” to identify these kind of match events was submitted to FIX back in 2015 and resulted in Extension Pack 198 (EP198 Indicative Execution Extension – FIX Trading Community v2.1) published in February 2016. FIX was extended as follows:
- Two new valid values for MatchType(574)
- 10 = Auto-match with last look [Execution that arises from a match against orders or quotes which require a confirmation during continuous trading.]
- 11 = Cross auction with last look [Execution that arises from a match against orders or quotes which require a confirmation during an auction.]
User-defined values for LastLiquidityInd(851) are not FIX-compliant. I assume that some implementations were not able to wait for the official extension and made the (false) assumptions that tag 851 is semantically the correct field to extend for this. The existing implementations should change to MatchType(574) over time and new ones should use MatchType(574) immediately.
As far as your initial question is concerned, tag 851 is not intended to distinguish different auction types. Hence, value 4=Auction is the correct one for any auction and is intended to to express a situation where there is no aggressor in the execution. Tag 574 is there to describe how the match came about. Period auctions would be covered by 7=Call auction.
If a given implementation only has one type of auction (e.g. periodic), the guidance is to use 851=4 (Auction) and to say “Applies to executions in periodic auctions” in the (BATS-)specific Rules of Engagement, avoiding the need for an extra field.
Thanks for this response. It’s extremely helpful.
When we were planning our MIFID spec I spoke to other brokers, clients, and vendors and when it came to Turquoise BDS everyone who had a view point on the subject was in line with using 851=8/9 so this is what we implemented.
The use of Match Type makes sense. When setting 574=10/11 would you expect not to also set 851?
How can I get more involved in the conversations that drive these tag decisions?
Thanks again for your help,
James
Hi James,
part of the problem is that people do not use FIXimate on the FIX website as golden source when taking implementation decisions. Thank you for using this forum to clarify the issue, please use it as early as possible if FIXimate does not show what others may be claiming as a standard.
Another part is the fact that people often come to FIX with a request when they need to implement something a few weeks later. In terms of relative FIX is a lot faster than other standards but it is still a standard and any extension requires proper process. People then assume that their proposal will go through as submitted. Turquoise BDS was one of the rare cases where the assumption was false in the sense that a different field was chosen compared to the initial idea.
Setting tag 574 convey the type of matching. It does not convey whether liquidity was added or removed. The latter is a requirement of its own in the ESMA context (RTS 24 Annex, Table 2, Field 44):
Passive or aggressive indicator
On partial fill and fill order events, indicates whether the order was already resting on the order book and >providing liquidity (passive) or the order initiated the trade and thus took liquidity (aggressive).
This field shall be left blank if not relevant.
“PASV” – passive or
“AGRE” – aggressive
To your last question about involvement. Typically, working groups and/or committees submit proposals to the GTC. As a FIX member, you can join these groups where the related business requirements are being discussed. The mapping to FIX tags and valid values is often part of the proposal but is not binding for the FIX Global Technical Committee (GTC). The GTC takes the final decision on the actual extension provided to cover the business requirement. It is possible to join the (at least) monthly GTC calls to be part of the decision process. The GTC has to view the standard as a whole, maintain the intended semantics of existing fields, avoid duplications and ambiguities etc. This requires a fairly good knowledge of the FIX application layer. The GTC always welcomes additional resources willing to spend some time to properly extend the FIX Family of Standards.
Non-members can do the same by responding to calls for public review of extension proposals. They are posted on this forum with at least 2 weeks time for comments. These will then be addressed by the GTC again.
Thanks for the explanation. This has been extremely helpful.
What’s involved in being part of the GTC monthly meetings?
Regards,
James
As a FIX member you can join working groups and/or committees such as the GTC upon request. In the case of the GTC, involvement is mainly about reviewing and discussing extension proposals with the submitters.
Hi Hanno,
You mention the Esma requirement for “Passive or aggressive indicator”. In your view, should we be able to use the field 851, values 1 and 2 to map to Passive and Aggressive respectively.
Also mentioned to us was the field 1057 AggressorIndicator as a potential source for this information. I’m no expert to put it mildly, and so am having a hard time working out the difference between these, and which one we should be using.
Many thanks,
David.
Hi David,
you can use values 1 and 2 of LastLiquidityInd(851) or FillLiquidityInd(1443) in the ExecutionReport message to denote passive (adding liquidity) or aggressive (removing/taking liquidity) trading behaviour. The FIX fields are more granular than ESMA currently requires.
AggressorIndicator(1057) is similar but has a boolean data type, i.e. it can only distinguish two values. It was added by the FX Working Group to both ExecutionReport and TradeCaptureReport whereas LastLiquidityInd was only available in the ExecutionReport at the time. This gap was later closed by means of SideLiquidityInd(1444) which takes its valid values from LastLiquidityInd.
So there is a semantic overlap between the two and your business requirements should give you guidance. Last(Side)LiquidityInd gives you more flexibility in case you also need to support scenarios where it is neither passive nor aggressive. Fees are often connected to such a classification. You could even use both, e.g. using LastLiquidityInd on the ExecutionReport with a higher granularity and mapping that to the two values of AggressorIndicator in the TradeCaptureReport. Obviously, the Rules of Engagement need to define the mapping that takes place between the two sets of valid values.
Thanks, Hanno - just the detail I was looking for. Really glad to have found this forum!
1 Like