Imported from previous forum
Hi, If we are using FIX 4.2, is it necessary/manditory to incorporate the recent “Best Practices around Execution Venue Reporting”?
The FPL Announcement states:
FPL Announcement – FPL Buy-Side Representatives Create Best Practices Around Execution Venue Reporting
FIX Protocol Ltd. (FPL) launched Buy-Side Working Groups in the Americas, EMEA and Asia Pacific regions in order to provide a platform for buy-side representatives to discuss how their needs can be efficiently met by the automated trading community. One issue that they prioritized was an inconsistent response from the broker-dealer community with regards to broker reporting of the execution venue on each fill. As a result, one of the main focuses of the FPL buy-side community has been to standardize the reporting of the executing venue and create a rules of engagement / best practices document to help resolve these challenges.
An effort was undertaken to define the usage expectations around the FIX fields that describe the final destination point of an execution, the capacity of the broker for that execution and the nature of liquidity (added or taken) for that trade. The buy-side participants would encourage the sell-side community at large to implement these best practices after consulting with your clients on the readiness of their systems.
In scope for this effort are the following FIX tags:
Tag 29: LastCapacity
Tag 30: LastMkt Tag
851: LastLiquidityInd
Tag 29
LastCapacity – Broker capacity in order execution. This field is applicable only for
OrdStatus of Partial or Filled.
Valid Values: 1 = Agent
2 = Cross as Agent
3 = Cross as Principal
4 = Principal
For executions in which a broker is the provider of liquidity, this should be indicated using a value of Principal. In cases where riskless principal is employed, this should be indicated using a value of Cross as Principal to distinguish from situations where capital commitment has occurred.
Tag 30
LastMkt – Market of execution for last fill, or an indication of the market where an order
was routed.
“Best Practices” identified by the buy-side for the use of this tag are: Use only Market Identifier Codes (MICs) regardless of FIX version. The actual destination where the fill was executed should be relayed in the tag (i.e. intermediate hops that were taken to get to the final point of execution are irrelevant for scope of this effort and should not be considered a valid entry for tag 30). All market centers, including broker crossing systems and alternative trading systems, should register or be encouraged to register for a MIC code. Where a market center has separate segregated orders books, such as a „Dark‟ and a "Lit‟ order book run by a single exchange or MTF, the market center should register for a separate MIC for each order book. Where a venue exists without a MIC the broker/dealer‟s internal description for that venue will be required. Do not use indeterminate identifiers such as, “Other” or “Not Specified” as they add no value. Markets should be asked to apply for MIC codes and use separate MIC codes for Dark/Lit venues when a gap is discovered. For a list of current MICs or information on how to apply for a MIC follow this link - Market Identifier Code Homepage. In the end the use of this tag is a mapping exercise from one system to the next and a premium should be placed on client configurability.
The use of MICs is standard from FIX version 4.3 and on but the proliferation of markets has made it imperative to use this standard in the earlier versions of FIX as well. This departure from the FIX 4.2 protocol is recognized but from our viewpoint is unavoidable and necessary.
Tag 851 (Alternative UDF: 8010)
LastLiquidityInd – This is a FIX 4.4 field the buy-side is advocating be used in <= FIX 4.3
sessions. For systems unable to use tag 851 over <= FIX 4.3, the equivalent custom tag
8010 can be used to convey the same information. Indicator to identify whether this fill was a
result of a liquidity provider providing or a liquidity taker taking the liquidity. This field is
applicable only for OrdStatus of Partial or Filled.
Valid Values:
1 = Added Liquidity
2 = Removed Liquidity
3 = Liquidity Routed Out
4 = Auction
It is the opinion of the FPL Buy-Side Working Groups that these tags should be required, for the purposes of these best practices, for each and every execution where fill information is being relayed and that the information be as accurate as possible.
For clarification, would we need to address our existing connections to incorporate the best practices, or just add the best practices to new connections that we create in the future?
Thanks in advance,
Eddie
For clarification, would we need to address our existing connections to incorporate the best practices, or just add the best practices to new connections that we create in the future?
Thanks in advance,
Eddie
Hi Eddie,
In publishing the execution venue best practices, the intent of the working group (which I co-chaired) was to encourage brokers to build up the ability to provide details on how fills are being accomplished, and to suggest a consistent format for providing that information. The intent is that once a broker has built this capability, for their clients it becomes a simple matter of asking for it to be turned on in their FIX session. You can then store/process/analyse that information as you see fit. So to answer your question, the intent is that it applies to both current and future connections. Since the publication of the guidelines, many of the members of the working group have been asking brokers to support this, many of which are now able to provide this information in at least some of the markets that they deal in. Going forward we hope to touch base with many of the OMS vendors to encourage them to process and display this information in their products. If you have more questions please feel free to email me directly or continue posting to this thread.
Regards
Brian
Hi Brian
We I am looking into support for this within our dark pool however there doesn’t seem to be much information out how this is expected to work.
It isnt clear to me where a dark pool matches 2 orders at midpoint, who is the supplier and who is the taker. They both sought to fill at midpoint, it’s just that one order arrived earlier than the other. It’s a bit clearer on a lit market where an order crosses the spread that they are the taker and the passive side is the supplier.
I can understand that if one order is sent in as IOC then it would be a taker but what if both orders are just day orders that match.
A clarification would be much appreciated.
Kind regards
Michael
Hi Eddie,
In publishing the execution venue best practices, the intent of the working group (which I co-chaired) was to encourage brokers to build up the ability to provide details on how fills are being accomplished, and to suggest a consistent format for providing that information. The intent is that once a broker has built this capability, for their clients it becomes a simple matter of asking for it to be turned on in their FIX session. You can then store/process/analyse that information as you see fit. So to answer your question, the intent is that it applies to both current and future connections. Since the publication of the guidelines, many of the members of the working group have been asking brokers to support this, many of which are now able to provide this information in at least some of the markets that they deal in. Going forward we hope to touch base with many of the OMS vendors to encourage them to process and display this information in their products. If you have more questions please feel free to email me directly or continue posting to this thread.
Regards
Brian
Hi Michael
Apologies for the long delay in replying, I’ve had a couple of discussions regarding this but unfortunately we don’t have a clear conclusion on this. In my opinion tag 851 is really more designed for exchange-based trading and consequently it doesn’t make a lot of sense in the context of dark pools. In your example where two day orders match in a dark pool, I think an argument could be made that both are suppliers of liquidity, so perhaps the maker/taker attribute is not useful in this context in which case you should omit tag 851, or alternatively you could label it with a value of 1 (Added Liquidity). We will bring this up for further discussion the next time the working group meets, and I will reply with further information if we reach any decisions on this. In the meantime, you may need to discuss directly with clients who are asking for this data to see if their opinions differ from mine. I would also encourage anyone reading this thread to weigh in with their thoughts.
Regards
Brian
Hi Brian
We I am looking into support for this within our dark pool however there doesn’t seem to be much information out how this is expected to work.
It isnt clear to me where a dark pool matches 2 orders at midpoint, who is the supplier and who is the taker. They both sought to fill at midpoint, it’s just that one order arrived earlier than the other. It’s a bit clearer on a lit market where an order crosses the spread that they are the taker and the passive side is the supplier.
I can understand that if one order is sent in as IOC then it would be a taker but what if both orders are just day orders that match.
A clarification would be much appreciated.
Kind regards
Michael
Hi Eddie,
In publishing the execution venue best practices, the intent of the working group (which I co-chaired) was to encourage brokers to build up the ability to provide details on how fills are being accomplished, and to suggest a consistent format for providing that information. The intent is that once a broker has built this capability, for their clients it becomes a simple matter of asking for it to be turned on in their FIX session. You can then store/process/analyse that information as you see fit. So to answer your question, the intent is that it applies to both current and future connections. Since the publication of the guidelines, many of the members of the working group have been asking brokers to support this, many of which are now able to provide this information in at least some of the markets that they deal in. Going forward we hope to touch base with many of the OMS vendors to encourage them to process and display this information in their products. If you have more questions please feel free to email me directly or continue posting to this thread.
Regards
Brian
Edward,
Tag 29 and 30 absolutely use on the exec Reports.
Tag 851, although in the future will be very advantageous is not really in a fit state at the moment.
The only Vendor i know that has implemented it is Bloomberg, and they have not added in the Value of 4 (auctions),
Regards,
Carl
Hi, If we are using FIX 4.2, is it necessary/manditory to incorporate the recent “Best Practices around Execution Venue Reporting”?
The FPL Announcement states:
FPL Announcement – FPL Buy-Side Representatives Create Best Practices Around Execution Venue Reporting
FIX Protocol Ltd. (FPL) launched Buy-Side Working Groups in the Americas, EMEA and Asia Pacific regions in order to provide a platform for buy-side representatives to discuss how their needs can be efficiently met by the automated trading community. One issue that they prioritized was an inconsistent response from the broker-dealer community with regards to broker reporting of the execution venue on each fill. As a result, one of the main focuses of the FPL buy-side community has been to standardize the reporting of the executing venue and create a rules of engagement / best practices document to help resolve these challenges.
An effort was undertaken to define the usage expectations around the FIX fields that describe the final destination point of an execution, the capacity of the broker for that execution and the nature of liquidity (added or taken) for that trade. The buy-side participants would encourage the sell-side community at large to implement these best practices after consulting with your clients on the readiness of their systems.
In scope for this effort are the following FIX tags:
Tag 29: LastCapacity
Tag 30: LastMkt Tag
851: LastLiquidityIndTag 29
LastCapacity – Broker capacity in order execution. This field is applicable only for
OrdStatus of Partial or Filled.
Valid Values: 1 = Agent
2 = Cross as Agent
3 = Cross as Principal
4 = Principal
For executions in which a broker is the provider of liquidity, this should be indicated using a value of Principal. In cases where riskless principal is employed, this should be indicated using a value of Cross as Principal to distinguish from situations where capital commitment has occurred.Tag 30
LastMkt – Market of execution for last fill, or an indication of the market where an order
was routed.
“Best Practices” identified by the buy-side for the use of this tag are: Use only Market Identifier Codes (MICs) regardless of FIX version. The actual destination where the fill was executed should be relayed in the tag (i.e. intermediate hops that were taken to get to the final point of execution are irrelevant for scope of this effort and should not be considered a valid entry for tag 30). All market centers, including broker crossing systems and alternative trading systems, should register or be encouraged to register for a MIC code. Where a market center has separate segregated orders books, such as a „Dark‟ and a "Lit‟ order book run by a single exchange or MTF, the market center should register for a separate MIC for each order book. Where a venue exists without a MIC the broker/dealer‟s internal description for that venue will be required. Do not use indeterminate identifiers such as, “Other” or “Not Specified” as they add no value. Markets should be asked to apply for MIC codes and use separate MIC codes for Dark/Lit venues when a gap is discovered. For a list of current MICs or information on how to apply for a MIC follow this link - Market Identifier Code Homepage. In the end the use of this tag is a mapping exercise from one system to the next and a premium should be placed on client configurability.The use of MICs is standard from FIX version 4.3 and on but the proliferation of markets has made it imperative to use this standard in the earlier versions of FIX as well. This departure from the FIX 4.2 protocol is recognized but from our viewpoint is unavoidable and necessary.
Tag 851 (Alternative UDF: 8010)
LastLiquidityInd – This is a FIX 4.4 field the buy-side is advocating be used in <= FIX 4.3
sessions. For systems unable to use tag 851 over <= FIX 4.3, the equivalent custom tag
8010 can be used to convey the same information. Indicator to identify whether this fill was a
result of a liquidity provider providing or a liquidity taker taking the liquidity. This field is
applicable only for OrdStatus of Partial or Filled.
Valid Values:
1 = Added Liquidity
2 = Removed Liquidity
3 = Liquidity Routed Out
4 = AuctionIt is the opinion of the FPL Buy-Side Working Groups that these tags should be required, for the purposes of these best practices, for each and every execution where fill information is being relayed and that the information be as accurate as possible.