[This message was posted by Hanno Klein of Deutsche Börse Systems <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/dd216b74 - PLEASE DO NOT REPLY BY MAIL.]
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 [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
