Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Thank you again for following up with me and providing me with this information.
As you can imagine I am not quite to the point where I have enough capital to bypass broker risk. But I appreciate you providing me with the ballpark figures, so if and when I ever get to that point..... But regarding just developing my own trading platform as an alternative to NT. Let's assume all other variables are constant: (I still go through broker risk, I still have my same proximity hosting) what do you think my speed improvement would be just by dropping NT and going full custom? Is this going from 10 MS down to 2 or 3 MS? And in your opinion would this get me close enough to matter considering:
I still have to hit broker risk
and considering I won't be plugging directly into the exchange any time soon. (Proximity hosting is all I can likely do for now.)
One final question regarding the chain from Application > Data provider > Broker Risk > Exchange. Is there any scenario where one can bypass broker risk due to the specific type of action they are taking. For example I know that an initial order submitted will have to hit broker risk, but I have seen some posts on this forum that seem to suggest there may be cases of amending actions that may bypass broker risk. For example would any of these actions be able to bypass broker risk?
1. Amending an order by changing quantity
2. Amending an order by changing the price
3. Canceling an order
You may think it's strange that I even asked the question about canceling after a level change, and even though it seems obvious that this is not possible, this is something that I can do with nearly a 100% success rate running NinjaTrader in SIM / Market Replay. I raised this issue with them and even submitted this as a bug, but they kind of dodged my line of questioning around characterizing this as a bug. Here is the thread where I raised my concern and they largely dismissed it. https://forum.ninjatrader.com/showthread.php?p=530462 What this implies is that anyone taking one of those Combine SIMs from TST or any similar company using NT, could completely game the testing as this is a fairly significant exploit.
Regarding the time stamps, I think I will take your advice and just build my own logic to further measure this. I can write some code in my strategy to measure my local clock as it passes from > Cancel Submitted > Canceled.
I think this should be about it as far as any remaining questions I had.
Thanks for taking the time to field my questions.
Depends on your coding ability. My first dry attempt with other people involved, no optimization (e.g. zero prior benchmarking, no core pinning, some allocations because we had no time to plug our own custom data structure), was <50 mics when we placed our first trade on that system. My second dry attempt with fewer people involved, no optimization was <100 mics when we placed our first trade. My third dry attempt alone, no optimization, was <300 mics on the first trade. The day one latencies actually got slower over time because we became more intelligent about what we actually needed for day one. Our FPGA platform is <1 mic but our slowest setup and venue is about <300 mics.
Main recommendations are to take a minimum viable product (MVP) mindset and plan thoroughly before executing. We spent >90% of the time planning and designing on the white board.
Your order goes through a different code path depending on the action you're taking. It depends on the exact implementation but it's possible. However this is not a high impact optimization at your stage.
The trickier situation arises when you support different teams, some of which deal with customer flow, who go through the same internalization engine as they might have a lot more heterogenous risk in such a situation.
Trading: Primarily Energy but also a little Equities, Fixed Income, Metals and Crypto.
Frequency: Many times daily
Duration: Never
Posts: 5,057 since Dec 2013
Thanks Given: 4,409
Thanks Received: 10,225
I'd take @artemiso's opinion over mine, but I'm one of those people that was under the impression that modifying the price of an order didnt involve a credit check, but increasing the quantity does.
I don't think NinjaTrader_RyanS understands what you are talking about, and doesn't understand market dynamics. I thought you outlined the issue quite well, but he just doesn't get it. Position in queue is important if only part of the order book is traded out, but with a 'level change' as you call it, it doesn't matter where in the queue you were, you got filled.
SMCJB, Exactly! I don't think they get it either, or see the implications of this. I put it out there mostly as a courtesy to them, and to see if they were aware of it. I honestly don't think they view this as a serious exploit, but it is. It doesn't seem logical at all that this should work in the real market, and I have never got it to work in the real market... I had to ask on here to see if anyone else had got it to work... Long story short, i'ts fiction. That being said, If someone wanted to crush one of those TST combines by cheating they easily could. Here is the code:
All you do is just run this on either OnMarketData, or OnMarketDepth. Pass a variable for your original entry price as fillask and every time a price level changes just cancel. (Opposite logic for longs obviously ). It lets you do this around 90% or more of the time. This implies that you will never catch bad entries because you can just cancel right as the market is taking out your level and dropping you down -1 tick.
I took one of my existing strategies that works fairly well, and slapped the above mentioned cancellation logic and it inflates it by around 20% - 30%.
This is not something I knew anything about until I read your post above and looked it up. But for TST with NinjaTrader, one connects to Rithmic's "paper trading" servers as a broker service. TST doesn't rely on the NT Sim engine or any desktop platform simulator for fills.
ocpb, Cool, thanks for clarifying this point. I never traded with TST, but I was aware that they used NT to some capacity for their evaluations. I still think you could likely use this hack with just about any SIM though, as most SIM's won't consider an order filled until they have a certain confirmation signal. On price pass-through type of fills such as this scenario, you will typically see a SIM engine confirm that a new price level has been created first, and then react to it. Some will even bake in a latency to simulate pinging the exchange one round trip. If you run your cancel on an event handler like OnMarketData, or OnMarketDepth you can get your cancellation out before they validate the fill.
I would be very curious to see how many SIMs, and which one this hack could beat.
I hesitate to make a definitive statement here because it's very implementation-specific but I can explain why it's not high impact optimization.
1. Credit checks should be very cheap for you guys, I know because we didn't have to worry about that on the first pass. There's maybe a couple of pointer hops to look up state by asset and account, then a few arithmetic instructions and potential branch misprediction.
2. Some vendors will set up their risk checks in a way you'll have to pass through that code path or at least check that conditional branch even if it's a modify. If your venue has a MIFID II/15c3-5 mandate I've seen sometimes they rather check something redundantly even if it's not necessary from a coding/logic perspective.
3. For CME you don't actually need to do it because it can take place on exchange side so it's 'free' at least because your order gets enqueued by the matching engine before it carries out credit checks. So credit checks only matter if your broker has another layer for stricter risk on top of that.