Re: Book Management
Ryan Pierce / CME Group
2 Sep 2010 10:53AM ET
> [I thought that the protocol allowed for adding user defined enums to a standard enum field - I will need to research this more.]
I think of this in three categories:
1. Fields where the FIX Protocol explicitly states that they can be extended. Doing so is fully compliant. Two sub-cateogries:
1A. Integer fields that are represented in the Repository with a union datatype. E.g. OrdRejReason(103) has the union datatype Reserved100Plus, which means users can, with bilateral agreement, add enums starting at 100. The data dictionary in Volume 6 of the spec shows this by appending the text: "or any value conforming to the data type Reserved100Plus" at the end of the list of enums. Unfortunately, I don't think FIXimate 3.0 on the website shows this.
1B. String fields that spell out in their descriptions how they should be extended. E.g. SecurityIDSource(22) is a String; it says in its description: "100+ are reserved for private security identifications". And MsgType(35) says: "Note: A "U" as the first character in the MsgType field (i.e. U, U2, etc) indicates that the message format is privately defined between the sender and receiver."
2. Taking standard enums from later versions and pulling them into a previous version. This is usually considered an acceptable practice when there is a need, and when doing so isn't duplicating existing functionality. E.g. ExecInst = f (Intermarket Sweep) was added to support Reg NMS in the US and was intended to support similar functions in other markets as requirements emerge (e.g. DAO orders in Canada.) I see nothing wrong with using ExecInst=f in FIX 4.2, even though it technically isn't part of 4.2. But this doesn't apply when functionality does exist. E.g. FIX 4.2 uses ExecType = 1 (Partial Fill) and 2 (Fill). FIX 4.4 uses ExecType = F (Trade). I would consider use of ExecType=F in FIX 4.2 a mistake.
3. Firms add their own enums to standard FIX fields that don't support user extensions all the time. This isn't compliant. But it happens anyway. Two things to consider:
* Counterparty impact. Generally, adding new data (e.g. a new MDEntryType) has less impact than adding new state (e.g. a new OrdStatus/ExecType.)
* The value you choose may be unique now, but may cease being unique in the future. If a field has 0-9, A-Z, and a-c assigned today, taking d isn't a good idea, because that's the next value FPL will likely assign. Taking z, y, and x doesn't guarantee uniqueness, but it is less likely to result in a collision for some time.
