SMART order execution speed

[Anonymous]

Has anyone had any luck trying different SMART order execution types on IB?

I’m having an issue at the moment with the amount of time it is taking the API/TWS to completely fill an order.

The problem manifests itself when the order volumes are large. For example, if I have submitted a LMT order for say, 20,000 quantity, if my limit price is reached then then fills commence, however it will be in a block of 100 units, then 300, then 100, then 200, then 700, then 200, then 1,100 then 200… and so on in seemingly random order until the order is complete. The problem here is that it could take a good two minutes to chew through executing the full 20,000 unit order and in this two minutes the price may have fluctuated by ten cents on $15 and I’m already losing a potential 1%. In some occasions it is to my benefit, but in other occasions (like my 15,000 unit order on GT (GoodYear) a few days ago), I got filled on 1,500 units but the remaining 13,500 got no fill at all because by the time 30 seconds had passed in filling the first 1,500 units the live pricing was well above my limit price and I could no longer get any fills.

Not only this, but all these multiple buckets of execution are adding up to perhaps $80 of commissions to complete the trade of all 20,000 units.

So I am thinking of trying something like SMART MaxFill or some other order type to perhaps speed up the execution of the trades. I am sure this will come with a higher commission cost, which I will have to measure in time.

Does anyone have any pointers or ideas on improving execution/fill speed?

[ScottMcNab]

Its not a direct answer to your question Matthew but an improvement may be achieved by reducing the volume for each order…you may be at the limits of what can trade with this type of system without moving the market. Does your system test ok on other markets? I am running my MRV on RUI but it also works well on RUT excluding RUI…so could halve the volume by constructing 2 markets from RUT…hopefully this would reduce impact.

[RobGiles]

Along the lines of what Scott is saying, it sounds as though it might simply be a liquidity issue, given that it looks like you’re swinging a fairly large bat. Can you test your system on a smaller universe of larger cap / higher liquidity stocks?

[Anonymous]

Scott and Rob,

Thanks for the ideas. I understand your thinking, but if anything, I would say maybe the logix is right but it is in the wrong direction. That is, if I move to a broader universe the market caps are going to probably be lower, thus creating even further problems with lower share prices and lower trading volumes for that instrument within one day. If I am then running positions on lower share prices, volumes are going to need to be higher, if anything to meet my position requirements and the prblem deepens because I won’t be looking for 15,000 units on $15, I might be looking for 45,000 units on 5$ and a share that may only have an average volume of 300K units in a full day. .

That said, the obvious answer would be to go to higher cap stocks, like NASDAQ100 so I can get a $500 share and only need to send an order for 600 units, however therein lies the problem. For reversion systems they like volatility and my tests in NASDAQ and S&P500 are only so so on these systems. Therefore I need to find the right balance and it seems RUI is a good one.

Still, I don’t think it is an overall liquidity/volume issue either. My filters are filtering out average daily volume over 1 Mil units and in these examples are trading many millions of units in the day, with many of those at beginning of session, so in my opinion a 15,000 unit order isn’t exactly going to sway the market much (or at all), especially when within the same 60 second block of time there are probably a good 500,000 units worth of orders for the broker to fill from all and sundry.

I still am unsure why it takes a good 60 seconds to pump through all the small packet of fills across so many individual orders in small packets of 100 or 300 or 200 or other such random buckets in the hundreds only. Maybe this is just the SMART functionality working correctly and if I want instant fill across fewer orders in larger buckets I need to accept a different order type with the drawback of potentially worse fill pricing?

[SaidBitar]

So if liquidity is not the issue, then it might be that there are not enough orders to sell on this price.
you can try replacing SMART with ISLAND if the stock is traded on NASDAQ but the problem if the stock is traded on other exchanges then there is a list of them and it will be tricky to know which one to put.
but for start you can try with ISLAND i believe that it can route all of them.

if you are entering on limit then you will not have any slippage but if you are using market for entering or exiting then yes it will happen. I noticed this with the MOC systems but not often.

[Anonymous]

Said,

Thanks for the input.

The thing I find “interesting” is that at end of day when the order executes as MOC, it ALWAYS gets an immediate and absolute fill across any quantity I enter. Whether its a 50 unit order or a 25,000 unit order, I always get filled on the sell, instantly, within seconds. That said, I cannot see how if in the SELL action you get immediate and absolute action on the fill without any potential liquidity issues but at the start of the day when you are seeking a Buy that you should then face market liquidity issues slowing down potential trades.

I am entering the trades on LMT yes, however the issue with the FHN trade on the 18th July (Sorry I said it was Goodyear, but it was FHN for 17,370 units at 16.74 LMT) was that it opened at 16.65 and hit a low of 16.61 within the first minute, in which same minute traded 147k Vol across the whole market. In the second minute low was 16.74 and traded a further 34K Vol. So if the price stayed at or below 16.74 for a full two minutes after open and traded a good 180K volume I can’t see the issue in why my order of total 17,370 units would have any great effect or not be able to be executed.

I just don’t “believe it” or think that IB only has the capacity to fill this amount of orders (a total of just 1,500 units) within a two minute period of time. BUT, I have to remember that this is also on the paper trade account. Maybe this is “one of those things” that I have to accept in that the paper trade operates at nowhere near the true market accuracy or execution speed. That is ok, if that’s the case I’m happy for someone to tell me so, however I am reluctant to send a system to live trading if I am having an issue like this.

Another avenue I am thinking is that could it be the way my VPS operates and also the fact that I was using remote desktop protocol to watch the action at the open. My reasoning:
1. VPS is after all, a VPS. It is a shared, virtual resource which is likely serving perhaps four or five other virtual computers/desktops at the same time on one bare metal server. Could it be that my VPS is struggling right on the open due to the compute demand from the other virtual customers bombing the server at the same time with similar workload?
2. Same story for internet connection. Could the internet connection from the VPS to the IB sever in Equinix NY4 be lagging right on the open? Is it possible to set it up with IB that I want my primary gateway to be Central instead of East or vice versa? Or do they just allow TWS to always make the decision itself? As my VPS is set up in a Chicago location, perhaps I might be able to get IB to set up Central IB server as my primary gateway?
3. I was watching the remote desktop do its thing on the open at the time. When connected to me here in China, the internet is just bloody horrible, and I don’t know exactly how windows RDP works, but perhaps the desktop and operating system itself is somewhat slowed down when it is struggling to deliver real time screen activity via RDP to me here in China. I know the VPS itself is actually doing all the work with IB locally within the US and the RDP service should just be a thin client snapshot window of the world to show me what is happening, however none the less, perhaps it still does slow down operations on the VPS when it is struggling to deliver screenshots through to me in China?

[JulianCohen]

Matthew I didn’t realise this was the paper trading account.

When I used the paper trading account I got crap fills a lot of the time. It is pretty much useless for our purposes I believe.

I would expect this problem to disappear on a live trading account. I have to admit I was finding it hard to understand why your fills were so poor until I saw the words “paper trading”

Honestly I ran my first system initially on a paper trading account and gave up after a week. Just went live with it and didn’t look back.

[SaidBitar]

Paper Trading account this is why, this problem will not happen in live account.

[Anonymous]

OK thanks Said and Julian for the confirmation. Knowing others have faced the same crap on the paper trade account and they were otherwise immediately resolved in going live, I feel a lot better.

[Author]

Posts