Just using Trading Technologies orders. The basic plan has them. If what I'm trying to do works ill probs jazz it up a bit in ADL.
This was recently discussed here - https://www.elitetrader.com/et/thre...my-order-sitting-at-nbbo.346847/#post-5139907 Older - https://www.elitetrader.com/et/threads/order-efficiency-ratio-at-ib.309340/ There are some strats here as well to consider on IB - https://ibkr.info/node/1765
This approach involves two actions: first the cancellation, followed by the placement of a new order. If you were to modify the existing order (change the limit price) this would only require one action. And thus is it faster. Is there a specific reason why you want to cancel and replace?
Depends on the venue and your connectivity (DMA vs non-DMA). There's usually 2 independent limits that apply to a DMA participant - which includes your broker - a message-to-execution ratio and a per port limit. With DMA: I'm overgeneralizing but on the markets I have familiarity with, you're probably safe everywhere around the 5:1 to 30:1 message-to-execution ratio on any given day, with some prior intraday warning if you're at risk of exceeding it. This usually comes in the form of an email from venue to you in DMA or venue to clearing firm/PB that gets forwarded to you. It may be counterintuitive to you but you will find that most markets' rules are defined in a way that technically give a retail trader with low volume an unlimited order-to-execution ratio, as they're more concerned with high volume, non-display traders. (I will explain below why it's not actually unlimited in practice.) The per port limit is measured over a sliding window, usually 1s to 5s, that regulates how much you can burst your messaging traffic during that window. You're generally safe just under 100 per second there. The per port limit is usually a worse issue than the execution ratio limit. Exceeding the port limit will often kill off your connection until human action and likely leave you stuck in position, whereas the execution ratio gives you a graceful window to rectify the issue and even then it just incurs a fine if you violate it at EOD. For non-DMA, i.e. if your traffic goes through your broker's stack, these 2 limits still exist under the hood, but your broker simply has a way to abstract their consequences away from you, using whatever throttling or even tighter rate limit defined within their execution stack. To understand this: Here, you're likely sharing a port with many other traders, and these ports can be anywhere from free to a few grand a month for a broker. If you're not giving your broker a few hundred per month of revenue, chances are that they've found some way to amortize this expense over many customers. This means that implicitly a broker will try to load balance across their ports and throttle your orders with arbitrary limits that give them a margin of safety under the venue-defined limits. The mechanism is usually quite rudimentary - like, take those numbers I gave you and divided by n on each subaccount. I've worked with the same header files used on pre-trade execution stacks of a few fairly large brokers (GS, UBS, BAML, Jefferies) and you'll be surprised these limits are usually just encoded as 1-2 numbers persisted on a single host Postgres. So the DMA numbers I cited will be just upper bounds, and the only way you'll really know is to ask your broker. This is absolutely reasonable so long as you had the intention of filling those orders, even if just for microseconds.
You are correct, I would only need to modify the existing order. I'm just beginning to learn about these things and proper terminology, and this detail was not entirely clear to me.