In paper trading when i submit an order sometimes it takes several minutes to get the ‘new order’ update. In the meantime if i try to replace a stop in the submitted order, it fails with ‘order not yet submitted to exchange’. Does this minutes-long delay between order submission on my end and order acknowledgment/activation on the Alpaca end happen often for live trading as well?
I’m having the same issue any info on the subject? Thanks!
Hey everyone!
The best way to think about Paper trading is that it always assumes the worst-case scenario - so a bit of delay isn’t unheard of with Paper, especially at market open.
That being said, I can certainly look at specific orders and give some more context. @urania or @max21ge – do either of you have some order IDs I can pull up?
Thank you so much for your answer! Here is an example of a trade that we’ve placed as a test. My main question is what is “updated” status vs “filled” that shows up 41s after beeing filled. We’re currently testing the API for day-trading quant strategies sent from our own software and we need to receive all info regarding trades simultaneously (or a couple 1/10s max) so if we need to wait seconds to get an update on a trade that will not work for us.
2352680c-916c-4216-aba0-367103f0886c
Submitted At2021-10-05T13:32:21.022987Z
Created At2021-10-05T13:32:21.028711Z
Filled At2021-10-05T13:32:21.238692Z
Updated At2021-10-05T13:33:02.628754Z
Hi @max21ge and everyone else on this thread. I know this is really late but I have the same question and I’m wondering if either of you got closure as to what the delay between “filled at” and “updated at” means? Does that mean alpaca hasn’t updated the order status to filled between those two times? So if I call the api to retrieve the order status it will still not return filled even though it has been until the “updated at” time passes? That was my guess as to what that means but if it means something else I’d love to find out.
March 2024 still having issues with paper trading. 9minutes between submitted and filled.
Don’t expect people to put real money if the simulation is broken.
Is anyone really using this? the forum seams quite dead too… not a good sign.
i’m having the same issue on paper with limit orders in high liquidity and low volatility . . . is this representative of live trading?
@Alexander_Lesnick While paper trading tries to mimic live trading quite accurately, there are a few areas where paper trading may have longer execution times. Specifically, paper trading adds random ‘partial fill’ logic. This slows down execution because of multiple fills. In live trading partial fills happen less frequently. Part of the rational for increased partial fills in paper is to ensure one’s algo gets them once in awhile and therefore can be tested to ensure they are handled properly. Otherwise one may never encounter a partial fill. Another, limitation of paper simulations is the fills do not take into account liquidity. A $1M order fills exactly like a $1 order. Realistically, live trading in typical stocks at typical order sizes, one’s order will have no impact on execution price. However, for thinly traded stocks, or those with large spreads that may not be the case.
However, you state “limit orders in high liquidity and low volatility”. Limit orders only fill if the limit price is at or better than the current bid. In other words, buy orders will fill only if the limit price is greater than or equal to the current ask. Sell orders fill only if the limit price is less than or equal to the current bid. That is true in both paper and live trading.
What can create confusion for some traders is they expect limit orders to fill based upon the current price (ie the last trade price). The last price has no impact on if/when an order fills. It all depends upon the quotes. So, what sometimes looks like ‘slow fills’ (ie the price is at my limit price but my order doesn’t fill) is really simply that the limit price isn’t better than the current quote.
If you provide an order number(s) for orders which you feel didn’t fill as expected, I may be able to get more detail.
Thanks for the reply — I appreciate throwing wrenches in paper to ensure robust handling. It has helped me tremendously. However, I suppose my understanding was that if I query the most recent ask price on the optionshistoricaldata client, and execute a limit order on the very next line of code (with no perceptible delay between the two), that the limit sale should go through. I’d even be ok with 50% fill, and I’ve tested my algorithm with a random injection of 1 to 3 second delay, and dropouts. But what I’m seeing is 90% never sell, and those that do have a 30 second or so execution.
Limit buys with this same setup execute immediately.
The limit sells execute immediately at 0.05 above the last queried ask price.
I am setting up the websocket stream now, because the only reasonable assumption I can make is that the historical client is giving me delayed our out of sync data. But the asymmetric behavior of the limit buy and limit sell seems curious to me.
This is my first day on the paper trading, so I’ll try more things tomorrow. Also, reasonably soon I’ll have my brokerage account transferred. Can you briefly explain the advantage in these types of scenarios (say, limit sells), with elite or smart router?
A few things. “The limit sells execute immediately at 0.05 above the last queried ask price.” Sell orders execute at the bid price (not the sell). The bid price is the highest price anyone is willing to pay. Your limit price is the lowest you are willing to sell at. Those need to overlap. So, set your sell limits at or slightly below the bid, and your buy limits at or slightly above the ask. Your order will fill at the quote regardless of your limit price so it’s ok to set it a bit better than the quote.
If you are indeed setting your buys at the ask and your sells at the bid, that is reason for the asymmetric behavior you are seeing. Reverse that and you should see the fills as expected.
thanks, that makes a lot of sense. I think there are still situations where I see market move past my limit. can you help me understand what happened on, say, 200faa0c-7057-49ce-89a5-5033205691ab? thats an order I had to cancel as the price moved past my pendling limit order
@Alexander_Lesnick I looked at your order 200faa0c-7057-49ce-89a5-5033205691ab. It was an option order to sell NVDA240830P00128000 with a limit price of $6.48. It was submitted at 13:16:16:05.807-04:00 and cancelled about two minutes later at 13:16:17:46.240-04:00. That meant $6.48 was the lowest you were willing to sell for.
The current bid at the time the order was submitted was $6.40. The most anyone wanted to pay was $6.40 which is why the order didn’t fill immediately. The bid never rose above your limit during that time (which is why the order didn’t subsequently fill). There were 9 trades reported during the time the order was open (shown below). However, technically only one was a ‘real’ trade with a trade condition “l” which executed at $6.45 below your limit price. The other 8 trades have trade conditions of “a” (transaction previously reported is now to be cancelled) or “f” (transaction is a late report of the opening trade and is out of sequence). Both of those conditions represent updates and not actual trades.
timestamp exchange price size conditions
2024-08-27 13:16:50.037361408-04:00 X 6.47 10 a
2024-08-27 13:17:12.261016064-04:00 C 6.47 1 a
2024-08-27 13:17:12.261016064-04:00 C 6.47 1 a
2024-08-27 13:17:12.261020928-04:00 C 6.47 1 a
2024-08-27 13:17:33.124231168-04:00 M 6.48 3 a
2024-08-27 13:17:34.774584832-04:00 C 6.45 5 I
2024-08-27 13:17:40.140900864-04:00 J 6.46 5 a
2024-08-27 13:17:43.544372480-04:00 X 6.48 10 a
2024-08-27 13:17:43.949352704-04:00 W 6.47 1 f
1 Like