Imported from previous forum
[ original email was from Greg Malatestinic - Greg.Malatestinic@reuters.com ]
Is anyone interested in defining a standard DTD or schema that can be used to describe the parameters of an algorithm? The idea is that a GUI could be coded to render an order entry screen from XML data based on this schema. (XUL was mentioned in another thread).
From my discussions at the recent FPL conference I know that a few OMS vendors are in the process of doing this already so it seems that this idea has reached maturity. Is there any benefit to sharing this or is this something that the OMS providers feel is strictly proprietary?
[ original email was from Daniel Clayden - daniel.j.clayden@jpmorgan.com ]
> Is anyone interested in defining a standard DTD or schema that can be
used to describe the parameters of an algorithm? The idea is that a GUI
could be coded to render an order entry screen from XML data based on
this schema. (XUL was mentioned in another thread).From my discussions at the recent FPL conference I know that a few OMS
vendors are in the process of doing this already so it seems that this
idea has reached maturity. Is there any benefit to sharing this or is
this something that the OMS providers feel is strictly proprietary?
I personally would love to define an industry-standard DTD / XML schema that can be used to describe an algorithm. It was my previous thread that mentioned XUL - we’ve been playing with this technology for a few months now, and I’ve spoken to some OMS vendors about it, but not really got that far. I would be willing to share what I’ve done, if this was going to be a proper official FPL sponsored initiative leading towards an industry standard.
[ original email was from Giancarlo Cobino - giancarlo.cobino@displayfinance.com ]
> > Is anyone interested in defining a standard DTD or schema that can be
used to describe the parameters of an algorithm? The idea is that a
GUI could be coded to render an order entry screen from XML data based
on this schema. (XUL was mentioned in another thread).From my discussions at the recent FPL conference I know that a few OMS
vendors are in the process of doing this already so it seems that this
idea has reached maturity. Is there any benefit to sharing this or is
this something that the OMS providers feel is strictly proprietary?I personally would love to define an industry-standard DTD / XML schema
that can be used to describe an algorithm. It was my previous thread
that mentioned XUL - we’ve been playing with this technology for a few
months now, and I’ve spoken to some OMS vendors about it, but not really
got that far. I would be willing to share what I’ve done, if this was
going to be a proper official FPL sponsored initiative leading towards
an industry standard.
I’m quite interested in share my information with someone else. Actually I’m working on my own using some algorithmic trading and strategies and developing some new functionality related to mass quotation.
In case this is going to be an official working case I’ll be glad to work within it.
I’m confused.
“Algorithms” as used in a trading order context seems to have two distinct sub meanings. Here is a proposed very rough first draft of what I’m talking about:
An Algorithm type of order is more complex than simple combination of: market, limit or stop orders, issued as a single directive.
Type 1 – “Open”
*Disclosed and understood with the same meaning among at least 10 or more distinct clients (investors, traders, black boxes, etc.)
*Offered by at least 2 or more servers (brokers, ECN’s, Exchanges, etc)
*Often offered at higher scheduled commissions or transaction fees, perhaps reflecting greater value added over more simple order types
Type II - “Proprietary”
*Generally closely guarded trade secrete
*Rarely standardized
*Rarely communicated (as such) even between the client giving the order and the server receiving the order.
Obviously any DTD could only cover Type I above, or am I missing something? If a trader had a highly profitable Type II algo why on earth would he want it disclosed in a standardized DTD? Would he not want to issue all parts of the algo separately, and try like heck not to have anyone else reverse engineer it?
See also:
http://www.itsdoc.org/tiki/tiki-index.php?page=Algorithmic%20Trading
Rick
rick@ITSdoc.org
[ original email was from Daniel Clayden - daniel.j.clayden@jpmorgan.com ]
Its quite simple really - I think perhaps you’re reading too much into it. The DTD/XML schema proposal is purely to come up with a standard XML template that can be used to describe any algorithm offered by a sell-side broker, i.e. what parameters it takes, what FIX tags they map to, valid ranges / values for those parameters, etc. Its all about us being able to define a new algorithm on-the-fly, and then instantly make that available in your OMS, without you or your OMS vendor having to do any programming, or wait for an upgrade etc.
Numerous OMS vendors already have their own internal XML schema for doing this (and we even worked with one to get them up & running). My vision is to define a standard schema backed by the FPL, make it public, and encourage everyone to adopt it.
I personally would like to take this further and include some kind of rendering schema that tells an OMS how to display an algorithm & its parameters, but that can come later.
Daniel,
You may indeed be correct that I’m reading too much into this. I’ve got to confess, I’ve got nil experience with placing and executing alo orders. So, I’m starting with less experience in this area than you are probably used to dealing with. I’m in “student mode” here so please help me out.
Is the primary purpose for the XML DTD to enable the following?
-
Client (buy side) has an OMS that has various order types (market, limit, stop, etc.) built in and perhaps a few destinations (various markets, ECN’s, etc.) that it’s aware of.
-
Server (sell side) goes into the R&D laboratory and comes up with a spanking new order type. They work out the technical and system infrastructure details and start accepting this new order type from clients electronically. Simplified example: buy 10,000 of xyz at the VWAP today, guarantee the VWAP is executed, instructions on allocation to specific accounts to follow.
-
Server expresses that new order type availability in the new XML document following the proposed new DTD. This essentially amounts to a “very smart advertisement.”
-
Numerous client OMS’, if they are so “subscribed” to the servers XML message stream for the above documents, imports the new order types automatically.
-
Each client OMS (and there may be many different OMS software vendors represented here) then reconfigures itself internally and displays the brand new order type(s) on the client’s order entry screens automatically.
-
The XML document contains all the new information on the order type including full documentation, fee structure, guarantees, legal, hours, training pointers (see below), etc. such that the client can educate themselves on placing this newly offered order type, and can in fact can just fill in the fields and start submitting this new order type to the various servers who are offering it – i.e. no reprogramming or version upgrade of the OMS. The OMS simply reconfigures to support the new order type.
Question 1: is the new order type standardized across ALL the servers (sell side)? E.g. buy xxx shares of xyz at the VWAP today. Does that appear on the OMS as a SINGLE new STANDARD order type offered by MULTIPLE servers (sell side brokers), but perhaps with different commissions / fees / structures / terms for each? Or is each algo order type custom to each server such that the order types are now: VWAP-Morgan version, VWAP-GS version, etc.
Question 2: (for the benefit of us on the buy side who have not yet used alo trades extensively) what are the 10 or so most popular “standard” algo orders? I’ve included just about all I know about “standard” algo trades below. If you or others on this thread could give simple examples of the 10 most popular algo order types it would be exceedingly beneficial.
BTW, I think having a standardized DTD that allows the new order types just to show up on the OMS without reprogramming is a FANTASTIC idea!!! Even having standardized XML documents of very simple order terms, all in a common format, would be terrific. What buy sider wouldn’t love that?
There is one downside however I see that that must be well managed along the way.
I went to a MSFT presentation yesterday on Visual Studio 2005 - boy that thing is getting HUGE, and SLOW! The properties dialogue boxes on most standard visual components has at least doubled! (That’s a lot of attributes to memorize.) Most of it is a voluminous automatic code generator and multi wrapper of the traditional windows API and other MSFT APIs. At some point, dealing with all the new bells, whistles and options, and the associated learning curve becomes too steep, and programmer productivity actually goes down.
Parallel to the above “information overload” situation, I’m sure most investers and traders would want the OMS they are using day in and day out not to suddenly appear radically different, showing a huge number of strange new offerings. The learning curve to adopt new algo type orders (particularly as they increase in complexity) I’m sure will be steep. The XML documents should anticipate the natural sharp human resistance to change. They would need to be highly educational, perhaps wrapping complexity and revealing it in layers. The OMS has traditionally housed in a dedicated, live, real time device. Making that particular tube on the traders desk also a streaming video, educational workstation to learn about the new order types is probably not the way to go. Also, any delay in reconfiguring itself in response to the new order types during the trading day is unacceptable. The DTD for new algo orders will however definatly need pointers to all the educational and “edutainment” material so traders can come up to speed on new order offerings. That stuff can’t however clog up the live environment.
Rick
rick@ITSdoc.org
All I know about algo orders at the moment:
from: http://www.itsdoc.org/tiki/tiki-index.php?page=Algorithmic%20Trading
Slicing orders over time - for example instead of sending an order “sell 10,000 shares at the market” you break that up and send ten 1,000 share orders at the market at one hour intervals.
VWAP - Volume Weighted Average Price - sum (price * volume) for each trade during the day and divide by total volume for the day.
TWAP - Time weighted Average Price - Sum (Last trade price x number of seconds till the next trade) for each trade and divide by the number of seconds in the full trading day)
Basket-lists slicing - Here the portfolio manager sent a list of several stocks to trade (the basket). Slicing the basket obviously means breaking down the aggregate order into manageable pieces. Perhaps a certain slice of the basket can be arbitraged through a future on an index with minimal “statistical error” (i.e. not exactly lining up). Individual slices can be handled differently - some fully automated, some partially automated and perhaps a few slices just manually “worked.”
Pegging - Don’t know exactly how this works but perhaps triggering buying and selling timing to changes in overall indexes, etc. For example, with a large order to buy, start out in the morning with a little buying, buy more slowly as S&P price moves down, more quickly as S&P price moves up???
“I personally would like to take this further and include some kind of rendering schema that tells an OMS how to display an algorithm & its parameters, but that can come later.”
^ I agree, and in fact I think this is the key. The bottleneck appears to be not just getting the correct tags populated and sent to the broker but presenting the buy side with a rich-enough interface, inside their OMS, with which to set those parameters. Because the universe of algo parameters could remain dynamic and somewhat proprietary for some time. In other words, define a standard way to describe and lay out the trader’s screen, and behind that, a standard way to map those “user interface components” to FIX tags/values that the broker expects.
I will be unable to attend the group on the 14th but will catch up after.
Its quite simple really - I think perhaps you’re reading too much into
it. The DTD/XML schema proposal is purely to come up with a standard XML
template that can be used to describe any algorithm offered by a sell-
side broker, i.e. what parameters it takes, what FIX tags they map to,
valid ranges / values for those parameters, etc. Its all about us being
able to define a new algorithm on-the-fly, and then instantly make that
available in your OMS, without you or your OMS vendor having to do any
programming, or wait for an upgrade etc.Numerous OMS vendors already have their own internal XML schema for
doing this (and we even worked with one to get them up & running). My
vision is to define a standard schema backed by the FPL, make it public,
and encourage everyone to adopt it.I personally would like to take this further and include some kind of
rendering schema that tells an OMS how to display an algorithm & its
parameters, but that can come later.
[ original email was from Giancarlo Cobino - giancarlo.cobino@displayfinance.com ]
> I’m confused.
“Algorithms” as used in a trading order context seems to have two
distinct sub meanings. Here is a proposed very rough first draft of what
I’m talking about:An Algorithm type of order is more complex than simple combination of:
market, limit or stop orders, issued as a single directive.Type 1 – “Open” *Disclosed and understood with the same meaning among at
least 10 or more distinct clients (investors, traders, black boxes,
etc.) *Offered by at least 2 or more servers (brokers, ECN’s, Exchanges,
etc) *Often offered at higher scheduled commissions or transaction fees,
perhaps reflecting greater value added over more simple order typesType II - “Proprietary” *Generally closely guarded trade secrete *Rarely
standardized *Rarely communicated (as such) even between the client
giving the order and the server receiving the order.Obviously any DTD could only cover Type I above, or am I missing
something? If a trader had a highly profitable Type II algo why on earth
would he want it disclosed in a standardized DTD? Would he not want to
issue all parts of the algo separately, and try like heck not to have
anyone else reverse engineer it?See also: http://www.itsdoc.org/tiki/tiki-
index.php?page=Algorithmic%20TradingRick rick@ITSdoc.org
Of course I won’t share my algo, just because - as you correctly said - if I’ve created a profitable strategy why should I share it.
The problem is that we were talking about the message that includes the algo. So, we just want to create dedicated message that cover all the possible case.
If your idea is different please let me know and discuss about it.