Imported from previous forum
Is there a (burgeoning) standard mechanism for indicating that an execution has occurred on a dark or lit segment of an integrated book?
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
> Is there a (burgeoning) standard mechanism for indicating that an execution has occurred on a dark or lit segment of an integrated book?
No market standard. Using FIX 4.2 some firms will modify tag 30 on exec reports to distinguish.
Personally I think we should see 2 ISO MICS - light and dark - per ex destination…
I am not aware of a standard here but I am not sure distinct MICs are the best approach. You do not want a hierarchy of MICs, one for ExDestination and sub-MICs for the lit and dark book. Also without a hierarchy, there is often a lot more attached to a MIC, e.g. trading admissions which you do not want to duplicate. Something more lightweight is needed here.
There is a user defined field (5018 OrderBookID) that goes more in the direction I think we should be going. Another option is to extend an existing tag (1021 MDBookType) beyond market data. It covers all kinds of situations where you have distributed liquidity of a single instrument within the same trading venue, i.e. round lot vs odd lot book, retail vs institutional order book.
Is there a (burgeoning) standard mechanism for indicating that an execution has occurred on a dark or lit segment of an integrated book?
No market standard. Using FIX 4.2 some firms will modify tag 30 on exec reports to distinguish.
Personally I think we should see 2 ISO MICS - light and dark - per ex destination…
Would TradingSessionID (336) be another option?
I am not aware of a standard here but I am not sure distinct MICs are the best approach. You do not want a hierarchy of MICs, one for ExDestination and sub-MICs for the lit and dark book. Also without a hierarchy, there is often a lot more attached to a MIC, e.g. trading admissions which you do not want to duplicate. Something more lightweight is needed here.
There is a user defined field (5018 OrderBookID) that goes more in the direction I think we should be going. Another option is to extend an existing tag (1021 MDBookType) beyond market data. It covers all kinds of situations where you have distributed liquidity of a single instrument within the same trading venue, i.e. round lot vs odd lot book, retail vs institutional order book.
Is there a (burgeoning) standard mechanism for indicating that an execution has occurred on a dark or lit segment of an integrated book?
No market standard. Using FIX 4.2 some firms will modify tag 30 on exec reports to distinguish.
Personally I think we should see 2 ISO MICS - light and dark - per ex destination…
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
> Would TradingSessionID (336) be another option?
I’ve normally seen this used to
(a) allow an exchange to notify sell sides about exchange status
(b) allow a FIX hub like Fidessa Express or Autex notify buy-side clients about if a sell-side connection is up or down, in which case tag 336 will have the sell-side CompID.
such as
2010-06-03 00:10:01,255 INFO - <280 TradingSessionStatus (8=FIX.4.29=9735=h49=hub56=buy-side115=sell-side34=28043=N52=20100602-22:10:00369=261336=sell-side340=310=174)
This in a 35=h message.
TradingSession(Sub)ID has a different intention, i.e. to represent (sub-)phases in terms of time, not location. FIX 5 SP1 defines a list of recommended valid values even if you can still use any value for backward compatibility.
TradingSessionID is for larger phases that can be expressed in terms of the business day (e.g. 1=Day, 2=Half Day,…). TradingSessionSubID is for shorter phases that are part of TradingSessionID (e.g. 1=Pre-Trading, 2=Opening,…).
Would TradingSessionID (336) be another option?
I am not aware of a standard here but I am not sure distinct MICs are the best approach. You do not want a hierarchy of MICs, one for ExDestination and sub-MICs for the lit and dark book. Also without a hierarchy, there is often a lot more attached to a MIC, e.g. trading admissions which you do not want to duplicate. Something more lightweight is needed here.
There is a user defined field (5018 OrderBookID) that goes more in the direction I think we should be going. Another option is to extend an existing tag (1021 MDBookType) beyond market data. It covers all kinds of situations where you have distributed liquidity of a single instrument within the same trading venue, i.e. round lot vs odd lot book, retail vs institutional order book.
Is there a (burgeoning) standard mechanism for indicating that an execution has occurred on a dark or lit segment of an integrated book?
No market standard. Using FIX 4.2 some firms will modify tag 30 on exec reports to distinguish.
Personally I think we should see 2 ISO MICS - light and dark - per ex destination…
Yes. That is the intension that is apparent from the specification. However, I recall seeing posts on this discussion forum about also using TradingSessionID (336) to denote separate books (e.g. odd lots). I was curious whether such a use would be deemed appropriate.
TradingSession(Sub)ID has a different intention, i.e. to represent (sub-)phases in terms of time, not location. FIX 5 SP1 defines a list of recommended valid values even if you can still use any value for backward compatibility.
TradingSessionID is for larger phases that can be expressed in terms of the business day (e.g. 1=Day, 2=Half Day,…). TradingSessionSubID is for shorter phases that are part of TradingSessionID (e.g. 1=Pre-Trading, 2=Opening,…).
Would TradingSessionID (336) be another option?
I am not aware of a standard here but I am not sure distinct MICs are the best approach. You do not want a hierarchy of MICs, one for ExDestination and sub-MICs for the lit and dark book. Also without a hierarchy, there is often a lot more attached to a MIC, e.g. trading admissions which you do not want to duplicate. Something more lightweight is needed here.
There is a user defined field (5018 OrderBookID) that goes more in the direction I think we should be going. Another option is to extend an existing tag (1021 MDBookType) beyond market data. It covers all kinds of situations where you have distributed liquidity of a single instrument within the same trading venue, i.e. round lot vs odd lot book, retail vs institutional order book.
Is there a (burgeoning) standard mechanism for indicating that an execution has occurred on a dark or lit segment of an integrated book?
No market standard. Using FIX 4.2 some firms will modify tag 30 on exec reports to distinguish.
Personally I think we should see 2 ISO MICS - light and dark - per ex destination…
It was my personal opinion as there is no general statement from FPL that anything that is not defined in the spec as permissible behaviour is deemed a mis-use. Posts in the forum must be seen as personal opinions if they are not backed by the spec or an official Recommended Practices document.
FPL has intentionally chosen not to require certification of each and every interface spec out there. The downside is that often enough, many different interpretations exist for the same concept. The reason may be as simple as not wanting to go through FPL and ask for a FIX extension and to just look for the best field(s) that are not limited to a list of pre-defined values and define one’s own stuff in there.
I will use this post to encourage people once again to come forward and work with FPL to make sure their usage of FIX aligns with the intentions of the spec and to put in the extra effort to go through a Gap Analysis process to get extensions where they are needed. It is less work than people might think and it saves the community a lot more work down the road when they do not hit all these different interpretations and have to code to them.
Part of the beauty of FIX is its flexibility. Lack of enforcement should not encourage mis-use as it is a disservice to the FIX community and requires money that is better spent elsewhere. Mis-use sounds like it is always intentional which it is not. Lack of knowledge regarding FIX concepts is a real issue. Part of the solution is to refrain from only reading message layouts and not the surrounding text of the spec. A little more time spent upfront before designing a FIX interface is a good investment for the benefit of the entire FIX community.
Yes. That is the intension that is apparent from the specification. However, I recall seeing posts on this discussion forum about also using TradingSessionID (336) to denote separate books (e.g. odd lots). I was curious whether such a use would be deemed appropriate.
TradingSession(Sub)ID has a different intention, i.e. to represent (sub-)phases in terms of time, not location. FIX 5 SP1 defines a list of recommended valid values even if you can still use any value for backward compatibility.
TradingSessionID is for larger phases that can be expressed in terms of the business day (e.g. 1=Day, 2=Half Day,…). TradingSessionSubID is for shorter phases that are part of TradingSessionID (e.g. 1=Pre-Trading, 2=Opening,…).
Would TradingSessionID (336) be another option?
I am not aware of a standard here but I am not sure distinct MICs are the best approach. You do not want a hierarchy of MICs, one for ExDestination and sub-MICs for the lit and dark book. Also without a hierarchy, there is often a lot more attached to a MIC, e.g. trading admissions which you do not want to duplicate. Something more lightweight is needed here.
There is a user defined field (5018 OrderBookID) that goes more in the direction I think we should be going. Another option is to extend an existing tag (1021 MDBookType) beyond market data. It covers all kinds of situations where you have distributed liquidity of a single instrument within the same trading venue, i.e. round lot vs odd lot book, retail vs institutional order book.
Is there a (burgeoning) standard mechanism for indicating that an execution has occurred on a dark or lit segment of an integrated book?
No market standard. Using FIX 4.2 some firms will modify tag 30 on exec reports to distinguish.
Personally I think we should see 2 ISO MICS - light and dark - per ex destination…
[ original email was from Andrew Bowley - andrew.bowley@nomura.com ]
Hanno, I’m interested to see your views on the MIC codes. Personally I think separate MIC codes is critical. At a regulation level, a lit book (eg Chi-X) is forced to operate distinctly from a dark book (Chi-Delta), and the venues are not allowed to mix the flow from one pool to the other. They are distinct venues and should be treated as such. Additionally it is critical for all post trade processing (venue activity reporting on fills, TCA analyses, and their consequent impact on smart routing behaviour) that this distinction can be made. Our clients are consequently asking us to create dummy MIC codes to compensate for use of tag 30, so that we use CHIX vs CHID for example, even though CHID is not an ISO standard. It would be better for all if such standards were properly established and adopted to avoid growth of alternative MICs. Anything that works off another tag will mean multiple touch points wherever MICs are used having to adapt to a new multi tag denomination. At the regulatory level, CESR are taking on board exactly this perspective when thinking about the tape quality and plans for MiFID II. Andrew
It was my personal opinion as there is no general statement from FPL that anything that is not defined in the spec as permissible behaviour is deemed a mis-use. Posts in the forum must be seen as personal opinions if they are not backed by the spec or an official Recommended Practices document.
FPL has intentionally chosen not to require certification of each and every interface spec out there. The downside is that often enough, many different interpretations exist for the same concept. The reason may be as simple as not wanting to go through FPL and ask for a FIX extension and to just look for the best field(s) that are not limited to a list of pre-defined values and define one’s own stuff in there.
I will use this post to encourage people once again to come forward and work with FPL to make sure their usage of FIX aligns with the intentions of the spec and to put in the extra effort to go through a Gap Analysis process to get extensions where they are needed. It is less work than people might think and it saves the community a lot more work down the road when they do not hit all these different interpretations and have to code to them.
Part of the beauty of FIX is its flexibility. Lack of enforcement should not encourage mis-use as it is a disservice to the FIX community and requires money that is better spent elsewhere. Mis-use sounds like it is always intentional which it is not. Lack of knowledge regarding FIX concepts is a real issue. Part of the solution is to refrain from only reading message layouts and not the surrounding text of the spec. A little more time spent upfront before designing a FIX interface is a good investment for the benefit of the entire FIX community.
Yes. That is the intension that is apparent from the specification. However, I recall seeing posts on this discussion forum about also using TradingSessionID (336) to denote separate books (e.g. odd lots). I was curious whether such a use would be deemed appropriate.
TradingSession(Sub)ID has a different intention, i.e. to represent (sub-)phases in terms of time, not location. FIX 5 SP1 defines a list of recommended valid values even if you can still use any value for backward compatibility.
TradingSessionID is for larger phases that can be expressed in terms of the business day (e.g. 1=Day, 2=Half Day,…). TradingSessionSubID is for shorter phases that are part of TradingSessionID (e.g. 1=Pre-Trading, 2=Opening,…).
Would TradingSessionID (336) be another option?
I am not aware of a standard here but I am not sure distinct MICs are the best approach. You do not want a hierarchy of MICs, one for ExDestination and sub-MICs for the lit and dark book. Also without a hierarchy, there is often a lot more attached to a MIC, e.g. trading admissions which you do not want to duplicate. Something more lightweight is needed here.
There is a user defined field (5018 OrderBookID) that goes more in the direction I think we should be going. Another option is to extend an existing tag (1021 MDBookType) beyond market data. It covers all kinds of situations where you have distributed liquidity of a single instrument within the same trading venue, i.e. round lot vs odd lot book, retail vs institutional order book.
Is there a (burgeoning) standard mechanism for indicating that an execution has occurred on a dark or lit segment of an integrated book?
No market standard. Using FIX 4.2 some firms will modify tag 30 on exec reports to distinguish.
Personally I think we should see 2 ISO MICS - light and dark - per ex destination…
Hi Andrew,
I would concur that distinct venues can use distinct MIC values. I am not aware of any restrictions on getting more than one MIC for a given marketplace. The way you describe the separation fits the purpose of two MICs in my view as it includes non-technical aspects. I was concerned that the idea was to use CHIX as an overall MIC and subordinate values such as CHIL and CHID for lit and dark book. This would constitute a hierarchy which should be covered by the market segmentation concept in FIX (tag 1300 MarketSegmentID). However, MarketSegmentID is not (yet) part of the single order messages and the ExecutionReport.
Multiple MICs also seem to be the wrong choice when there are automated interactions between them that the user does not control, e.g. round lot and odd lot book with round lots being tradable in both (don’t know if that is a good example but I hope it shows what I mean).
Regards,
Hanno.
Hanno, I’m interested to see your views on the MIC codes. Personally I think separate MIC codes is critical. At a regulation level, a lit book (eg Chi-X) is forced to operate distinctly from a dark book (Chi-Delta), and the venues are not allowed to mix the flow from one pool to the other. They are distinct venues and should be treated as such. Additionally it is critical for all post trade processing (venue activity reporting on fills, TCA analyses, and their consequent impact on smart routing behaviour) that this distinction can be made. Our clients are consequently asking us to create dummy MIC codes to compensate for use of tag 30, so that we use CHIX vs CHID for example, even though CHID is not an ISO standard. It would be better for all if such standards were properly established and adopted to avoid growth of alternative MICs. Anything that works off another tag will mean multiple touch points wherever MICs are used having to adapt to a new multi tag denomination. At the regulatory level, CESR are taking on board exactly this perspective when thinking about the tape quality and plans for MiFID II. Andrew
As Registration Authority for the MIC standard, I can confirm there is no restrictions on getting more than one MIC for a given market place.
The example below is a valid reason why two MICs could be created. This can be done using the form on http://www.iso15022.org/MIC/homepageMIC.htm.
Note the standards ic currently being reviewed in order than MICs at operating level and segment level MICs are clearly identified and can they be linked together. The need for market segment MICs is definitly a need but the need for only identifying the market itself as well.
Today, we have occurences of segment MICs existing without an operating level MIC existing (eg Milan Stock Exchnage. All segments of that exchange have a MIC but the Milan Stock Exchange itself does not have any).
Hi Andrew,
I would concur that distinct venues can use distinct MIC values. I am not aware of Hope it helps.any restrictions on getting more than one MIC for a given marketplace. The way you describe the separation fits the purpose of two MICs in my view as it includes non-technical aspects. I was concerned that the idea was to use CHIX as an overall MIC and subordinate values such as CHIL and CHID for lit and dark book. This would constitute a hierarchy which should be covered by the market segmentation concept in FIX (tag 1300 MarketSegmentID). However, MarketSegmentID is not (yet) part of the single order messages and the ExecutionReport.
Multiple MICs also seem to be the wrong choice when there are automated interactions between them that the user does not control, e.g. round lot and odd lot book with round lots being tradable in both (don’t know if that is a good example but I hope it shows what I mean).
Regards,
Hanno.Hanno, I’m interested to see your views on the MIC codes. Personally I think separate MIC codes is critical. At a regulation level, a lit book (eg Chi-X) is forced to operate distinctly from a dark book (Chi-Delta), and the venues are not allowed to mix the flow from one pool to the other. They are distinct venues and should be treated as such. Additionally it is critical for all post trade processing (venue activity reporting on fills, TCA analyses, and their consequent impact on smart routing behaviour) that this distinction can be made. Our clients are consequently asking us to create dummy MIC codes to compensate for use of tag 30, so that we use CHIX vs CHID for example, even though CHID is not an ISO standard. It would be better for all if such standards were properly established and adopted to avoid growth of alternative MICs. Anything that works off another tag will mean multiple touch points wherever MICs are used having to adapt to a new multi tag denomination. At the regulatory level, CESR are taking on board exactly this perspective when thinking about the tape quality and plans for MiFID II. Andrew
Thank you very much for this clarification and background information. I was not aware of MICs on a segment level.
As Registration Authority for the MIC standard, I can confirm there is no restrictions on getting more than one MIC for a given market place.
The example below is a valid reason why two MICs could be created. This can be done using the form on http://www.iso15022.org/MIC/homepageMIC.htm.
Note the standards ic currently being reviewed in order than MICs at operating level and segment level MICs are clearly identified and can they be linked together. The need for market segment MICs is definitly a need but the need for only identifying the market itself as well.
Today, we have occurences of segment MICs existing without an operating level MIC existing (eg Milan Stock Exchnage. All segments of that exchange have a MIC but the Milan Stock Exchange itself does not have any).Hi Andrew,
I would concur that distinct venues can use distinct MIC values. I am not aware of Hope it helps.any restrictions on getting more than one MIC for a given marketplace. The way you describe the separation fits the purpose of two MICs in my view as it includes non-technical aspects. I was concerned that the idea was to use CHIX as an overall MIC and subordinate values such as CHIL and CHID for lit and dark book. This would constitute a hierarchy which should be covered by the market segmentation concept in FIX (tag 1300 MarketSegmentID). However, MarketSegmentID is not (yet) part of the single order messages and the ExecutionReport.
Multiple MICs also seem to be the wrong choice when there are automated interactions between them that the user does not control, e.g. round lot and odd lot book with round lots being tradable in both (don’t know if that is a good example but I hope it shows what I mean).
Regards,
Hanno.Hanno, I’m interested to see your views on the MIC codes. Personally I think separate MIC codes is critical. At a regulation level, a lit book (eg Chi-X) is forced to operate distinctly from a dark book (Chi-Delta), and the venues are not allowed to mix the flow from one pool to the other. They are distinct venues and should be treated as such. Additionally it is critical for all post trade processing (venue activity reporting on fills, TCA analyses, and their consequent impact on smart routing behaviour) that this distinction can be made. Our clients are consequently asking us to create dummy MIC codes to compensate for use of tag 30, so that we use CHIX vs CHID for example, even though CHID is not an ISO standard. It would be better for all if such standards were properly established and adopted to avoid growth of alternative MICs. Anything that works off another tag will mean multiple touch points wherever MICs are used having to adapt to a new multi tag denomination. At the regulatory level, CESR are taking on board exactly this perspective when thinking about the tape quality and plans for MiFID II. Andrew