Charbel Tahhan
31 May 2017 11:06pm
Hi all,
For the new MIFID II repeating group fields that the committee is adding, there is no mention of any example for 35=E message type. The approach is that anything on a ‘new order single’ applies to the entire suite of new order messages (including list and multileg). Having said that, I am looking to know if the repeating group are expected in the main body or inside the repeating group for 35=E.
Any ideas?
Thank you.
Charbel.
Hanno Klein
1 June 2017 8:10am
Could you please be more specific about the “the new MIFID II repeating group fields”? You cannot assume that anything added to NewOrderSingle can be applied to the entire suite of order messages including the ExecutionReport. It has to be explicit. 35=E is the NewOrderList message and has been out of scope for the Gap Analysis documents prepared for MiFID 2 so far. This means that you would currently have to use OrderCancelReplaceRequest on every order in the list to set the fields for MiFID after you have entered the orders with NewOrderList. Adding them to 35=E directly is then a question of convenience. In general, NewOrderList is not intended to be an exact copy of NewOrderSingle, just with a repeating group. Am I right to assume that you are not using NewOrderList in a high performance environment?
I have a supplementary and related question. We are seeing differences from entities submitting orders in their interpretation of the location of the Parties repeating group in List Orders (35:E). Some entities are placing the parties group outside of the order, tags 453,448,452,447 and expecting them to be applied to each order in the list; some are placing them inside the order group (tag 73). On the FIX standard it seems to indicate that the parties group is part of the order list and hence we would expect to the the 453,448,452,447 group on each order in the list - thoughts?
Also the SI indicator is not included on the 35:E standard is this something that should be added. Hanno I know from your original statement that the MiFID tags were excluded from the analysis - does that still hold true and following submission of a list order we should expect, almost immediately, a series of updates sending in the relevant MiFID related info?
Hi, we have received an interpretation from a client, where they are appending tag 20013 to every order in the repeating group in the list. It feels like we need to develop a response for list orders to accommodate the MiFID requirement (or have an explicit statement that they do not accommodate that information).
Sorry for missing the two posts in November with the questions to my post from June 1.
Location of parties component in NewOrderList(35=E)
NewOrderList has two repeating groups for parties, one outside the group of orders (ListOrdGrp) and one inside. The outside one is called RootParties and hence tags 1116-1119 have to be used. The inside one is called Parties and has the tags 453,448,452,447 mentioned above.
Missing SI Indicator in NewOrderList(35=E)
The “SI indicator” comes in two flavors. One is when you want to identify the SI on the order as a party which is covered by the parties component and role 63=SI. The other is when you want to flag the order as having been submitted by an SI. This is covered by the repeating group OrderAttributeGrp with OrderAttributeType(2594) = 5 (SI order). This has been added to FIX with EP222 but only for NewOrderSingle, NewOrderMultileg and ExecutionReport. With the extension for MiFID Part 4 (EP237, published mid-december), the repeating group was also added to NewOrderList and is now officially available.
Order Origination Firm in NewOrderList(35=E)
“Appending tag 20013 to every order in the repeating group” sounds as if the client is not using the Parties component with PartyRole(452)=13 to do the same thing. As they client is obviously supporting repeating groups in general, it is non-compliant to use the user-defined field 20013 instead of the standard Parties component. Hence, the requirement is covered and NewOrderList does accomodate the necessary data element.
Please let me know if you have any further questions.