Hi, I am unclear about the usage of 20063 (or repeating group 452=63). A buy-side firm receives an execution report from their broker with the following tags:
Tag 30 (Last Market): BATF
Tag 20063 (PartyIDSystematicInternaliser):
Tag 2524 (TradeReportingIndicator): 8
Tag 574 (SI Execution) is NOT set
For transaction reporting the buy-side firm needs to know if the execution was done by an SI. Because of 20063 being set it determined that this was the case. However, the broker argued that they didnât execute in SI capacity. Their usage of 20063 is "We send tag 20063 if we are an SI in the stock, however that doesnât mean that the execution takes place on the SI."
The Trade Reporting Implementation Guide isnât clear on when the 20063 should be set. It says âthat brokers identify whether they are an SI or not at the point of order receiptâ but not if they are executing in that capacity.
Any guidance will be appreciated. Thanks, Gernot
Please have a look at the MiFID II Extension Packs (FIX Extension Packs â FIX Trading Community v2.1) as follows.
EP222, section 2.1, table 2, row #1 defines the use of party role 63 for the identification of the trading venue where the transaction was executed. If the order was not executed as part of an SI venue then party role 63 should not be used.
EP228, section 2.2, table 2, row #2 defines the use case of generically identifying that a fill has come from an SI. Use LastMkt(30) = âSINTâ. This should be accompanied by a party instance with party role 63 to also convey the MIC of the SI. Alternatively, one can put the SI MIC directly into LastMkt and set MatchType(574)=9 (SI) to express the fact that the fill took place at an SI.
EP228, section 2.2, table 2, row #15 defines the use case âIdentifying the investment firm is an SI for the instrumentâ by means of a new value of PartySubIDType(803) = 76 (SI). This information can only be attached to a party instance, for example for the broker (with party role 1).
The root level parties block of the order handling and execution messages is intended to capture actors (party roles) specific to the order or execution, not specific to the instrument. Static data (like address information but also the fact that an actor is an SI in an instrument) should only be one level deeper (party sub information) in the order handling messages. Using user-defined tags such as 20063 indicates the lack of support for repeating groups. They did already exist in FIX 4.2 but many have chosen not to implement them at the time. This needs to change now that we have 2018 and MiFID II!
Last not least another option for static information related to an instrument. The instrument component has a repeating group called InstrumentParties. This is intended for actors related to the specific instrument. This could be an SI but also the market maker(s) etc. This was already added with FIX 4.4 but is probably rarely used.
Hi Hanno,
thanks a lot for the fast answer and providing specific pointers to the documentation. Thatâs very helpful for my discussion with the broker.
Best regards
Gernot
Interestingly I was going to post a question today on this EXACT topic! We have yet to start transaction reporting SI MIC values in our buy-side report due to the numerous inconsistencies and differing interpretations of how SI trades are sent via FIX. UBS, for example, has the following set-up
- Sends Tag 20063 on ALL trades where they are an SI in that instrument
- Denoting trades where they are executing as an SI using MatchType (Tag 574) = 9
Which of course goes against other brokers who donât use 574 at all (they only use 20063), then other brokers who donât use 20063 at all but use 574⌠Itâs a mess to say the least. Weâre working with our OMS vendor to improve the SI flagging within their data model, but unless the sell-side gets consistent, itâs at best a moving target.
There seems to be two ways to indicate the âSInessâ of an execution as Hanno implies.
- Tag30=SINT and a party instance with 63=SI MIC
OR - tag30=SI MIC and tag 574=9 (SI)
I see a lot of brokers supporting option 2, and given the flexibility in FIX should we either settle on one method or build in the need to support both?
Both options appear to be sufficient. Using only 20063 and 574 not at all is ambiguous and cannot really work. The presence of 20063 could then mean âSI of the instrumentâ or âthis is an SI executionâ. The ambiguity should best be avoided by using 574 for actual SI executions (option 2). SINT should only be used for LastMkt(30) when the SI does not have a MIC. LastMkt(30) should always have MIC if available (and not stored in the parties component).
Agree - so message construct seems pretty clear. If there is no SI MIC for the venue then use Option 1, 574 could be added to that option.
Not quite, LastMkt(30)=SINT and MatchType(574)=9 express the same thing, i.e. execution took place at an SI. Option 1 says to put the SI MIC into role 63. But if the SI has a MIC then it should be put into LastMkt. Option 1 can hence only be defined as follows:
Option 1: Tag30=SINT and a party instance with role=63, ID=SI identifier (non-MIC) and ID source = N (LEI)
Great - thatâs clear so there are two and only two possible contructs that need to coded to.
If I may ask any other buy-side colleagues on this forum, is everyone reporting the SI MIC value in their transaction report only in cases where a counterparty executed on their SI or are they populating SI MIC when the counterparty has indicated they are an SI on an instrument?
In other words - are you using trade-specific MIC values (tag 30 or even tag 20063) or do you have an SI MIC value as mapped to a counterparty?
Whatâs interesting is that Iâm aware of an ARM soon to release a data enrichment service that will populate the SI MIC for you as part of their rules engine validation, and theyâre doing this using counterparty mappings, not trade-by-trade MIC values.
Responding to my own post. Had a useful chat with the Investment Association on this topic where I have concluded the following:
-Referring back to Genotâs original post, Tag 20063 is NOT sufficient for transaction reporting seeing as it only indicates the broker is an SI on that particular instrument, not that they have executed on their SI book for that specific execution
-Aforementioned ARMâs data enrichment service will not work as advertised, as the ARM will not have enough information (for equity trades) having their current data set. The ARM would instead need to receive the SI execution flag (Tag 574=9) in order to populate the SI MICs on transaction reports where appropriate. This topic for us anyway is restricted just to equities, seeing as our FI trades are generally executed on MTFs.
-Not sure about others but we are seeing a lot of inconsistency in Tag 20073 values coming from the sell-side. SI executions often are XOFF where they should contain the SI MIC, effectively matching that of LastMkt (Tag 30). Weâre reaching out to the brokers who are consistent right now to firstly confirm our interpretation of the data they send us and will secondly push for fixes as appropriate.
-We have additionally requested our OMS vendor to revisit their internal logic on how they flag SI executions so that ONLY trades with Tag 574=9 are labeled as SI executions (their current logic is identifying false positives as Tag 20063 trades are incorrectly flagged as SI).
Would appreciate hearing everyone elseâs thoughts and concerns on this topic.