NexusFi: Find Your Edge


Home Menu

 





Market spikes Vs. Bracket Orders - how does your platform handle that?


Discussion in Platforms and Indicators

Updated
      Top Posters
    1. looks_one xplorer with 11 posts (10 thanks)
    2. looks_two DavidHP with 3 posts (6 thanks)
    3. looks_3 iantg with 3 posts (5 thanks)
    4. looks_4 SMCJB with 2 posts (2 thanks)
      Best Posters
    1. looks_one DavidHP with 2 thanks per post
    2. looks_two iantg with 1.7 thanks per post
    3. looks_3 sam028 with 1 thanks per post
    4. looks_4 xplorer with 0.9 thanks per post
    1. trending_up 5,208 views
    2. thumb_up 25 thanks given
    3. group 4 followers
    1. forum 21 posts
    2. attach_file 3 attachments




 
Search this Thread

Market spikes Vs. Bracket Orders - how does your platform handle that?

  #1 (permalink)
 
xplorer's Avatar
 xplorer 
London UK
Site Moderator
 
Experience: Beginner
Platform: CQG
Broker: S5
Trading: Futures
Posts: 5,945 since Sep 2015
Thanks Given: 15,447
Thanks Received: 15,292

So yesterday I had what could be termed as 'freak accident' trading-speaking.


I had placed a bracket limit order on a swing which I hoped could provide some small support.

Just as price reached my entry point, there was a significant spike down - from a fundamentals perspective I think one of the contributors to the spike may have been news that Boris Johnson (yes, the clown) in the UK resigned, which affected 6B, which dragged down 6E, which probably in turn affected DXY and thus CL.

The spike was so fast that my stop was rejected.

By 'rejected' I mean, by the time the bracket order limit was filled and then tried to trigger a stop, the market was already beyond where the stop should have been placed.

