Imported from previous forum
The Global Technical Committee has reviewed and preliminarily approved resubmission of the MMT v3 support proposal. It was originally submitted and publicly reviewed in May 2016. The proposal builds on the support of the MMT Model already incorporated into FIX in 2012/2013 with EP 163 and EP 186. Note that verbiage of valid values and their elaborations may be subject to minor changes to enhance clarity of definitions. Any such changes will be incorporated together with feedback from the public comment period into the final ASBUILT version.
This document now enters a public comment period in which public review and feedback is encouraged. Once the public comment period closes, the Global Technical Governance Board will meet to review public comments before final approval.
Please post feedback, comments, and questions as replies to this discussion thread.
A link to the proposal can be found at:
http://www.fixtradingcommunity.org/pg/file/fplpo/read/3353809/fix-protocol-ga-mmt-v3
The public comment period ends on August 16, 2016.
Document looks good to me. I have one question/request though – it’s very important that all of the ESMA trade flags are available not just on the trade capture report but also the trade capture report ACK as well. Some of the data workflow analysis we’ve been doing has uncovered some situations where the APA/trading venue derives flags (i.e. they wouldn’t be on the trade capture report itself as sent from the investment firm) which need to be sent to the investment firm to enable them to fulfil their transaction reporting/record keeping obligations. A good example is the suite of PRIC/ILQD/NLIQ EMSA codes for negotiated trades.
We also also going to need to make these codes available on execution reports at some point and, though I wouldn’t expect this to be a subject for this GA, I just want to make sure that there’s nothing in the design that would prevent these from being added to execution reports via a separate GA.
The draft RTS document includes seven Waiver indicators : LRGS, RFPT, NLIQ, OILQ, PRIC, SIZE & ILQD as potential to be reported in transaction reports - page 455 of https://www.esma.europa.eu/sites/default/files/library/2015/11/2015-esma-1464_annex_i_-_draft_rts_and_its_on_mifid_ii_and_mifir.pdf
However, TrdRegPublicationGrp/TrdRegPublicationReason on page 20/21 of the MMT suggestions only include five enumerations - looks to be missing LRGS and ILQD (though includes NLIQ for equity Illiquid). How would LRGS or ILQD be represented under this proposal please?
Similarly, there are 19 Post Trade Deferral flags (page 456 of the RTS) but only three represented as TrdRegPublicationReason(s) on page 25 of the MMT doc.
Is there a more complete enumeration for TrdRegPublicationReason outside this document, or are those other waiver/deferral flags deliberately excluded as they will be treated differently?
Jim, Ian,
during the work for the MMT Gap Analysis, it became apparent that RTS 1 and RTS 2 contain more than the outbound broadcasting of trade information with appropriate flags which is what MMT covers. There was then a clear scope decision to focus on the trade flags of RTS 1 and 2 and to omit the inbound (trade entry) side with its request/response mechanism (involving TCRAck) as it is not part of MMT.
I agree that the information needs to be on the TCRAck to play back values calculated by the receiving venue but this scope is to be targeted by a separate Gap Analysis which will cover everything within RTS 1 and 2 (and other RTS’s) with the exception of the trade flags already covered here.
This separate Gap Analysis would then cover the interactive/transactional (inbound) side of things and include further fields on the TCR and then also cover the TCRAck.
The complete RTS document (not just RTS 1 and RTS 2) is very large. It is therefore important to be clear of the scope of any Gap Analysis covering parts of it. There will be no single Gap Analysis covering its entirety. Ian, the pages you are referring to were taken from RTS 22 (twenty-two) which targets transaction reporting. The current Gap Analysis defines its scope in chapter 1.2.1, limiting it to RTS 1 and RTS 2 and further to the trade flags contained therein. The tables in scope have been copied from the RTS document into this chapter.
You are missing values LRGS and ILQD mentioned in RTS 22 on page 455 as pre-trade waivers.
- LRGS is covered as post-trade deferral flag by TrdRegPublicationReason(tbd) = 6 (Large in scale). LRGS as pre-trade waiver flag is not defined in RTS 1 or 2 and should be covered by the separate Gap Analysis mentioned above.
- ILQD has been included and is covered by TrdRegPublicationReason(tbd) = 4 (No public quoting as instrument is illiquid).
Looking at the pages you reference, it is important to note that page 456 does not contain 19 “Post Trade Deferral flags”. It contains 19 “OTC Post Trade Indicators” as ESMA field 63 is called. Some but not all of them relate to post trade deferrals. Hence the perceived shortage of values for TrdRegPublicationReason(tbd).
I hope these comments help to clarify scope of the Gap Analysis at hand as well as the approach for dealing with the outstanding requirements of RTS.
Regards,
Hanno.
All,
I agree that all additions and enhancements proposed for TCR also be applied to TCRAck.
Second, there are inconsistencies in the 2.1.1 Per-value mapping table in the row for RTS 2: ILQD/LRGS/SIZE - the enum values assigned in the Data Dictionary are 6, 7 & 8, not 7, 8 & 9.
Third, I suggest changing the wording of the enumerations for TradePublishIndicator(1390) so that they can be used appropriately by an APA returning the decision to the client in TCRAck. E.g. 0=Trade is not to be published, 1=Trade is to be published, 2=Publication is deferred.
Regards,
Dean
Hi Dean,
we want to defer the inbound side to a separate Gap Analysis to have a clear scope. This includes the adaptation of elaborations to cover additional workflows / use cases.
Regards,
Hanno.