Ago Trading Proposed Extensions v1.0

, ,
1

Imported from previous forum

2

[ original email was from jim whitehead - jwhitehead@latentzero.com ]
Hi there

Page 7 of the FPL Algo Trading Working Group Proposed Ago Definition Schema, makes reference to

‘List of the extension models supported as described by Algorithmic Trading Proposal Extensions v1.0’

Is the Extensions document available for perusal anywhere?

It doesn’t appear to be in the repository here:
http://fixprotocol.org/working_groups/algowg/documents

Thanks in advance for your help
Jim

3

The document is posted under the “Past Materials” section. You may need to be logged in or have certain privileges to access it. We’re in the process of moving it to the public section.

4

Jim,

It’s pretty wild you mention trading extensions because we were working on that at the last Tech meeting and also in the documentation.

We eliminated algoExtModel= in the strategy element. It’s not needed.

Down in the parameter elements there are three simple ways to go:

  1. standard fix tag (for all base order parameters) - here there is no “extension model” so you go with the well established FIX standard tag. Also note - we have gone to having ALL parameters fully expressed in the xml files. (base order parameters, and of course the algo parameters).

  2. Tags in the 5000-9999 area (for custom algo parameters only). This was the technique used by every beta tester and is well known to work on older FIX hubs, routing networks, older FIX engines, etc. This is the safe, conservative route for right now. Everyone understands the flat structure TAG=Value convention, the variable name on the left, the value on the right, metadata always on left, standard assignment direction, predicate logic, etc.

  3. 957-960 repeating group (again for custom algo parameters only) The only note here is on (959) below. We almost eliminated this as an option but after several people made exceptionally good arguments to keep it, we retained it. It is however more complex, analogous to packing several fields into a single database field and unpacking it on the other end. However it does offer some advantages, similar to having an array that has no pre established upper bound. And that can be handy in things like NewOrderList where you don’t know in advance how many items are going to be in the list, etc. Also some Sell-Side firms have internal tag librarians that assign FIX tag numbers in the 5000-9999 area through a lengthy and bureaucratic internal process. The high speed algo developers want to avoid that delay and tunnel algo parameters though the repeating groups so they can get algo product out the door very quickly to their top clients.

To recap:

  1. there is no longer any algoExtModel= that covers all algo parameters
  2. each algo parameter may be 5000-9999 OR included in a 957-960 repeating group (and within a single strategy they may be mixed)
  3. the xml files now will carry ALL order parameters, including the custom algo parameters and every base order parameter. So when you get the xml file you know exactly what to send to the target, including EVERY parameter.

Rick

Note on using the repeating group:

[From the prospective of the OMS sender, sending an order to a Sell-Side target, which is constructed based on an XML file supplied by that Sell-Side target] (1) StrategyParameterType (959) should be sent (for simple repeating group consistency) however it is 100% superfluous and should be ignored by the target. The dataType is explicitly expressed in the XML within the Parameter element (or is unequivocally implied by a standard Fix tag attached to ParameterTagNo in the range of 1-4999). There is NO WAY for a SENDER to change the dataType of ANY parameter!