Imported from previous forum
[ original email was from Anthony Collyer - ]
Although the question of extending FIX to Fixed Income is being addressed I have seen nothing so far on the subject of extensions to cover derivatives. Is anyone else interested in this subject?
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Although the question of extending FIX to Fixed Income is being addressed I have seen nothing so far on the subject of extensions to cover derivatives. Is anyone else interested in this subject?
>
I am very interested in this. I’m guessing the biggest hurdle is probably going to be one of symbology.
Ryan Pierce
Townsend Analytics Ltd.
[ original email was from Anthony Collyer, Trinitech Systems - ]
> > Although the question of extending FIX to Fixed Income is being addressed I have seen nothing so far on the subject of extensions to cover derivatives. Is anyone else interested in this subject?
> >
>
> I am very interested in this. I’m guessing the biggest hurdle is probably going to be one of symbology.
>
> Ryan Pierce
> Townsend Analytics Ltd.
>
I have been in contact with both a)a business user of FIX as a means of transmitting derivatives information internally and b) the UK FIX symbology sub-committee. Both felt the following approach was valid:
Contents of field 55 – “Symbol”
Characters FieldType Example
1-5 Exchange LIFFE
6-10 Instrument BUND
11-15 Maturity 1998H
16 PutCallFuture P
17-30 StrikePrice 100.0078125
Any comments?
Best Regards
Anthony Collyer
Trinitech Systems International
[ original email was from Chris Morstatt - cmorstatt@erols.com ]
hey all,
i would recommend that rather than overload the symbol field, each of these should be defined as a separate field.
a couple of years ago bondnet made a proposal at a fix open forum to include these as separate fields, i think their proposal is in the old minutes…
chrism
> Contents of field 55 – “Symbol”
>
> Characters FieldType Example
> 1-5 Exchange LIFFE
> 6-10 Instrument BUND
> 11-15 Maturity 1998H
> 16 PutCallFuture P
> 17-30 StrikePrice 100.0078125
>
> Any comments?
>
> Best Regards
>
> Anthony Collyer
> Trinitech Systems International
>
I don’t like putting that in the Symbol field either. One potential compromise might be to define an IDSource of “FuturesAndOptions” with the positional characteristics you described and put the combined fields in the SecurityID field. The advantage of this is that IDSource and SecurityID are already in all of the business level messages which have Symbol specified (the couple which did not now do in the FIX 4.1 draft). The disadvanatges are that you’re still overloading a single field and you couldn’t also speicfy a CUSIP or SEDOL if desired.
BondNet’s proposal was given at the 8/28/1996 FIX Technical Forum meeting. They suggested using CUSIP as the SecurityID, an optional value for Symbol and add two new Symbol-related fiels: Coupon (xxxx.xxxxxx) and Maturity (Date). The rest of the recommendations delt with variations to support Price, Yield, and Spread to the places where Price is specified.
Thoughts??
> hey all,
>
> i would recommend that rather than overload the symbol field, each of these should be defined as a separate field.
>
> a couple of years ago bondnet made a proposal at a fix open forum to include these as separate fields, i think their proposal is in the old minutes…
>
> chrism
>
>
> > Contents of field 55 – “Symbol”
> >
> > Characters FieldType Example
> > 1-5 Exchange LIFFE
> > 6-10 Instrument BUND
> > 11-15 Maturity 1998H
> > 16 PutCallFuture P
> > 17-30 StrikePrice 100.0078125
> >
> > Any comments?
> >
> > Best Regards
> >
> > Anthony Collyer
> > Trinitech Systems International
> >
>
[ original email was from Bob Lamoureux - ]
PLEASE PLEASE PLEASE stay away from having fixed field definitions in the protocol. The whole point of self-describing fields is to allow flexability. God forbid we adopted a fixed field for this and then needed an extra character right smack in the middle…
> PLEASE PLEASE PLEASE stay away from having fixed field definitions in the protocol. The whole point of self-describing fields is to allow flexability. God forbid we adopted a fixed field for this and then needed an extra character right smack in the middle…
>
Amen! I thought we were escaping the headaches associated with fixed-length records.
> > PLEASE PLEASE PLEASE stay away from having fixed field definitions in the protocol. The whole point of self-describing fields is to allow flexability. God forbid we adopted a fixed field for this and then needed an extra character right smack in the middle…
> >
>
> Amen! I thought we were escaping the headaches associated with fixed-length records.
>
This is a very interesting topic. I am having the same problem with values that I don’t have FIX fields to put them on. My solution was to use the SecurityDesc field with values separated by a delimiter, but again, I don’t think that this is serving the FIX protocol purpose.
Questions:
How can we append all the fields that we need in the FIX Protocol?
Do we need to wait for another FIX Version to populate them?
You should look into using User Defined fields.
> Questions:
> How can we append all the fields that we need in the FIX Protocol?
> Do we need to wait for another FIX Version to populate them?
>
[ original email was from Shalom Reich - shalom.reich@neonsoft.com ]
> > > PLEASE PLEASE PLEASE stay away from having fixed field definitions in the protocol. The whole point of self-describing fields is to allow flexability. God forbid we adopted a fixed field for this and then needed an extra character right smack in the middle…
> > >
> >
> > Amen! I thought we were escaping the headaches associated with fixed-length records.
> >
>
> This is a very interesting topic. I am having the same problem with values that I don’t have FIX fields to put them on. My solution was to use the SecurityDesc field with values separated by a delimiter, but again, I don’t think that this is serving the FIX protocol purpose.
>
> Questions:
> How can we append all the fields that we need in the FIX Protocol?
> Do we need to wait for another FIX Version to populate them?
>
You can always add user defined fields to your message. This means changing your message descriptions and those of your counterparties and needs to be done on a bilateral basis. If the changes are needed by all participants, they should be submitted for the next release (I assume).
Shalom Reich
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
Can you provide some specifics on what type of fields are required?
Do they relate to futures and options product definition?
In the pastprocess has been to propose a user defined field. Once this is done it sets in motion a process of review by members of the FIX technical committee whereby - you may find that a field is already defined for that purpose or other users have identified it and it has already been defined with a user defined tag. If the user defined tag is defined - it is recorded on the website for other users to reference and it is likely to be considered for inclusion in a future version of the FIX standard - assuming wide enough applicability.
>
> This is a very interesting topic. I am having the same problem with values that I don’t have FIX fields to put them on. My solution was to use the SecurityDesc field with values separated by a delimiter, but again, I don’t think that this is serving the FIX protocol purpose.
>
> Questions:
> How can we append all the fields that we need in the FIX Protocol?
> Do we need to wait for another FIX Version to populate them?
>
>
> Questions:
> How can we append all the fields that we need in the FIX Protocol?
> Do we need to wait for another FIX Version to populate them?
>
I went to Tech Resources and then to the custom fields link. I only found the tag 9546 - Maturity Date.
Lets say that I need a field to identify if I am sending Return Cap, Underlying Price, or Both (in the quote FIX message). I will like to call this field CapPriceFlag, where 0=Return Cap, 1=Und. Price, and 2=Both.
1.- Can I submit this field as a new custom field on the Web?
2.- Should I take the first 9000 or 10000 number?
3.- Can I start using that field without waiting for an authorization from a FIX Technical Committe?
4.- Does the Quote Message needs to be modified on the FIX Server every time that we agree in a new field?