mistrade indication through FIX4.4 MarketDataSnapshotFullRefresh

, ,
1

Imported from previous forum

2

Hi,

I have a question regarding mistrades and how they can be reported via the message FIX4.4 MarketDataSnapshotFullRefresh.

In the user defined fields repository I have found the field 6567 which can be used for this:
http://www.fixprotocol.org/specifications/fields/6567-6567

Browsing further through the FIX5.0 fields I also discovered the field 828 (TrdType) which can take the value 24=ErrorTrade and can be used on the MarketDataSnapshotFullRefresh message, but only for FIX5.0.

Is there a general recommendation whether one should use user-defined fields over fields from newer FIX versions? And is 828 the correct field for my intended purpose?

Many thanks in advance for any hints.
Best regards,
Christoph John

3

Christoph,

ini general the recommendation is use elements from higher versions before going to user-defined fields (UDFs). This eases later migration to higher versions. However, this option is not always possible if it is about fields from higher versions. Messages can be used by prefixing the standard FIX MsgType with “U”. Valid values might not be checked by the FIX engine and left entirely up to the application level. However, fields are typically checked and then UDFs might be the only solution.
You asked about mistrades in 4.4. This depends somewhat on the way you send them, i.e. do you just send instrument, qty and price or also an entity identifier for the trade? With the former you can send a negative qty to ensure it all adds up again. When sending trade entities, you need to send the same entity again and mark it as a mistrade that has been reversed. You should do this with TradeCondition (277) = 0 = Cancel even though this value did not exist in FIX 4.4. TrdType (828) = 24 is related specifically to MiFID and would thus only be my second choice. The valid value problem is the same as you already noted.
Regards,
Hanno.

Hi,

I have a question regarding mistrades and how they can be reported via the message FIX4.4 MarketDataSnapshotFullRefresh.

In the user defined fields repository I have found the field 6567 which can be used for this:
http://www.fixprotocol.org/specifications/fields/6567-6567

Browsing further through the FIX5.0 fields I also discovered the field 828 (TrdType) which can take the value 24=ErrorTrade and can be used on the MarketDataSnapshotFullRefresh message, but only for FIX5.0.

Is there a general recommendation whether one should use user-defined fields over fields from newer FIX versions? And is 828 the correct field for my intended purpose?

Many thanks in advance for any hints.
Best regards,
Christoph John

4

Dear Hanno,

thank you for your reply. Since we are not sending any identifier for the trade, the negative qty might be a good option.

Best regards,
Christoph

Christoph,

ini general the recommendation is use elements from higher versions before going to user-defined fields (UDFs). This eases later migration to higher versions. However, this option is not always possible if it is about fields from higher versions. Messages can be used by prefixing the standard FIX MsgType with “U”. Valid values might not be checked by the FIX engine and left entirely up to the application level. However, fields are typically checked and then UDFs might be the only solution.
You asked about mistrades in 4.4. This depends somewhat on the way you send them, i.e. do you just send instrument, qty and price or also an entity identifier for the trade? With the former you can send a negative qty to ensure it all adds up again. When sending trade entities, you need to send the same entity again and mark it as a mistrade that has been reversed. You should do this with TradeCondition (277) = 0 = Cancel even though this value did not exist in FIX 4.4. TrdType (828) = 24 is related specifically to MiFID and would thus only be my second choice. The valid value problem is the same as you already noted.
Regards,
Hanno.

Hi,

I have a question regarding mistrades and how they can be reported via the message FIX4.4 MarketDataSnapshotFullRefresh.

In the user defined fields repository I have found the field 6567 which can be used for this:
http://www.fixprotocol.org/specifications/fields/6567-6567

Browsing further through the FIX5.0 fields I also discovered the field 828 (TrdType) which can take the value 24=ErrorTrade and can be used on the MarketDataSnapshotFullRefresh message, but only for FIX5.0.

Is there a general recommendation whether one should use user-defined fields over fields from newer FIX versions? And is 828 the correct field for my intended purpose?

Many thanks in advance for any hints.
Best regards,
Christoph John

5

Hello Hanno,

We are interested in that behavior, by using tag 277, to cancel and modify trades. I got the picture for cancelations, but I’m not sure about the specific value to use if we want to send a trade correction/modifcation. Could you help me?

Thanks

Christoph,

ini general the recommendation is use elements from higher versions before going to user-defined fields (UDFs). This eases later migration to higher versions. However, this option is not always possible if it is about fields from higher versions. Messages can be used by prefixing the standard FIX MsgType with “U”. Valid values might not be checked by the FIX engine and left entirely up to the application level. However, fields are typically checked and then UDFs might be the only solution.
You asked about mistrades in 4.4. This depends somewhat on the way you send them, i.e. do you just send instrument, qty and price or also an entity identifier for the trade? With the former you can send a negative qty to ensure it all adds up again. When sending trade entities, you need to send the same entity again and mark it as a mistrade that has been reversed. You should do this with TradeCondition (277) = 0 = Cancel even though this value did not exist in FIX 4.4. TrdType (828) = 24 is related specifically to MiFID and would thus only be my second choice. The valid value problem is the same as you already noted.
Regards,
Hanno.

Hi,

I have a question regarding mistrades and how they can be reported via the message FIX4.4 MarketDataSnapshotFullRefresh.

In the user defined fields repository I have found the field 6567 which can be used for this:
http://www.fixprotocol.org/specifications/fields/6567-6567

Browsing further through the FIX5.0 fields I also discovered the field 828 (TrdType) which can take the value 24=ErrorTrade and can be used on the MarketDataSnapshotFullRefresh message, but only for FIX5.0.

Is there a general recommendation whether one should use user-defined fields over fields from newer FIX versions? And is 828 the correct field for my intended purpose?

Many thanks in advance for any hints.
Best regards,
Christoph John

6

Javier,
I assume you are still talking about public data, not private trade information sent directly to the counterparties of the trade. If you need the complete transactional capabilities for trades (add, modify, delete) then it is better to use the MDIncrementalRefresh message to convey trades. There you have MDUpdateAction which covers what you need. If you need to use MDSnapshotFullRefresh then you can implement a modify by sending a cancel (277=0) followed by another trade. 277 is not intended for transactional semantics, it merely qualifies the trade in more detail.
Regards,
Hanno.

Hello Hanno,

We are interested in that behavior, by using tag 277, to cancel and modify trades. I got the picture for cancelations, but I’m not sure about the specific value to use if we want to send a trade correction/modifcation. Could you help me?

Thanks

7

Hanno,

Ok, that make sense, thanks a lot.

Regards

Javier,
I assume you are still talking about public data, not private trade information sent directly to the counterparties of the trade. If you need the complete transactional capabilities for trades (add, modify, delete) then it is better to use the MDIncrementalRefresh message to convey trades. There you have MDUpdateAction which covers what you need. If you need to use MDSnapshotFullRefresh then you can implement a modify by sending a cancel (277=0) followed by another trade. 277 is not intended for transactional semantics, it merely qualifies the trade in more detail.
Regards,
Hanno.

Hello Hanno,

We are interested in that behavior, by using tag 277, to cancel and modify trades. I got the picture for cancelations, but I’m not sure about the specific value to use if we want to send a trade correction/modifcation. Could you help me?

Thanks