Algorithmic trading, VWAP and Piccolo

[nononsense]

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?

Stephen,
In my experience, the main problem is to get at the 'state' of your TWS-IB operations inside your own computer. This is far from simple and documentation is very inadequate (restarts, dropouts, etc). It is obvious that all this was put together by people who never traded themselves over an API. In defense of IB however, they are still the most advanced. Over the years, many discussions were posted on this at IB's forum, mainly under API. I learned a lot from these.

I worked a long time on my own solution, but once you have this licked it becomes relatively trivial.

As to FIX, it seems that IB is kind of a slow starter on this. Maybe similar problems. A real McCoy would be to start getting rid of Java and forget about FIX.

 

[stephencrowley]

Quote from nononsense:

Stephen,
In my experience, the main problem is to get at the 'state' of your TWS-IB operations inside your own computer. This is far from simple and documentation is very inadequate (restarts, dropouts, etc). It is obvious that all this was put together by people who never traded themselves over an API. In defense of IB however, they are still the most advanced. Over the years, many discussions were posted on this at IB's forum, mainly under API.

I worked a long time on my own solution, but once you have this licked it becomes relatively trivial.

As to FIX, it seems that IB is kind of a slow starter on this. Maybe similar problems. A real McCoy would be to start getting rid of Java and forget about FIX.

I'm not hating on IB here, I'm just saying that the API in its current sate is inadequate for my purposes. It is obviously a fine solution for many people.

The problems you mention (drop outs, etc) are very important issues that should easy to handle from the API.

As far as being the most advanced, what criteria are you using to judge? TWS itself is definitely very advanced.. but from an API perspective it certainly isn't..

Lime's api is however handles dropouts beautifully and can tell you individually which streams are connected/disconnected, automatic reconnection, etc as well as giving raw data (milliseconds) and all that so you can estimate latencies yourself. There are better apis out there..

Quote from IBsoft:

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.

I meant co-located the server in your facilities.. as far as aggregate depth that is understandable because inidividual orders at every level is overkill most of the time, but it would be bery nice to have the number of orders and the total size so you could at least calculate the average order size at that level. ms timestamps are generated by the exchanges I care about.

 

[IBsoft]

Quote from nononsense:

Stephen,
In my experience, the main problem is to get at the 'state' of your TWS-IB operations inside your own computer. This is far from simple and documentation is very inadequate (restarts, dropouts, etc). It is obvious that all this was put together by people who never traded themselves over an API. In defense of IB however, they are still the most advanced. Over the years, many discussions were posted on this at IB's forum, mainly under API. I learned a lot from these.

I worked a long time on my own solution, but once you have this licked it becomes relatively trivial.

As to FIX, it seems that IB is kind of a slow starter on this. Maybe similar problems. A real McCoy would be to start getting rid of Java and forget about FIX.

You seem to have a hard time resisting raising your "get rid of Java" issue everywhere.

Anyway, IB is not slow starting the FIX; we have had it for years and it is being utilized by all our institutional clients. We have also made it available to retail, partially on your request. I hope you are using it.

 

[stephencrowley]

Quote from nononsense:
As to FIX, it seems that IB is kind of a slow starter on this. Maybe similar problems. A real McCoy would be to start getting rid of Java and forget about FIX. [/B]

I don't know about FIX.. the only reason I can think of for using it are if you are getting a raw quote feed via a socket. If you are already using the API for quotes, why not use it for orders?

Re: java. What do you suggest as a replacement? Java is absolutely beautiful compared to most of the other things out there. Dotnet would be nice if it wasn't tied to mickeysoft. (Yes i know about mono but it is terrible)

The only way I would support some broker moving away from java is if they allowed clients to connect with raw sockets and published a thouroughly documented protocol reference.

 

[IBsoft]

Quote from stephencrowley:

I'm not hating on IB here, I'm just saying that the API in its current sate is inadequate for my purposes. It is obviously a fine solution for many people.

The problems you mention (drop outs, etc) are very important issues that should easy to handle from the API.

As far as being the most advanced, what criteria are you using to judge? TWS itself is definitely very advanced.. but from an API perspective it certainly isn't..

Lime's api is however handles dropouts beautifully and can tell you individually which streams are connected/disconnected, automatic reconnection, etc as well as giving raw data (milliseconds) and all that so you can estimate latencies yourself. There are better apis out there..




I meant co-located the server in your facilities.. as far as aggregate depth that is understandable because inidividual orders at every level is overkill most of the time, but it would be bery nice to have the number of orders and the total size so you could at least calculate the average order size at that level. ms timestamps are generated by the exchanges I care about.

We currently don't have clients co-locating. However, it seems that you also have a list of other issues that would need to be addressed in order for you to become a client. Perhaps some day in the future we can do business together. Thanks for the conversation.

 

[stephencrowley]

I guess I'm just tough to please .. I'l definately keep an eye out in the future. Good luck

Quote from IBsoft:

We currently don't have clients co-locating. However, it seems that you also have a list of other issues that would need to be addressed in order for you to become a client. Perhaps some day in the future we can do business together. Thanks for the conversation.

 

[alanm]

Because of the focus on performance, I'm guessing, too, that Stephen wants to route his orders himself, and not via SMART. This doesn't work well with IB's fee structure.

 

[stephencrowley]

Yes, I do route myself.. each exchange has different rules and fee structures so I optimize using that information as well.

Quote from alanm:

Because of the focus on performance, I'm guessing, too, that Stephen wants to route his orders himself, and not via SMART. This doesn't work well with IB's fee structure.

 

[nitro]

I don't know anything about the Goldman algos.

IB has VWAP guarantees, and the orders exist on their servers - not sure about TWAP.

I don't see why non-NYSE stocks are an issue at the "close" - they continue to trade after the close on ECN's, althought admitedly the B/A spread widens somewhat. But in a pinch, that will do.

In my experience, unless the stock has earnings, there is almost zero chance of a disaster of trading liquid NAZ stocks on ECNs in the after hours as an "emergency" exit. Howerver, I do appreciate your desire to wanting to cover as many contigencies as possible during RTHs.

nitro

Quote from stephencrowley:

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

 

[nitro]

Quote from IBsoft:

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

IBsoft,

Thanks for the gracious offer. One day I may take you up on it.

nitro