I had a look at FIX-CAT specifications (EP253). Here are some comments.
New values were added to RegulatoryReportType (1934) to identify CAT events: 1934=22 (order), 1934=23 (child order), 1934=24 (order route), 1934=25 (trade), 1934=26 (quote). However this tag is only available for TradeCaptureReports. Is it an error? Why do we need to identify an order acknowledgment in a TCR message, for example?
For unsolicited quotes, it is suggested to use the tag 377 (SolicitedFlag). I expected to use UnsolicitedIndicator (325). Why SolicitedFlag is more appropriate?
New tags 1725 (OriginatingDeptID) and 1726 (ReceivingDeptID) were created. Since FIX.4.3, the practice is to use PartyID to identify parties. Also there are already PartyRole=order-origination-firm and PartyRole=order-origination-trader. It would be consistent to have PartyRole=order-origination-department instead of a new flat tag.
Concerning the tag 2422 (OrderRequestID), I think its name is confusing. I would name it OrderMsgID to be consistent with QuoteMsgID (1166) - If I’m not wrong, both tags have the same purpose.
That is unfortunately an error, thank you for pointing this out and apologies for the omission. RegulatoryReportType(1934) has been used for all messages conveying CAT events. The mapping (https://www.fixtrading.org/packages/mapping-cat-fix-phase-2a_equities/) did not identify this as a gap in messages other than the TCR. The GTC will need to issue another Gap Analysis to fix this. The field should have been added to the following messages:
NewOrderSingle(35=D), CAT events MECOR and MEOR
ExecutionReport(35=8), CAT events MENO(S), MEOA, MEOM(S), MEOJ, MECOM, MECOC, MEIR
The information was only required in the Quote(35=S) message which already has the field SolicitedFlag(377) and could hence be re-used for CAT. It conveys whether orders or quotes were requested. UnsolicitedIndicator(325) is more appropriate to flag whether reports were triggered by a request or not.
These tags are not new. These FIX fields have been introduced specifically for OATS at the time (OATS for NMS Stocks, June 2011, https://www.fixtrading.org/packages/ep135/). CAT has heavily drawn upon OATS. The first choice are always existing fields/values. Another advantage of 1725/1726 is that these are not part of a repeating group. There are still many FIX 4.2 users out there that have not implemented support for repeating groups like Parties and are then expecting UDFs in the 8000-8499 range.
OrderRequestID(2422) was introduced with EP188 (https://www.fixtrading.org/packages/ep188/) to optimise FIX for high performance applications. Orders always had a message identifier, i.e. ClOrdID(11), that is also an entity identifier. The objective was to separate the two purposes by introducing a new field as an explicit message level identifier.
Quote entity and message level identifiers are unfortunately not very consistent. There is a QuoteReqID(131) specifically for quote requests. Single and mass quotes both had QuoteID(117) as identifier for both entity and message. QuoteMsgID(1166) was then added as a pure message level identifier (except for mass quotes). The name needed to be different from the existing QuoteReqID(131).
Newer request messages all include a tag XXXRequestID to express not only the message level nature (instead of entity) but also to express that it is a request and not a response or a report. The name for the orders was hence not aligned with quotes but with other request messages. Note that it is aligned with QuoteRequest(35=R) and its QuoteReqID(131) field but that was not part of the consideration I believe.
Hope it helps to understand the choices that were made a little bit better.
Thank you for the additional details. It makes sense now.
Concerning the spreadsheet: to identify MEOJ events, I’m not sure “absence of OrdType” is a valid criterion if it means “OrdType didn’t change” since all fields have to be specified even if they didn’t change.
MEOJ = Used to report simple order modifications including changes to the price or quantity of the
order.