The latest version of MiFID II/R Implementation Guidelines for Inter-Firm Data Communication for Transaction Reporting recommends that client fills be distinguished from informational NOEs based upon the presence or absence of the transaction reporting venue (TRV). This is critical for buy-sides if they are to mirror the broker’s transaction reports one for one.
However, many banks have interpreted this as saying that the “last” fill for an execution should also contain the TRV because the fact that it is the last fill makes the Market Execution of which it is part publishable. This interpretation means that the last fill will always contain the TRV irrespective of whether that fill is itself reportable.
There are some workarounds to this. If the broker’s capacity is MTCH, then the fill is reportable. It is possible that an agreement is in place that all fills from a give broker are or are not reportable. Failing that, the other workaround I know of is to make the assumption that all the fills for a given execution either are or are not reportable, so the reportability of the last fill will be the same as that of its predecessors.
This last workaround is far from ideal. Not only is it based upon an assumption, it also means that the reportability of a fill cannot be determined from the contents of that fill message. Does anyone have a better solution to this? Are the MiFID Transaction & Trade Reporting Working Group working on a recommended solution to this?
Have you seen PUBLIC COMMENT PERIOD – MiFID II/MiFIR Extensions Part 4 Proposal? I am not sure whether this fully addresses your question. The MiFID II/MiFIR Extensions Part 4 Proposal (https://www.fixtrading.org/packages/fix-protocol-ga-mifid-ii-mifir-extensions-part-4/) includes a new mechanism to explicitly identify reportable quantities and prices. This can become part of the guidelines as soon as it has been fully approved and implemented in the FIX Repository. I agree that the presence or absence of the TRV is an implicit approach and not ideal.
Note that the explicit approach (if used) requires to “roll-up” unreported quantities and hence requires the last fill of an order to contain the new fields in order to have the last fill included in the report. The NOE is a different way of looking at the same thing, i.e. reporting in a lesser granularity than providing FIX ExecutionReports to the client. It is not about reporting a lesser overall quantity, i.e. all LastQty values must add up to same total as all ReportingQty values which are sent less frequently.
Are you referring to business requirement 4 “Reportable Quantity and Price”. Is the intention that these new fields will only be present on fills that are reportable? Presumably, as with the TRV, it will always be present on the last fill, so as with the TRV, their presence of absence cannot be used to determine the reportability of the fill. I guess we can compare the Reportable Quantity and the Filled Quantity but I’m not sure how safe that is.
What worries me is that this seems to rely on the fact that all the fills within an execution are all reportable, or none of them are, and I see no guarantee of that. The addition of a simple "Transaction Reporting Status field would be some much simpler.
Yes, it is #4 in table 1 (Reportable Quantity and Price) and explained in detail in section 4.1 “ExecutionReport(35=8)
Order-level Reporting”. And no, it is not the intention that these new fields will only be present on fills that are reportable. A simple status field as you suggest would suffice for that.
The intended usage of the new fields is to indicate reportability, i.e. presence is to interpreted by the receiver as being reportable (by sender or receiver). It is intentional that the new fields stand for themselves, i.e. you do not have to determine reportability by comparing reporting and filled quantity as you describe. In fact, you have to ignore filled quantity and use only the reporting quantity. The proposal foresees out-of-band bilateral agreement whether the new paradigm is actually used. Otherwise you would not know what to do with the first ExecutionReport if it does not contain the new fields. There is no order level indicator field for the chosen reporting model as it has not been defined as a business requirement by the FIX regulatory subgroup. You can use OrderAttributeType(2594) with a user-defined value if you want an in-band indicator per order.
I am interested in the your use case that not all fills within an execution are reportable. Can you elaborate on the conditions for such a use case where a single order is executed multiple times but only some of the executed quantity needs to be reported? Do you maybe have a reference to an ESMA document or RTS where such a scenario is described? The current assumption is that the total of ReportingQty(2751) must be equal to CumQty(14) at the end of the lifetime of an order. I would even say that this should be the case everytime both fields are present. When populating ReportingQty it does not make sense to include less than the previously executed but not yet reported quantity.