Hi all,
we use PartyRole [452] = 1 to identify the broker to which the broker’s client order is sent. When the broker itself routes the order to an Exchange, which PartyRole (or another tag) suits the best to report back the Exchange to the broker’s client?
Many thanks,
laurent
Hi Laurent,
Generally tag 30 (LastMkt) is used for this, and our recommendation would be to use an ISO market identifier code (MIC).
Jim.
1 Like
Hi Jim,
thanks for your comment. Should PartyID be normalised too using MIC?
Hi
There is a value “G = Market Identifier Code (ISO 10383) MIC” for the various PartyIdSource fields which you can use. I’ll defer to others on if/how this is actually used in practice.
Jim.
Could you elaborate on what you mean with “normalised”?
PartyID(448) may contain different kinds of information, depending on the value chosen for PartyRole(452), which has 127 different values by now. A MIC in PartyID(448) only applies to some of these values, e.g. PartyRole(452)=22 (Exchange). However, the exchange where an execution of an order actually took place should be conveyed by LastMkt(30) in the ExecutionReport(35=8) message as pointed out by @jkaye.
There was a recommended practices published by the Global Buy-side WG that called for using LastMkt(30) to report which exchange the fill being reported to the buy-side was executed, and they also called for using MIC values in tag 30. I can’t find the document now on the FIX website so I don’t know what happened to it.
Filling tag 30 with a MIC makes sense indeed. I was just a bit leery about PartyID(448) when PartyRole(452)=1 because not all brokers we are connected to have a MIC.
It’s on the ‘Business Practices’ page. I’ve copied the relevant section below (though do look on the website for the actual document as there are footnotes which aren’t copied):
LastMkt – Market of execution for last fill, or an indication of the market where an order
was routed. Whenever possible, the market reported should be the market where the execution
occurred.
General comments
• Use only Market Identifier Codes (MICs) regardless of FIX version.
• The actual destination where the fill was executed should be relayed in this tag1
. 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 LastMkt(30).
• For a list of current MICs or information on how to apply for a MIC follow this link - Market
Identifier Code Homepage.
Trading Venue Executions
• 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 order 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 market
center runs an integrated order book containing both dark and lit orders, this will have a single
MIC.
• If the venue does not distinguish dark/lit, the convention is to base the dark/lit nature of an
execution as being taken from the order that caused that execution. So if the order was a lit
order, all executions will be treated as lit (even if the order crossed with a dark order, where the
market counterparty’s executions would be flagged as dark).
• If a valid MIC doesn’t exist on the venue that the trade occurred, LastMkt(30) should still be
included and should use the XXXX MIC code as per the list of ISO 10383
Exchange/MarketIdentifier Codes (xls).
Broker Executions
• All brokers are to have an operator-level MIC in each major location in which they operate2
.
• All brokers that operate automated execution systems (e.g. BCN, MTF, ATS) should have a
segment-level MIC for each one and use that MIC in LastMkt(30) on executions arising from
these systems.
• Systematic Internalisers are to have their own MICs.
• For OTC executions outside Systematic Internalisers, brokers may either use the appropriate
operator-level MIC in LastMkt(30) or have separate segment-level MICs at their discretion.
PartyRole=1 (Executing Firm) is about the broker, not an exchange therefore PartyID would never be a MIC.