Can defined fields be added to a message?

, ,
1

Imported from previous forum

2

Can a defined field (ClientID tag 109) be added
to a defined message (Indication of Interest) or
is this a violation of the Fix Spec?

Is adding a user defined field the correct
approach?

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Can a defined field (ClientID tag 109) be added
> to a defined message (Indication of Interest) or
> is this a violation of the Fix Spec?
>
> Is adding a user defined field the correct
> approach?

It’s hard to say what approach is most correct because they both have distinct advantages and disadvantages.

Any addition of fields to messages beyond the ones stated in their definition is going to require consent by both parties. Such an addition could have several forms:

  1. Adding a field defined in that FIX version, but not for that message type. (What you’re describing.)

  2. Adding a field defined in a later FIX version.

  3. Adding a user-defined field.

Each has distinct issues related to them. The user-defined approach has the most likelihood of not introducing compatibility problems with either party’s engine, since I would imagine any commercial engine’s validator would be smart enough to know that 9000-9999 or 5000-9999 depending on FIX version are user-defined fields.

However, user-defined fields aren’t necessarily the most future-proof. For example, EffectiveTime was defined in FIX 4.1, but not in New Order - Single. FIX 4.2 added EffectiveTime to New Order - Single. If you want to indicate that an order should go live at a particular time in FIX 4.1 or 4.0, use of the EffectiveTime field is the most future-proof, since when migrating to 4.2 or 4.3 that part of your implementation doesn’t change. But it may cause issues with the validation code of some engines. This is why I would hope engine vendors with strong validation allow their users the option of supporting cases #1 and #2.

The use of such a field needs to be considered as well. For example:

  • Addition of a field for informational purposes. This is usually safe, but the biggest risk is that the other party’s engine might see it and consider the message invalid.

  • Addition of a field to support optional business functionality. This is also usually safe; if a client wishes to stick to basic functionality, they can do so, but if they want functionality beyond what that FIX version supports, then some custom coding is going to be required.

  • Addition of a field that you require for normal business functions. This is particularly dangerous. Not every FIX user has an in-house development staff that can customize their FIX implementation to accomodate specific connections. Adding fields and making them required for basic business functions can limit your client base and/or your selection of vendors.