Randy,

Just letting you know I think you are right to be concerned. I've noticed this funkiness from time to time with Q's reported results. It is enough to make me nervous about relying on the reports but not enough to keep me from using the system. I've checked the actual buys/sells on active trading with the actual prices at that time and these jive.

Back to your problem. I see a fill for 41 shares on May 4th, yet 43 shares are showing held currently. Did this account previously hold 2 shares ?

Click on the "order and fills" status button and see at what price you got filled. Then go to IB side and see if that is the same.

I'll be very curious to see how Q support responds to this question. It does appear there's a bug loose there.

Hi Serge,

I'm using Quantopian's paper trading method. I don't have it linked to an interactive brokers account yet. I didn't notice the discrepancy of the 43 and 41 shares until you pointed it out. Could Quantopian's paper trading be modeling partial fills perhaps? The algorithm just did an order target percent of 100% allocation to SPY.

I'm starting to think I may need to switch over to IB's paper account for a more accurate picture but at this time I don't have the required funds to open one as I don't think they let you open paper accounts without a funded brokerage account.

Thanks,

Randy

Yeah, IB will probably want a funded account before giving you a paper trading one. Good luck with that. If you do finally figure out what happened, please post it to this forum so we can all learn from the answer.

Good luck and be patient. I've been with Q for 1.5 years now and am very impressed with overall setup.

I've been unable to replicate the bug where I've had differing positions from the fills. It's concerning to me such a bug is lurking in their codebase. So far support has been absolutely worthless in tracking it down. :(

Apparently their live trading is not really live trading. In my algorithm I'm using fetch_csv and the rep said this - "Every day after the markets close, paper trading and live trading algorithms are shut down. Every morning, algorithms are re-simulated for a period spanning the first day which it was live traded to the current day. This resimulation is used to regain the state from the previous day's close. If there are any changes to the data retrieved via Fetcher from any of the previous live trading days, the re-simulated state will not be correct and your positions and orders tables could diverge."

So their "paper" trading is bogus! It's nothing more than a fancy backtest. They're creating positions out of thin air!

Randy, I think there was a bit of a misunderstanding here. I just sent you a new explanation of the behavior that I will also share it here, so that anyone else facing this problem can get a better idea of what's going on under the hood.

In live, broker-backed trading, your positions and order history are read directly from the broker. As you place orders, they are sent to the broker. Each night, live servers and paper trading servers are shut down. Every morning the servers boot back up and your algorithm 'warms up' by reading the positions and order history directly from your brokerage account. However, the state of your algorithm, including variables, models, etc. are re-simulated. This is done because live servers do not persist overnight. One of the reasons we do this is that we sometimes push software changes that can not be done while live servers are running.

In paper trading, the same process occurs, only there is no brokerage account to read positions and orders from. The re-simulation step is used to re-gain the 'state' of the algorithm including variables, models, positions, etc. each morning. The order history is not retrieved this way, it is instead recorded as you see on your dashboard. One of the limitations of Fetcher is that none of the data in the CSV file with a date in the past can be removed, added, or changed or it will cause a divergence between the re-simulated state and the live sessions. This behavior is simply not supported on Quantopian.

The graph you see on your live dashboard is not a part of the re-simulation. Each day, only the new day's activity (including P&L and orders) is generated from the live algo. The re-simulation simply allows the algorithm to re-gain its state every morning when the server boots up. In the screenshot you shared, the big jumps at the start of each trading day highlight the divergence between the re-simulated state and the current day.

I hope this helps.

Jamie,

So you're telling me you're taking a shortcut and instead of keeping track of actual positions in the paper trading simulation like a real broker would, you just "resimulate" it every day? Your paper trading should act just like a broker. Each day it should feed the algorithm with it's actual position, not some theoretical position based on the "re-simulation." step it does. Paper trading needs to be as close to paper trading as a broker as reasonably as possible, including P&L tracking.

I guess that leaves me to needing to rely on Interactive Brokers's paper account if I'm going to do any out of band testing with Quantopian. I'm incredibly frustrated by this.

Randy,

I don't mean to discourage you further, but I would not rely too heavily on IB's paper trading either. I am NOT speaking from experience, although I have paper traded with them, but I never matched their results with live results. What I fear is that IB will not have Q's assumption (in my opinion correct for most stocks but not heavily traded etf's) that large purchase orders can move prices. So if you are running it against SPY, that's not an issue, but if you are buing stocks in the smallcap range, it could have more of an effect.

That said, I agree with you that Q should change their procedures to record purchases and sales and maintain state overnight on the simulated side.

Nothing really matches live trading - even if it is with a small amount of money. That of course increases fees a bit proportionally at IB, but depending on your strategy that might be insignificant. Plus, if your algo makes money with little capital, you're likely to pleasantly surprised when you throw more money at it.

Good luck
Serge

It's pretty reasonable, Quantopian can't prevent you from making unrealistic algorithms. It's up to you to make sure your code follows leverage and other broker restrictions. Fetch CSV is a known bad actor and I think quantopian only provides it as a curtesy to traders who use their own data but they make no claims that you can't introduce future bias or edited data streams that will fake out a backtest.

What I'm trying to say is that paper trading on quantopian isn't paper trading because quantopian is not a broker! A paper trade on quantopian is just a backtest running in real time because Quantopian can't know what orders your broker would execute in real life. They just provide an environment to create, store, test, and implement your code.