Search results

For now, log as a defect, and fix later. In the short term, market on reject implemented locally. But, somehow... I'd like this logic sitting server side. RTrader's market on reject logic appears to be implemented locally, and that has a risk associated with it. Haven't put much thought into...

Greg, Thank you! I'm using R|Api, not R-Trader, so I can't do that exactly, but will end up implementing something similar in my own software.

Thanks for your reply. Couple of things: 1) I'm using a a 100% custom/self-developed software stack, and its only recently been put online. Risk is intentionally kept low so I can find issues like this, and not pay a massive price for it. I only trade maybe an hour or so a day while I can...

Code worked exactly as designed. But, bad design on my part to not handle this. I never expected a stop order that was sitting server side to be rejected. Stupid, but mistakes are part of every development process.

Thats my goal, but I'm not in a place where I can justify the increased fixed-cost...Someday soon, hopefully.

I used to handle the bracket fully on my machine with my software, but decided it was safer to rest thing on a larger entitites server (rithmics), as they are more robust to power/network outages than I am.

There are stop-orders for futures: Stop Order Notes The stop order's trigger price is validated differently depending on the market state. During the Continuous market state, a Buy stop order must be > last trade price and a Sell stop order must be < last trade price. Absent a last trade...

Yes...this has all been discussed and acknowledged. My assumption was that since the market was below my stop trigger that it would have simply been treated as a market order...this proved to be false.

You're misunderstanding. Do you know what a bracket order is?

Nah, I'd prefer this to low vol. Just gotta recalibrate myself for the new normal

Note that this was NOT slippage, as the stop order was rejected by the exchange. It wasnt necessarily a platform error either.... I'm the trader and the platform programmer... so either way, the fault is my own. I misunderstood how a stop order would be handled in a fast market.... but... I...

Timestamps below are in seconds since beginning of epoch (local machine time..my latency to rithmic appears to be about 30ms... I'm in Arizona): OMS Traffic: 1517933323.066: Bracketed Limit Buy to Open order send at price $6480.00 (target and stop rest on Rithmic) 1517933323.137: Limit Buy...

As previously stated: stop market

Yeah, just quirk/oversight on my part. Googling around, other people have had similar issues with ninja trader. I'll look at my timestamps more thoroughly later, and post here

100% custom combination of c++ and python. I use Rithmic API for data and execution.

To be clear, I attempted to place a stop market, not stop limit. Issue was the trigger price was below the market at the time it hit the exchange (within ms of open fill). Not sure if this was a Rithmic reject, or a cme rejected...but I'll find out.

Yup, it was automated, and I was watching fortunately. I only run when watching. I would have been okay if I wasn't, as my target would have eventually been hit...but my stop was supposed to be 2 ticks...and I went as low as 80, within seconds. Completely my fault, but I learned something...

Correct, and I got a reject message to inform me of such....but, like a fool, I didn't plan for this situation and was left unhedged for a bit.

I think the stop rests on rithmics servers, until the open is filled. If the burst that filled the open took the market down through where the stop is supposed to be(which is what I believe happened), the stop never would get a chance to rest on the exg. Can't rest the stop prior to the open...

What do you mean? I entered a bracket order, got filled on opening leg, but the the market blew through where my stop would have been before it hit the exchange. I assumed I would just get a market order in this situation, but rithmic or cme rejected the stop