Duplicate FIX Field Names -Different Tag values

, ,
1

Imported from previous forum

2

Hi All,

One of our client’s spec uses FIX 4.3 and they used Custom tag 5227 – FutSettDate2 for Market Data Request(Pre Trade) instead of using already existing tag 193 (available in New Order Single) which is also FutSettDate2. Currently we use a FIX testing tool which does not allow duplicate field names.

It looks like FTC supports duplication of Field Names. Is it standard practice? How should we be handling such situations?

http://fixprotocol.org/specifications/fields/5000-5999 - Look for 5227

http://fixprotocol.org/FIXimate3.0/?language=en&version=FIX.4.3 – look for 193

Thanks,
Jayaram

3

Field names should not be on the wire for tag=value syntax, i.e. only duplicate tag IDs should be a problem. This does not seem to be the case here.

The actual message should not use two different tags that have the same semantic, i.e. either 193 or 5227 should be defined in the Rules of Engagement as being part of the message. You do not clearly state whether 193 is actually used or if it is only part of the standard MarketDataRequest but not used in the given interface implementation.

There are a few duplicate names in the user-defined fields for cases where a lower version of FIX does not support the standard tag defined in a higher version. It is recommended to use the standard tag from the higher version (if you can) to avoid having all standard tags defined a second time as user-defined tags. Semantic duplicates have not (yet) been removed.

Hi All,

One of our client’s spec uses FIX 4.3 and they used Custom tag 5227 –
FutSettDate2 for Market Data Request(Pre Trade) instead of using already
existing tag 193 (available in New Order Single) which is also
FutSettDate2. Currently we use a FIX testing tool which does not allow
duplicate field names.

It looks like FTC supports duplication of Field Names. Is it standard
practice? How should we be handling such situations?

http://fixprotocol.org/specifications/fields/5000-5999 - Look for 5227

http://fixprotocol.org/FIXimate3.0/?language=en&version=FIX.4.3 –
look for 193

Thanks, Jayaram

4

Hi Hanno,

     I understand what you are trying to get to, actually 193 is not available in Standard MarketDataRequest(V), It's available in New Order Single(D), but the purpose of both the tags is the same .Client uses FIX 4.3, So why use custom tag instead of Standard tag.

     Another good example is , client has used Custom Currency tag 5232 in Market Data Request , although as we all know there is standard currency tag 15 which is available in New Order Single and other messages. So is it against the protocol to use tag 15 in Market Data Request for the same purpose. 

     Correct me if I am wrong, Can all Standard Fields(as listed in speciofic FIX version) be used in any message type where they fit in appropriately or is it against the Protocol to use a field/tag from a message type which has support for it and use that in a Message Type which does not have support for it although the purpose of the tag in both the messages is the same.

    Hope it's clear what I am trying to get to.

Thanks,
Jayaram

Field names should not be on the wire for tag=value syntax, i.e. only
duplicate tag IDs should be a problem. This does not seem to be the
case here.

The actual message should not use two different tags that have the same
semantic, i.e. either 193 or 5227 should be defined in the Rules of
Engagement as being part of the message. You do not clearly state
whether 193 is actually used or if it is only part of the standard
MarketDataRequest but not used in the given interface implementation.

There are a few duplicate names in the user-defined fields for cases
where a lower version of FIX does not support the standard tag defined
in a higher version. It is recommended to use the standard tag from the
higher version (if you can) to avoid having all standard tags defined a
second time as user-defined tags. Semantic duplicates have not (yet)
been removed.

Hi All,

One of our client’s spec uses FIX 4.3 and they used Custom tag 5227 –
FutSettDate2 for Market Data Request(Pre Trade) instead of using
already existing tag 193 (available in New Order Single) which is also
FutSettDate2. Currently we use a FIX testing tool which does not allow
duplicate field names.

It looks like FTC supports duplication of Field Names. Is it standard
practice? How should we be handling such situations?

http://fixprotocol.org/specifications/fields/5000-5999 - Look for 5227

http://fixprotocol.org/FIXimate3.0/?language=en&version=FIX.4.3 –
look for 193

Thanks, Jayaram

5

Jayaram,

I now see what the main point is. The answer is no, you cannot use standard FIX tags in messages where they have not been defined in. The exception to the rule is when they have been defined in a higher version than you are using. Formally, this is not permitted just the same and standard FIX engines will reject such messages.

Standard FIX tags are in the messages for a purpose and if they are not, then it is either intentional or there has been no business requirement for it so far. The standard process is to submit a proposal to FIX to add a standard tag to a message.

Currency is a good example. It is outside of the Instrument block, i.e. semantically not part of the identifying information for an instrument. If someone now uses a custom tag for currency in the Market Data Request for the purpose of uniquely identifying an instrument, he is violating the FIX standard even though he is using a custom tag. In the case of currency there is no problem because tag 15 was added to the standard Market Data Request in a later version, i.e. it is ok to be in there. If the FIX engine is strict and does not allow standard tags to pass that are not part of the message in the given version, then the usage of a custom field is a workaround as these are not checked by the FIX engine and just passed through to the application layer.

So, in summary, if the FIX engine and counterparty application permits, always use standard tags as long as they are part of the current or a higher FIX version. If that is not the case, submit a gap analysis to a FIX working group or committee and justify why you think the standard tag should be part of the message.

Custom tags are always only second best and can be detrimental to the standardization that FIX Protocol wants to provide to the industry. A good example here is to add a custom tag for the quantity to be deleted in an OrderCancelRequest. The FIX standard defines a cancel request to always apply to the entire order, OrderCancelReplaceRequest is to increase or decrease the quantity. The custom tag allows to circumvent the standard but that does make your application talk true FIX. Your counterparties will suffer if you use custom tags to deviate from the concepts and semantics of the FIX standard as defined in the spec.

There are grey areas where the concepts of legacy systems just cannot fully support the FIX concepts but the aim must always be to do so.

Regards,
Hanno.

Hi Hanno,

     I understand what you are trying to get to, actually 193 is not
     available in Standard MarketDataRequest(V), It's available in
     New Order Single(D), but the purpose of both the tags is the
     same .Client uses FIX 4.3, So why use custom tag instead of
     Standard tag.

     Another good example is , client has used Custom Currency tag
     5232 in Market Data Request , although as we all know there is
     standard currency tag 15 which is available in New Order Single
     and other messages. So is it against the protocol to use tag 15
     in Market Data Request for the same purpose.

     Correct me if I am wrong, Can all Standard Fields(as listed
     in speciofic FIX version) be used in any message type where
     they fit in appropriately or is it against the Protocol to
     use a field/tag from a message type which has support for it
     and use that in a Message Type which does not have support
     for it although the purpose of the tag in both the messages
     is the same.

    Hope it's clear what I am trying to get to.

Thanks, Jayaram