Imported from previous forum
[ original email was from Khody Azmoon - kazmoon@algotm.com ]
At FPL Americas Trading Conference 2011 in New York, an audience member mentioned at the “FIX vs. Proprietary Protocols: The New Fragmentation” technical session that NASDAQ was exploring options with FPL in regards to its binary protocol. Does anyone have any updates regarding this?
Discussions are ongoing. A charter is being drafted to form a working group with key exchange participation to address HFT requirements based upon the work largely done by Rolf Andersson and Mark Reece. My belief is we now have interest from key market structure providers to make the effort worthwhile.
From an equities perspective Ouch and Itch have proven themselves to be fit for purpose for trading (as opposed to order processing). Both protocols have been extended into derivatives. But, there are shortcomings in terms of the flexibility that FIX provides. Itch and Ouch are de facto industry standards along side FIX.
But, the starting point is to define the requirements specifically (not generally), before delving into a specific solution. With high end FIX message parsing being done sub-10 microseconds, do we need to completely move away from existing infrastructure? Or, should we look at the specific areas of the standard FIX Protocol that are decreasing its “fit-for-purposefulness” for HFT. Things such as message size, order handling semantics, session layer recovery, come to mind as areas that are not fit for the purpose of HFT.
I hear from the equity trading community “just give me Itch and Ouch”. I hear from order routing folks “use FIX.4.2 or FIX.4.4”. But I am unaware of even a cursory analysis of the appeal and what is the benefits and “fit-for-purposefulness” of Itch and Ouch. My conjecture is that benefits are there intrinsically, as opposed to “use Itch and Ouch” because we already use it. There is an appeal in terms of its core technical and functional value. It would be good to have this assessment performed as part of this reconstituted working group.
This new group building upon the quality work for Mssrs. Andersson and Reece is an appropriate starting point.
I agree there is some sense of urgency and import to this effort.
My major concern in terms of coming up with an HFT solution is trying to create a standard that can be a horizontal technology standard and general use and as a result becomes overly complicated. My belief is that simple fit-for-purpose solutions that are understandable are what ultimately gain adoption.
[ original email was from Khody Azmoon - kazmoon@algotm.com ]
Thanks Jim. It does seems FIX 4.4, 4.2, and 4.1 are still very popular. It would be ideal to see the next major iterations of FIX protocol making a shift towards this field.
Regards,
Khody
Discussions are ongoing. A charter is being drafted to form a working group with key exchange participation to address HFT requirements based upon the work largely done by Rolf Andersson and Mark Reece. My belief is we now have interest from key market structure providers to make the effort worthwhile.
From an equities perspective Ouch and Itch have proven themselves to be fit for purpose for trading (as opposed to order processing). Both protocols have been extended into derivatives. But, there are shortcomings in terms of the flexibility that FIX provides. Itch and Ouch are de facto industry standards along side FIX.
But, the starting point is to define the requirements specifically (not generally), before delving into a specific solution. With high end FIX message parsing being done sub-10 microseconds, do we need to completely move away from existing infrastructure? Or, should we look at the specific areas of the standard FIX Protocol that are decreasing its “fit-for-purposefulness” for HFT. Things such as message size, order handling semantics, session layer recovery, come to mind as areas that are not fit for the purpose of HFT.
I hear from the equity trading community “just give me Itch and Ouch”. I hear from order routing folks “use FIX.4.2 or FIX.4.4”. But I am unaware of even a cursory analysis of the appeal and what is the benefits and “fit-for-purposefulness” of Itch and Ouch. My conjecture is that benefits are there intrinsically, as opposed to “use Itch and Ouch” because we already use it. There is an appeal in terms of its core technical and functional value. It would be good to have this assessment performed as part of this reconstituted working group.
This new group building upon the quality work for Mssrs. Andersson and Reece is an appropriate starting point.
I agree there is some sense of urgency and import to this effort.
My major concern in terms of coming up with an HFT solution is trying to create a standard that can be a horizontal technology standard and general use and as a result becomes overly complicated. My belief is that simple fit-for-purpose solutions that are understandable are what ultimately gain adoption.
[ original email was from Khody Azmoon - kazmoon@algotm.com ]
Article FYI …
Thanks Jim. It does seems FIX 4.4, 4.2, and 4.1 are still very popular. It would be ideal to see the next major iterations of FIX protocol making a shift towards this field.
Regards,
Khody
Discussions are ongoing. A charter is being drafted to form a working group with key exchange participation to address HFT requirements based upon the work largely done by Rolf Andersson and Mark Reece. My belief is we now have interest from key market structure providers to make the effort worthwhile.
From an equities perspective Ouch and Itch have proven themselves to be fit for purpose for trading (as opposed to order processing). Both protocols have been extended into derivatives. But, there are shortcomings in terms of the flexibility that FIX provides. Itch and Ouch are de facto industry standards along side FIX.
But, the starting point is to define the requirements specifically (not generally), before delving into a specific solution. With high end FIX message parsing being done sub-10 microseconds, do we need to completely move away from existing infrastructure? Or, should we look at the specific areas of the standard FIX Protocol that are decreasing its “fit-for-purposefulness” for HFT. Things such as message size, order handling semantics, session layer recovery, come to mind as areas that are not fit for the purpose of HFT.
I hear from the equity trading community “just give me Itch and Ouch”. I hear from order routing folks “use FIX.4.2 or FIX.4.4”. But I am unaware of even a cursory analysis of the appeal and what is the benefits and “fit-for-purposefulness” of Itch and Ouch. My conjecture is that benefits are there intrinsically, as opposed to “use Itch and Ouch” because we already use it. There is an appeal in terms of its core technical and functional value. It would be good to have this assessment performed as part of this reconstituted working group.
This new group building upon the quality work for Mssrs. Andersson and Reece is an appropriate starting point.
I agree there is some sense of urgency and import to this effort.
My major concern in terms of coming up with an HFT solution is trying to create a standard that can be a horizontal technology standard and general use and as a result becomes overly complicated. My belief is that simple fit-for-purpose solutions that are understandable are what ultimately gain adoption.