Imported from previous forum
The FPL Algorithmic Trading Working Group created a draft algorithmic schema that allows algorithmic providers to describe their algorithmic order types and parameters via XML. It also provides an optional foundation for dynamic rendering of algorithmic order entry screens, and an optional foundation for validation during order entry time, ahead of order submission.
The FPL Global Technical Committee has approved the draft schema for broader industry comment. The most current versions of all documents are available via a public directory on the FPL website:
http://www.fixprotocol.org/working_groups/algowg/documents
We would appreciate if you could take a look as soon as possible as we expect to begin pilot testing with interested parties in a few weeks. After that, the change process becomes much more rigid.
Included in the above directory is the Algorithmic Trading Working Group “Issues” document, which outlines currently known outstanding issues. This document will be updated in real time as issues, changes and enhancements are further identified.
Please respond with technical comments, ASAP, but no later than Friday, April 20th to algotech@fixprotocol.org. If you are also interested in doing a pilot please advise us.
Thanks very much.
Sincerely,
FPL Algorithmic Trading Working Group
Just one quick comment. In the examples for the Clock UI component, only HH:MM seem to be displayed. The FIX standard UTCTimestamp/UTCTimeonly fields suggest this should be HH:MM:SS or HH:MM:SS.sss.
We should probably clarify the exact format for date/time fields in algos and update the UI examples to show seconds/milliseconds as necessary.
thanks
Steve
[ original email was from Zoltan Feledy - zoltan_feledy@ssga.com ]
Steve,
Thank you for taking the time to review our proposal. Your suggestion is noted and will be addressed.
This did come up in a discussion just yesterday and we decided to only support the data types supported by FIX. We originally intended to offer support for legacy algorithmic specifications some of which required that time be sent in HHMM format.
As we will change the date/time support to match FIX, we will be sure to update the corresponding GUI components as well.
Thanks again for your time and input,
Zoltan
Just one quick comment. In the examples for the Clock UI component, only
HH:MM seem to be displayed. The FIX standard UTCTimestamp/UTCTimeonly
fields suggest this should be HH:MM:SS or HH:MM:SS.sss.We should probably clarify the exact format for date/time fields in
algos and update the UI examples to show seconds/milliseconds as
necessary.thanks Steve
A user preference setting could be used to enable/disable seconds or milliseconds on a clock component. I think this would be a feature of an OMS. If the user only wants to enter only hours and minutes then the OMS would, as a default, set seconds to zero and could still send a properly formatted datetime.
If the broker needs a specific granularity (or a different format altogether) then we have provided an attribute to describe the format. However, as Zoltan just noted, our recent train of thought is to depricate this attribute and support only the standard FIX date and time formats.
-Greg
However, as Zoltan just noted, our recent train of thought is to
depricate this attribute and support only the standard FIX date and
time formats.
I agree it would be preferable to stick to existing FIX standards where we can. In a similar vein, I noticed there was some discussion of START_DAY and END_DAY indicators, and wonder whether it would make more sense to use the existing tag 59=TimeInForce eg. “At the Opening” and “At the close” values?
cheers
Steve
[ original email was from Zoltan Feledy - zoltan_feledy@ssga.com ]
Steve,
Thanks again for your review. The keywords we were considering had to do with strategy parameters. Most algorithms have start and end times as input parameters. Something along the lines of: Run this algo from “Now” until “Market_Close”. These keywords would specify points in time.
This is somewhat different from TimeInForce(59) where you would specify a duration for the order. Probably “Day” orders (59=0) for algos but this would be overridden by what is specified in the parameters for the algo.
Zoltan
However, as Zoltan just noted, our recent train of thought is to
depricate this attribute and support only the standard FIX date and
time formats.I agree it would be preferable to stick to existing FIX standards where
we can. In a similar vein, I noticed there was some discussion of
START_DAY and END_DAY indicators, and wonder whether it would make more
sense to use the existing tag 59=TimeInForce eg. “At the Opening” and
“At the close” values?cheers Steve
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
A few comments on “Algorithmic Trading Schema Proposal v2.2.1.doc”
Conditional fields. A lot of algos only need value X populated if value Y is populated. To make the algo easier to understand why not allow this conditionality to be made explicit. This way an OMS vendor can make the user interface simpler by ‘greying-out’ fields that are conditionally required where the depends-on field has not been set. The validation sub-schema seems to cover some of this but it’s a bit unclear
Time stamps. All time related fields will generally be defaulted by the broker at their end. So why not provide the defaulting at the front end? Allow “standard tenors” to be used - similar to a yield curve “NOW”, “NOW plus xx”, “Cash close”, “End of morning session” and so on. If a buy-side in Paris sends an order to a broker in London an order for a multi-listed instrument which exchange open time do you use? Which close time? This whole area is handled through the brokers defaulting to values but this should really be set on the front end. Since the front end may not have access to the static data to accurately specify the precise time, why not just use the “standard tenors”.
“locations” and “disclosureDoc” attributes. Enhance this - add in contact details for the dealing desk
Example “Algo XXX is available for New York desk - email address is algoex@megabank.com phone number is +1 212 666 6666”
Makes is easier for the buy-side dealer to see contact details.
Glad you brought up conditional fields…
We have recently added another sub-schema (flow) that deals with flow control. It addresses exactly the situations you are describing, i.e. based on the existence or value of one para,eter you may want to disable or grey-out another parameter. The flow sub-schema will let you do just that. We should have the latest version of the schema files up on Algo WG site very shortly, so please download it and take a look at the examples.
As far as standard tenors go - we have thought about it but have decided to leave it foir future versions of the standard. Most of the broker dealers were comfortable with using actual times such as 16:00 for mkt close. This is fine for now, but I’m in agreement withyou that we’ll need to make some enhancements. Be warned - we may call on you when we get around to supporting it.
-Greg
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
Happy to discuss, mailed you offline.
I’d like to pick up on one general point made: “Most of the broker dealers were comfortable with using actual times such as 16:00 for mkt close.”
Ok, but did anyone ask the buy-side?
The technical implementation is one thing, but it’s all about making algos user friendly - that’s the thing that matters. User friendly = gets used by the buy-side = MONEY for the broker.
The analogy I have given to many brokers is like cars. It’s fine that cars have different engines, gearboxes, steering, suspension etc. But (for the UK) let’s keep the pedals in the same order and the steering wheel in front. Gearstick on the left of the driver. That’s a user friendly car - let’s make algos user friendly.
A prediction: never mind the number of installed desktops (a bogus measure), the provider to the buy-side that has the most algo order flow to the sell-side will be the one with the easiest to use front end.
For the techie audience, think of the difference between a command line and a GUI. A command line is great if you really know what you are doing. For mere mortals a GUI is a way better way to work. And that GUI has to behave in a smart manner - default everything, conditional logic, dropdowns populated with meaningful values (“Aggressive”, “Medium”, “Passive” - not 1,2,3) and a user look and feel like a well thought through metaphor and implicit workflow.
Just my 2p worth…