A Question of Style

, ,
1

Imported from previous forum

2

[ original email was from Newton White - ]
Suppose that I want to implement the broker side of a FIX based system, but for various reasons I do not wish to support the full set of features included in the Version 4.0 documentation. For purposes of discussion, suppose that I want to bounce orders that seek settlement any way other than regular way or when issued (i.e., I want to restrict the normal range of values for tag 63, SettlmntType, to "0=Regular" and "7=When Issued").

Would it be morally superior to:

  1. Agree with all counterparties that if they specify tag 63 in an order, they will use a subset of the normally valid values (with the understanding that if they enter some other value, even though the standard says it is valid, I will bounce their order)
  2. Agree with all counterparties that they will never specify tag 63 in any order and create a new User Defined Field (5000 <= tag number <= 9999) for which the range of legal values are limited to "regular way" and "when issued"
  3. Define a new message type which begins with the letter U and a new tag as discussed above, on the theory that it would be immoral to use the message tag for "New Order - Single" if I were going to reject an input that is defined as valid in the specification. This solution would also involve bouncing all messages for which the messag type is New Order - Single.
  4. The following obviously superior approach:_______

Thanks for your thoughts.

3

[ original email was from Scott Atwell - ]
I (and imagine most others) would vote for #1. The protocol has been designed to be flexible and support the various business needs. Fields which have a specific list of valid values should not (and still comply with the spec) specify values not in the valid list, however, that doesn’t mean one has to support all valid values if some of them are not applicable from a business perspective. The purpose of the
protocol is to support the business needs. Agreement upon the business issues is/should be done outside of the FIX spec. Your example is really not any different than a buyside only paying attention to specific fields in an IOI. In order to comply with the spec, the buyside FIX system should accept an IOI with any field in the specification, however, the buyside’s FIX system may ignore those which it doesn’t care about. Adding user defined fields or new enumerations should really only be done if “new” requirements will be met and in practice is often very difficult to arrange with all counterparties.

4

Im new to fix and business terms. can anybody tell me what is the difference between IOI and a QUOTE ?

thanks,
Srinivas