Imported from previous forum
Is it true that the rules implemented by FIX engines vary by implementator or are there specific standards published by FIX? For example, a validation scheme may assure the presence of required tags and assure the correct format of the tag contents. However, are tag contents validated? Specifically, where a tag calls for specific alpha values, do the validation standards specify that the engine check that only valid values are present?
The reason for the question stems from the recently released NYSE Information Memo #02-59 (Dec. 17, 2002 - see NYSE.com) whereby orders to cover error positions in a member’s error account must be specified as Account Type (Rule80A[47]) “Q”. Currently, “Q” is not a valid value for Tag 47. It seems that it now should be added to the list of valid values. What is the mechanism for this to happen?
[ original email was from Sam Johnson - sam.johnson@transacttools.net ]
gerry -
i’ll leave the policy question to the keepers of the specification, but to address your issue on a more immediate and practical level:
yes it’s true that the amount and type of validations vary widely among engines. although the specification is pretty clear, many vendors leave validations beyond simple required field checking to the business application. and others hard-code these validations. those approaches both have severe limitations.
in ttCONNECT, we have taken an XML-driven approach to defining validations (called a data dictionary) which can then be turned on or off within the engine as necessary. take a look at our online data dictionary browser, which has both standard and NYSE specifications:
http://www.transacttools.net/datadict
you’ll notice that for field Rule80A in the standard FIX version (4.0-3) “Q” is not a valid value, while in the NYSE version (nyse4.1-2) it is. for a NYSE connection, the user would select either nyse4.1 or nyse4.2 and validations would happen as specified in the NYSE memo.
in practice, FIX is extended to support day-to-day business more often than the specification document is published. that’s the reality, and that extensibility is one of the biggest advantages of FIX.
> Is it true that the rules implemented by FIX engines vary by implementator or are there specific standards published by FIX? …do the validation standards specify that the engine check that only valid values are present?
>
[ original email was from Gideon Low - gideon@corefix.com ]
Gerry,
In my experience with both enumerated value (such as “Q” for Rule80A) and custom tag/msg protocol extensions I’ve found that brokers, exchanges, and ECN’s too often underestimate the impact of such changes on their customers.
Many FIX Engine vendors such as CoreFIX provide easy parameter-driven tools for extending FIX utilization beyond the published protocol. However, other FIX Engine products as well as in-house FIX Engines may have more difficulty handling the logic without a larger impact.
Simply allowing a value to pass validation is also only half of the issue since the value needs to be handled in application business logic as well. A good way to make protocol extensions easier for everybody to process is to provide more than one method of implementation. Depending on specific system architecture, it may be much easier for some of your customers to implement a completely new custom tag, place the value into an alternate existing tag, or imbed a value into the comment field.
A FIX Hub service providor that normalizes message usage variations can provide your customers with these alternatives without forcing you to complicate your spec.
The best long term solution, of course, is to work with FPL to include the new value in the next release of the protocol.
Gideon
> Is it true that the rules implemented by FIX engines vary by implementator or are there specific standards published by FIX? For example, a validation scheme may assure the presence of required tags and assure the correct format of the tag contents. However, are tag contents validated? Specifically, where a tag calls for specific alpha values, do the validation standards specify that the engine check that only valid values are present?
>
> The reason for the question stems from the recently released NYSE Information Memo #02-59 (Dec. 17, 2002 - see NYSE.com) whereby orders to cover error positions in a member’s error account must be specified as Account Type (Rule80A[47]) “Q”. Currently, “Q” is not a valid value for Tag 47. It seems that it now should be added to the list of valid values. What is the mechanism for this to happen?
>