CAT FIX specification clarification request.

Hi,
We have recently started our analysis and implementation of the new CAT tags as shown by EP 253 and its accompanying PDF outlining the changes.
However, there are a few points we would like to clarify.

  1. Why use 770=32 instead of 770=1 in the Trade Cancel Execution Report message? (150=H)
    Can we have 770=32 in messages that are not 150=H or 856=6?

  2. The OrderAggregationGrp component is indicated as being included in the ExecutionReport (35=8) in the FIX CAT specs.
    However, when we look at the latest EP, we only see it as being in the TradeAggregationRequest (35=DW). Which is the correct interpretation of this change?

  3. When we have 1081=9, what is the source of the identifier? OrderID?
    How do we know what type of identifier this should be.

Hi Daniel,

thank you for your analysis. I hope I can clarify your questions as follows:

  1. TrdRegTimestampType(770)=32 (Trade cancellation time) explicitly refers to the cancellation of an execution or trade. It maps to the CAT field cancelTimestamp in the MEOT event (Trade). 770=1 (Execution time) is intended for the actual execution and not for its later cancellation.
    What would be the use case for 770=32 if it is not a cancellation of an execution or trade?
    Please also see https://www.fixtrading.org/recommended-practicesguidelines for the detailed CAT/FIX mapping.

  2. EP253 had a design error (duplicate fields in tagvalue syntax) that was rescinded with a new Gap Analysis that has just been put out for public review (PUBLIC COMMENT PERIOD - Related Orders Proposal). Tag numbers will change, the extension will be the same.

  3. RefOrderIDSource(1081)=9 (parent order identifier) refers to whatever ID the parent order has. It maps to the CAT field parentOrderID in the MEIR (internal route) and MECO (child order) event. I would recommend to use the system assigned order identifier, i.e. OrderID(37) as source.

Regards,
Hanno.

I see, thanks a lot for the info @hanno.klein !
Will check out linked documents and share with my team :slight_smile:

Hi @hanno.klein, I have an extra question concerning subject 22 in the FIX/CAT gap analysis.
I see you mention using ExecID(17) as an increasing sequence number in 35=8 (executionReport).
Is this accurate? or did you mean to say 2422, as implied in the message tables on page 23 of the document?

@danielitiviti ExecID(17) is the right one for ExecutionReport(35=8), OrderRequestID(2422) only applies to requests and not all ExecutionReport(35=8) messages are in response to a request by the owner of the order.

I do not understand “as implied in the message tables on page 23 of the document”. Page 23 of the ASBUILT PDF document shows QuoteStatusReport(35=AI). Did you mean page 20/21 which shows ExecutionReport(35=8) and in that table the field OrderRequestID(2422)? The message tables do not show the fields relevant for CAT. They show what is needed to define the positioning of new fields in that message (e.g. for display in FIXimate). Only the column “Mapping and usage comments” is specific to CAT.

@hanno.klein Hi, could it be we are not on the same version of said document?
We are using version v0.5 from the 29th of November 2019. Is there a more recent version?
(This is the version that is bundled with EP253)

@danielitiviti The published ASBUILT PDF on https://www.fixtrading.org/packages/ep253-extensions-for-cat-fix-mapping/ has October 10, 2019 v0.5 on the title page. The history has Nov 29, 2019 as latest change date. I did look into a prior version from Nov 27, apologies. Page 23 is correct for the ExecutionReport layout.

Hi Hanno,

Is it planned to add [TrdRegTimestamps] to quotes and quote status reports as suggested by the separate spreadsheet of EP253?

Thank you,
Xavier.

@xavierbruyet thanks for catching that. It was intended and missed in the Gap Analysis for EP253. Have you found any more omissions? The mapping sheet was the basis for the Gap Analysis and should have been completely covered. Apologies for the errors!

I’ve reviewed the last tags we still need to implement. It seems that [QuoteAttributeGrp] is also missing in QuoteStatusReport.

