Imported from previous forum
Similar to “User Defined Fields Repository” at
http://fixprotocol.org/specifications/fields/5000-5999
a “User Defined Messages Repository” would be useful. We can know for what purposes custom messages are being used and those messages which are found useful can be added as standard FIX messages to newer versions.
Regards,
K. Mahesh
Customization and the resultant non-uniformity (in my opinion not the opinion of FIX Protocol Ltd.) lessen the value of FIX to the overall FIX community (using economic terminology the non-uniformity creates a negative externality). The flexibility of FIX and the ability of customization are valuable indeed but they come at a cost - I prefer to look at them as a very necessary evil.
Why do people need custom fields and custom messages? Because 1) the lead time in obtaining official tag numbers and new messages takes longer than the time available OR 2) the need identified is not considered a valuable or proper direction for the FIX Protocol (as decided by the GTC) OR 3) they have proprietary extensions that for reasons of privacy or competitive advantage they do not want to standardize or publicize (algorithmic trading tags for instance).
Regarding #1: Under the leadership of Kevin Houston and Matt Simpson as GTC Co-chairs, we put in place the extension pack process and a proposal process that streamlines the time from a request to the issuance of tag numbers and message types. We have a process that we used even this week to issue tag numbers officially to avoid the requirement for user defined fields and enumerations.
The automated specification build process which was created using FPL member funds now automatically creates a repository, FIXimate, and a FIXML Schema for each extension pack. Once we begin publishing extension packs to the website (starting next week) - members will receive the full value of this full process originally conceived by Kevin and Matt back in 2005. So we think we have an approach that addresses issue #1 appropriately.
Regarding #2: I don’t think it is necessarily a good idea for the FIX community as supported by FPL to provide a simple easy solution for publishing custom messages and fields. FPL should instead be focused on encouraging uniform adoption and expanding the standard in a commonly agreed upon way as needed. Providing a simple way to publish custom messages rewards and reinforces divergence not uniformity.
Additional point: Custom messages in order to work an match the standard are identified as U1, U2, … Now everyone that implements a custom message starts at U1. So we probably have 100 different custom U1 messages out there. What benefit does it provide listing 100 U1 messages?
As a result we don’t see the value in providing this inventory on the FPL website.
So from my perspective as a member of the FIX community - I would much prefer to see us use our very limited resources (of the 10,000 or so firms that use FIX only 197 have seen fit to support the FIX Protocol) on improving the uniform use of FIX than to take members’ money to facilitate divergence and customization (Again I want to reiterate - this is my opinion and not the opinion of FIX Protocol Ltd.).
Similar to “User Defined Fields Repository” at
http://fixprotocol.org/specifications/fields/5000-5999
a “User Defined Messages Repository” would be useful. We can know
for what purposes custom messages are being used and those messages
which are found useful can be added as standard FIX messages to
newer versions.Regards,
K. Mahesh
[ original email was from Ryan Pierce (FPL Technical Director) - ryan.pierce@fixprotocol.org ]
I agree strongly with Jim on this issue.
FPL does not have unlimited funding and resources. Quite the contrary, given that only 197 firms out of the thousands that use FIX are financially supporting the development of the protocol, it is clear that we have to weigh the cost vs. the benefit of new initiatives carefully.
Adding the functionality that you suggest is something that would have a fairly significant cost. We can’t just click a few links, type in a few column names, and have a custom message catalog database implemented. We would have to pay web and database developers familiar with this site’s custom architecture to make these changes, and FPL resources would be needed to QA the resulting code and manage its deployment.
I can think of plenty of better uses for FPL membership dollars.
Even if this could be done for free, Jim’s concerns still stand. I want to encourage standardization, not promote fragmentation.
#1 : I fully agree that custom messages / tags / values are a necessary evil. Users of custom messages / tags / values are fully aware that extra custom coding is required because off the shelf FIX engines would not process them and usually this extra code would lead to a loss of performance. But they do this because the functionality they need is not provided by standard FIX messages / tags / values.
#2 : I do not think “Providing a simple way to publish custom messages rewards and reinforces divergence not uniformity.” Whether there is a place in http://fixprotocol.org/ to publish a custom message or not, those who want / need to use custom messages would do so since the protocol permits it.
Since there is already a repository for custom tags, I thought a repository for custom messages would serve a similar purpose.
#3.1 : There may be many U1 custom messages each having different purpose and structure. By studying the structure and fields of User defined messages published, we can gain insight into the gap between standard FIX messages and the needs of electronic trading community which would help in further development of the protocol.
#3.2 : Users who create custom messages to keep their systems proprietary would not publish their custom messages in the repository
#3.3 : In the user defined fields repository, I see many fields having only description “Reserved” example 5187, 5239, 5241-5248, 5268 etc, what use does this serve?
I fully agree its not free and we have to weigh the cost vs. the benefit of new initiatives carefully.
I do not believe that a repository of user defined messages would be beneficial to the standard. People always choose the path of least resistance. Why should I try to convince FPL committees of the usefulness of a message if I can simply post it to the public without such approval? I would not blame people for doing this as it is human nature but FPL should not create the means to do it.
I have similar concerns with the user defined fields even if the level of granularity is very different and one can quite easily answer the question “Is this field useful for me?”. In case of a user-defined message, the answer is almost always going to be “Yes, maybe, but I would also need a few more (standard) fields in it”. It gets really nasty when people re-define standard messages in their own flavor as user-defined messages. People would do that whenever they do not like the underlying transaction, state or identification models of FIX.
Not all fields are of equal importance. That is where my concerns about user-defined fields comes from. A single standard field like ExecType (150) or OrdStatus (39) conveys an entire state model. Adding user-defined fields can distort the intended semantics of a message. User-defined fields that convey additional attributes of an entity are not the problem as they have no impact on other fields or on the message flow. For example, adding a user-defined field expressing the quantity to be canceled to the OrderCancel message is technically no different than any other user-defined field. However, it suddenly allows partial cancelations of an order which was supported in the early days of FIX but then discarded. Mis-use is just too easy, already on a field level.
It only gets worse on the message level as you can then circumvent mandatory fields which FPL might have deemed key for a given message. You can just redefine NewOrderSingle and call it OrderEntry.
The whole idea of the FPL community is to come together in working groups and committees to discuss, among other things, gaps in the current spec and how best to close them. This is the only way that new messages, fields or enum values make it into the spec. Many user-defined fields are by now obsolete, yet the owners do not come forward to have them removed from the website. They have long solved their problem. Other have come forward with proposals that happen to cover some of the user-defined fields.
Let’s be realistic, user-defined messages would not be added to the standard other than by the owner himself. The process for that is well established, i.e. participate in a working group or committee, write a gap analysis, have it posted, discussed, modified and finally approved by the GTC. Compared to SWIFT the process is very lean. People making a living with FIX should also support FIX by being a member and donating time and effort through participation. It takes more time than the design of a proprietary message but that is a price to pay for a standard that automatically benefits many.
There is enough mis-use of standard FIX messages and fields out there. I lean more towards not posting user-defined fields than towards also posting user-defined messages. The concepts as such make sense and should be kept. I doubt the actual degree of re-use beyond the submitter. Some fields are merely placeholders and serve no purpose for others.
Anyway, that’s my opinion, but I believe the purpose of this thread was to collect views on this subject.
Regards,
Hanno.
Similar to “User Defined Fields Repository” at
http://fixprotocol.org/specifications/fields/5000-5999
a “User Defined Messages Repository” would be useful. We can know
for what purposes custom messages are being used and those messages
which are found useful can be added as standard FIX messages to
newer versions.Regards,
K. Mahesh