Algorithmic trading, VWAP and Piccolo

S

stephencrowley

So I have an automated strategy, and a defined half-life that tells me when I should stop entering new orders and begin winding down trades.

I don't want to just send market orders, but I also never want to be left with open positions.

Can VWAP or Piccolo guarantee that an order will be filled within a specfiied amount of time even if that time falls at the market close?
 
Quote from stephencrowley:

So I have an automated strategy, and a defined half-life that tells me when I should stop entering new orders and begin winding down trades.

I don't want to just send market orders, but I also never want to be left with open positions.

Can VWAP or Piccolo guarantee that an order will be filled within a specfiied amount of time even if that time falls at the market close?
More...
You can do a MOC is they are NYSE. Otherwise, you might want TWAP.

nitro
 
Interesting, so I can't trade non-nyse stocks with Goldman's algos? TWAP seems interesting but I don't have access to that. I could implement something on the client side, but I'd rather have it available on the broker side so I could also use it in disaster-scenarios (box crashes, fiber cut, whatever).

--Stephen

"The degree of one's emotions varies inversely with one's knowledge of the facts."
Bertrand Russell

Quote from nitro:

You can do a MOC is they are NYSE. Otherwise, you might want TWAP.

nitro
More...
 
stephencrowley and nitro:

If you describe the algorithmic order types you use (or would want to use), we would consider implementing them.

Please feel free to PM me.

Thanks.
 
Quote from stephencrowley:

IBsoft:

I appreciate the effort but your java API is way too heavy for my purposes.. the dependency on TWS is a real killer.
More...

I don't see how that is a problem, but thanks for the response.
 
There is no GUI in my trading system.. it runs in a server room somewhere. I realize I can run a virtual display but that greatly increases resouce consumption and latency. Ideally, there is a minimumal amount of processing between the socket and when it gets to my application. I haven't seen any design docs or performance specs for TWS+API but I cant imagine its faster than the API im using now. I could be completely misinformed though but stability, speed and simplicity are the only things I need. Once I get the data into my own system then I do useful things with it.. it just needs to get there asap.


Quote from IBsoft:

I don't see how that is a problem, but thanks for the response.
More...
 
Quote from stephencrowley:


There is no GUI in my trading system.. it runs in a server room somewhere. I realize I can run a virtual display but that greatly increases resouce consumption and latency. Ideally, there is a minimumal amount of processing between the socket and when it gets to my application. I haven't seen any design docs or performance specs for TWS+API but I cant imagine its faster than the API im using now. I could be completely misinformed though but stability, speed and simplicity are the only things I need. Once I get the data into my own system then I do useful things with it.. it just needs to get there asap.
More...

I think the TWS-API throughput holds up well. Currently we limit the incoming message rate at 50 per second. As to the speed, I don't have a concrete number as to how much delay the "extra hop" introduces. My guess is it would be in msec. I can dig up the numbers or have new tests done, in case you would seriously consider IB.

We have FIX as well. In that case you would only run a very lightweight process on your end, the sole purpose of which is authentication and routing messages to our gateway. Have you considered that option? Thanks.
 
It's pretty important for me that the message rate is not limited.. does this limit apply to colocated servers as well? FIX is fine but I've found it to be a real pain to deal with.. and also, FIX for quote dissemenation is not realistic due to the amount of bloat in the protocol. Also, having the source time generated by the exchange (accurate to the millisecond) for every single trade and depth update is very important for estimating latency and filtering. Also, doesn't appear nasdaq totalview is available either.

Quote from IBsoft:

I think the TWS-API throughput holds up well. Currently we limit the incoming message rate at 50 per second. As to the speed, I don't have a concrete number as to how much delay the "extra hop" introduces. My guess is it would be in msec. I can have tests done, in case you would seriously consider IB.

We have FIX as well. In that case you would only run a very lightweight process on your end, the sole purpose of which is authentication and routing messages to our gateway. Have you considered that option? Thanks.
More...
 
Quote from stephencrowley:

It's pretty important for me that the message rate is not limited.. does this limit apply to colocated servers as well? FIX is fine but I've found it to be a real pain to deal with.. and also, FIX for quote dissemenation is not realistic due to the amount of bloat in the protocol. Also, having the source time generated by the exchange (accurate to the millisecond) for every single trade and depth update is very important for estimating latency and filtering. Also, doesn't appear nasdaq totalview is available either.
More...

We can't have unlimited message rate. I am not sure what you mean by co-located servers, i.e. what is co-located with what. We don't do market-data through FIX; instead we use our own compressed protocol. Not all exchanges generate time accurate to the milisecond for every single trade; for the ones that do it, we could send it to you - although I would have to have some idea about the level of commissions you expect to generate to initiate such a customized upgrade. We have market-depth. We have not programmed that because our customers did not want to pay for it. We give them the combined: depth of each individual ECNS and one price level per market maker from the Montage.

We would program the algorithmic trading for free, because it is something we want to do anyway.
 
You must log in or register to reply here.
Back
Top