You are right, it is only referred to in the comment column of the mapping. It is not properly identified as a gap in column M and was missed. Will also be added to a new Gap Analysis like the missing TrdRegTimestamp component. Thanks!

Hi Hanno,

I’m reviewing the tabs of each message type in the spreadsheet now and I’ve found more omissions. As instance:

  • 2524 (TradeReportingIndicator) is needed in new orders and trade capture reports,
  • 2525 (AffiliateFirmsTradeIndicator) is needed in new orders and execution reports,
  • 1028 (ManualOrderIndicator) is needed in trade capture reports.

For now, I’ve only reviewed tags suggested for new orders. I will review other tabs in the next two weeks. If you confirm they are omissions, maybe you can change the EP draft for RegulatoryReportType to an EP which includes all corrections for CAT.

Regards,
Xavier.

Thanks a lot for doing this analysis @xavierbruyet! The column “Gap” in the mapping spreadsheet is the issue here. I guess that due to cut&paste of rows between tabs, it was forgotten to check whether the setting of “Gap” is correct for the individual tab (=FIX message type).

It will probably have to be a new Gap Analysis due to the narrow focus of the one for RegulatoryReportType. The name of the Gap Analysis should not be changed. We will need a generic name and also need to update the mapping sheet (https://www.fixtrading.org/packages/mapping-cat-fix-phase-2a_equities/) to set “Gap” = “Y” for all of the omissions.

Regards,
Hanno.

Hi Hanno,

We are done with our implementation. Here are the additional discrepancies we found.

  • Tag 1033 (DeskType) is missing the value “FB”.
  • Tag 19 (ExecRefID) is suggested for TCR messages but not present.
  • Repeating group 2668/2669 (TrdRegPublicationGrp) is required in single orders.

We also found these two errors in the spreadsheet:

  • In tab “FIX TradeCaptureReport”, on lines 51 and 57 (eventTimestamp), it should probably be “Y = Manual” (instead of “N”).
  • For tag 2830 (EventInitiatorType), FIX values are “C” and “F” instead of “0” and “1”.

Regards,
Xavier.

1 Like

@xavierbruyet thanks a lot for that analysis and summary! FIX also thrives due to the effort of its volunteers. I see the quality of the standard as a joint responsibility. The GTC will take care of the corrections, including the mapping table. Apologies again for any inconvenience the errors may have caused.

Hey,
Sorry to bump this old thread, but could you please tell me which file I should look at that outlines the changes between the excel spreadsheet you shared above and whatever FIX supports in terms of CAT right now (with the extra time you have had to flesh out the specs and the new EPs related to CAT to fix the known issues).
Thanks!

@danielitiviti, we are about to release the next batch of EPs from EP259 - EP264 which will include the various corrections for CAT:

EP259 Related Orders (Support for order aggregation on execution reports)
EP261 RegulatoryReportType Extension (Additional support for CAT (Consolidated Audit Trail) event types)
EP263 Regulatory Timestamps for Quotes (Support for repeating group of timestamps in quote messages)
EP264 CAT/FIX Mapping Phase 2 – Update (Additional support for data reporting required by CAT)

This include the correction of RefOrderIDSource(1081) = 10 (Manual order identifier). The datatype of the field is char, i.e. the value will change from 10 to A.

The updated mapping table will be posted together with the batch of EPs, updated FIXimate and repositories (unified and Orchestra), probably early next week. Apologies for the delay in publishing the changes/corrections.

Thanks for the quick reply, looking forward to it.
Will the updated mapping table clearly outline the changes from the previous version? or will you have a separate changelog somewhere?
That would be really appreciated so I don’t have to double check everything myself :slight_smile:

The mapping sheet has a change log that details all changes made. Additionally, cells in the layout sheets that were subject to change compared to the previous version are colored in blue.

Awesome :grin:
Thanks again for all the work you put into this !