(The exact error code was "RejectFCM - Stop price is already in market, ExchangeRejectCode=5').


Eventually I had to close the trade manually. Thankfully this was a SIM trade, otherwise I would be looking at a 37 tick loss on a scalp, which usually tries to take a handful of ticks out of the market. Not pretty.




But the same principles apply to live trades. CQG - which is the platform I use - tends to have a fairly realistic SIM engine, so I could expect to experience a similar event live.



After some to and fro with CQG support, they eventually confirmed this would happen live as well, although they wanted to point out that "this rejection would happen on any platform."


On this latter point, I am looking for your experience.

I fully understand that latency may always play a part in how our orders are handled between our platform and the Exchange, but surely the way a trading platform and its infrastructure are built contribute too?


By that I mean:
  • the algorithm that handles orders can be written more or less efficiently
  • the language with which the platform is built with can have an impact on the speed of execution
  • the infrastructure routing your order could have preferential routes to the Exchange

In other words, the latency issue could be somewhat mitigated (I want to stress, I am not suggesting that any such problems can be avoided altogether, but I think they can be mitigated)

So, my first question:
If you've been trading for a while, something similar may have happened to you. How does your platform compare?

I am curious about most platforms, but I'd be particularly keen to hear also from people using TT ( @SMCJB ) which I suspect has an infrastructure similar to CQG, and see how this is handled.


Second question:
If this turns out to be a case of 'it's just latency, all platforms will behave this way', to avoid such events, isn't it better then to forget bracket orders and just place a limit and a stop manually?



Grateful for you sharing your experience.


Thanks

Started this thread Reply With Quote
Thanked by:

Can you help answer these questions
from other members on NexusFi?
My NT8 Volume Profile Split by Asian/Euro/Open
NinjaTrader
NT7 Indicator Script Troubleshooting - Camarilla Pivots
NinjaTrader
Are there any eval firms that allow you to sink to your …
Traders Hideout
Better Renko Gaps
The Elite Circle
NexusFi Journal Challenge - April 2024
Feedback and Announcements
 
Best Threads (Most Thanked)
in the last 7 days on NexusFi
Get funded firms 2023/2024 - Any recommendations or word …
61 thanks
Funded Trader platforms
44 thanks
NexusFi site changelog and issues/problem reporting
24 thanks
GFIs1 1 DAX trade per day journal
22 thanks
The Program
19 thanks
  #3 (permalink)
 
xplorer's Avatar
 xplorer 
London UK
Site Moderator
 
Experience: Beginner
Platform: CQG
Broker: S5
Trading: Futures
Posts: 5,945 since Sep 2015
Thanks Given: 15,447
Thanks Received: 15,292


@sam028 this strikes me as something you also would be able to offer an insight about

Started this thread Reply With Quote
  #4 (permalink)
 
SMCJB's Avatar
 SMCJB 
Houston TX
Legendary Market Wizard
 
Experience: Advanced
Platform: TT and Stellar
Broker: Advantage Futures
Trading: Primarily Energy but also a little Equities, Fixed Income, Metals and Crypto.
Frequency: Many times daily
Duration: Never
Posts: 5,041 since Dec 2013
Thanks Given: 4,375
Thanks Received: 10,192

I don't have a lot of experience with stop orders so can't be much help here. Sorry.

Reply With Quote
Thanked by:
  #5 (permalink)
 iantg 
charlotte nc
 
Experience: Advanced
Platform: My Own System
Broker: Optimus
Trading: Emini (ES, YM, NQ, ect.)
Posts: 408 since Jan 2015
Thanks Given: 90
Thanks Received: 1,147

I have been optimizing my algorythm for a while to increase my performance in some of these areas. While I can't speak to TT, I can speak to NinjaTrader and you may see some paralells. I will give you some examples of latency improvements I have made with my code over time.

Tips:
1. Always put your execution related code blocks near the top. Or in separate subroutines that will get triggered near the top of your code. In my case I had around 5,000 lines of code and all my execution related lines were mixed with analytical / reporting related lines. So by optimizing this, my execution speed increased ten fold.

2. Ninjatrader has a few different ways you can quantify if you got filled or not. After doing a few optimizing rounds I quickly figured out that OnOrder Update front runs OnPositionUpdate. So if you wait until you get a confirmation that you are long or short, you will likely be losing 25, 50, 100 milliseconds. But if you can code your own logic to derive what you need using OnOrderUpdate, there you go....

3. In terms of the order logic, just to point it out. I always work multiple positions at the same time. Some short, some long. When one of them gets filled, then I place my exits positions accordingly. The worse latency I ever hit live trading (with my optimized code) was around 300 Milliseconds, and 200 of this was due to the broker which usually has 0 lag. It was a rare event where 3 price levels broke by a single huge market order... But usually I can get between 0 and 25 Milliseconds submitting any order.

4. Execution speed is usually not the issue though (assuming you are co-locating and have decent code) The biggest obstacle for me and I assume everyone is that retail trading platforms can lag badly handling the market data feeds. For example Ninjatraders level 1 feed OnMarketData can actually lag as much as 1 to 2 seconds behind calling GetCurrentAsk / GetCurrentBid from the OnBarUpdate event handler sometimes. So you have to test your calls to level 1, level 2 and your Bar updates and see what the latency map looks like. I think all retail platforms will lag at times with each feed. So my nightmare workaround was to program some logic to figure out which feed was lagging and which feed was front running the others, and this flips all the time. So this was the more disappointing workaround I had to deal with.

5. Reporting is fairly useful. I don't claim that the time stamps are 100% accurate, but I think that if I can make a round trip to and from the exchange and use my server clock to stamp it both ways, then if anything I am understating not overstating the speed... But I do reporting on every order (entries, exits, cancels, etc.) and measure my full chain from platform > Broker > Exchange > Confirmed. So I can see where I hit any latency. I think everyone should start here just to see where they have weakness, otherwise they might have overlooked something obvious and easy to solve for.


Just a few ideas, maybe not directly related, but hopefully somewhat useful....

Ian

In the analytical world there is no such thing as art, there is only the science you know and the science you don't know. Characterizing the science you don't know as "art" is a fools game.
Visit my NexusFi Trade Journal Reply With Quote
Thanked by:
  #6 (permalink)
 
xplorer's Avatar
 xplorer 
London UK
Site Moderator
 
Experience: Beginner
Platform: CQG
Broker: S5
Trading: Futures
Posts: 5,945 since Sep 2015
Thanks Given: 15,447
Thanks Received: 15,292

Thanks @iantg, have you experienced how that works with market spikes?

Started this thread Reply With Quote
  #7 (permalink)
 iantg 
charlotte nc
 
Experience: Advanced
Platform: My Own System
Broker: Optimus
Trading: Emini (ES, YM, NQ, ect.)
Posts: 408 since Jan 2015
Thanks Given: 90
Thanks Received: 1,147

Yeah, as far as market spikes go.... About the worst I personally ever got caught in was a sequence where a few price levels broke at once (large market order) 5 ticks above my limit order and the market rapidly started panicking. Everyone on my side was canceling trying to get out of the way, the limit order queue got really thin, and another large market order hit and cleared 2 levels at once including my level. Then as the market continued against my position I tried to scratch, (Missed it), then tried a passive exit for a 1 tick loss, (missed it), then tried a passive exit for a 2 tick loss (missed it), then it finally hit my emergency 3 tick loss across the spread.

I didn't mention this before but the way that I solve for these types of worse case scenarios: For every order I submit that fills, as soon as it fills I submit an emergency exit 3 ticks out across the spread. But I typically try to scratch, or go for a 1 or 2 tick loss gaining the spread. The emergency exit is kind of a worse case scenario.

I am actually a snail in the high speed world, but as a reference I can typically make my round trip in 10 milliseconds or less. So once I confirm I was filled (call it 10 ms to get the message back to me), then I send my 3 tick emergency exit (+ another 10 MS) that puts me at usually < 20 MS. But I have had cases where I hit 50 MS or 100 MS even. The market can do a lot of damage in 100 MS, but it won't typically take out 3 price levels in < 10 MS.

Granted I am still in the testing / optimizing phase of my strategy but I haven't ever missed an emergency exit yet. I also have logic in my code that If I ever do miss it, I make use of marketable limit orders. I layer in 3 more exit attempts at 1, 2, and 3 ticks from my new current position. I don't anticipating needing this, but it's are in my code nonetheless.

As you can imagine the real fun is that I am using unmanaged code and have to handle every possible permutation of canceling logic by analyzing every open position, filled position, in connection with the current price level to figure out which orders to cancel, which are still in play, etc. It get's nuts.... That is why I have > 5,000 lines of code mostly.

Ian




xplorer View Post
Thanks @iantg, have you experienced how that works with market spikes?


In the analytical world there is no such thing as art, there is only the science you know and the science you don't know. Characterizing the science you don't know as "art" is a fools game.
Visit my NexusFi Trade Journal Reply With Quote
Thanked by:
  #8 (permalink)
 
DavidHP's Avatar
 DavidHP 
Isla Mujeres, MX
Legendary Market Wizard
 
Experience: Advanced
Platform: NinjaTrader
Broker: Ninjatrader / Optimus Futures / AmpFutures
Trading: ES / 6E / 6B / CL
Frequency: Every few days
Duration: Minutes
Posts: 1,609 since Aug 2009
Thanks Given: 11,328
Thanks Received: 2,743

This happened to me today on CL.
I have never had this occur in my strategy but today it did.

The order was triggered and then the market moved above my stop (was a short trade) before the stop could be filled and was rejected.

I am using a strategy that triggers an ATM (built into Ninjatrader) so it should have be the fastest possible fill and stop execution available. I will review the trade today and see what can be done. It is a very unusual for this to occur in this strategy. I have tested it live and in sim running at 500 speed and never had this happen on this strategy.

I assume that a large order took all of the available contracts above my entry so my stop could not be filled without the NT error that popped up and closed the strategy. But things like this are why I NEVER let my strategy run without me sitting there watching.

I was fortunate to be able to exit manually gracefully with only a small loss that was recovered on the next series.

Rejoice in the Thunderstorms of Life . . .
Knowing it's not about Clouds or Wind. . .
But Learning to Dance in the Rain ! ! !
Follow me on Twitter Reply With Quote
Thanked by:
  #9 (permalink)
 
xplorer's Avatar
 xplorer 
London UK
Site Moderator
 
Experience: Beginner
Platform: CQG
Broker: S5
Trading: Futures
Posts: 5,945 since Sep 2015
Thanks Given: 15,447
Thanks Received: 15,292


DavidHP View Post

I am using a strategy that triggers an ATM (built into Ninjatrader) so it should have be the fastest possible fill and stop execution available. I will review the trade today and see what can be done. It is a very unusual for this to occur in this strategy. I have tested it live and in sim running at 500 speed and never had this happen on this strategy.

I assume that a large order took all of the available contracts above my entry so my stop could not be filled without the NT error that popped up and closed the strategy. But things like this are why I NEVER let my strategy run without me sitting there watching.

Thanks David for sharing your experience.

Firstly, I agree that it should be something quite unusual, but in the last 2-3 weeks it happened twice already to me and now it happened to you. I wonder whether something changed either in the way orders are handled or perhaps there's some new player in CL which is sending order bursts and causing this.

By the way, what I described in my first post I experienced with CQG. When I replayed the same trade on NT I had no issues, the limit order was triggered (at a better price than where I had placed it) and then I was stopped out with some relatively minimal slippage. I don't think Replay is designed so that it could mimick such extreme events.

I keep going back to latency though. Depending on how NT handles this, there is going to be a delay between when the first order is triggered and when the ATM triggers the stop, which is why I am thinking that, if this behaviour becomes more frequent, it's probably better to put orders and stops in the market manually to avoid ugly losses.

Started this thread Reply With Quote
Thanked by:
  #10 (permalink)
 
SMCJB's Avatar
 SMCJB 
Houston TX
Legendary Market Wizard
 
Experience: Advanced
Platform: TT and Stellar
Broker: Advantage Futures
Trading: Primarily Energy but also a little Equities, Fixed Income, Metals and Crypto.
Frequency: Many times daily
Duration: Never
Posts: 5,041 since Dec 2013
Thanks Given: 4,375
Thanks Received: 10,192



DavidHP View Post
This happened to me today on CL.

While ride in CL today

Reply With Quote
Thanked by:




Last Updated on August 1, 2018


© 2024 NexusFi™, s.a., All Rights Reserved.
Av Ricardo J. Alfaro, Century Tower, Panama City, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada)
All information is for educational use only and is not investment advice. There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
About Us - Contact Us - Site Rules, Acceptable Use, and Terms and Conditions - Privacy Policy - Downloads - Top
no new posts