Discussion Forums

Re: XML based rendering of custom parameters
Richard Labs / ITSdoc, LLC. <>
9 Nov 2005 10:24AM ET

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?

1. 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.

2. 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.

3. 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.”

4. Numerous client OMS’, if they are so "subscribed" to the servers XML message stream for the above documents, imports the new order types automatically.

5. 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.

6. 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???


XML based rendering of custom parameters
Greg Malatestinic / Reuters   7 Nov 2005 4:21PM ET
Re: XML based rendering of custom parameters
Daniel Clayden / JP Morgan   8 Nov 2005 5:11AM ET
Re: XML based rendering of custom parameters
Giancarlo Cobino / DISPL@Y Finance   8 Nov 2005 6:40AM ET
Re: XML based rendering of custom parameters
Richard Labs / ITSdoc, LLC.   8 Nov 2005 6:34PM ET
Re: XML based rendering of custom parameters
Daniel Clayden / JP Morgan   9 Nov 2005 3:33AM ET
Re: XML based rendering of custom parameters
Richard Labs / ITSdoc, LLC.   9 Nov 2005 10:24AM ET
Re: XML based rendering of custom parameters
Stephen Cooper / Miletus Trading, LLC   10 Nov 2005 3:54PM ET
Re: XML based rendering of custom parameters
Giancarlo Cobino / DISPL@Y Finance   9 Nov 2005 5:08AM ET