|
ECNs, Exchanges
< Previous Next >
Re: Book Management
Colin Cullen / ICAP <>
2 Sep 2010 12:35PM ET Thanks Ryan, that makes a lot of sense and clears some things up for me.
I recently performed searchs of the forums for "custom" and "user defined" and learned a lot more, those who have an interest may want to do the same.
Regards,
Colin
> > [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.
Re: Book Management
Colin Cullen / ICAP 2 Sep 2010 12:35PM ET
|
