That's correct. Many platforms have that problem. It's not necessarily their fault per se. It's just in the nature of using bar data to simulate real time trading. Unfortunately, the highs and lows of each bar require 3 prices rather than only one that you have at the top and bottom of the humble bar. In real life, each high or low has a 3 prices--bid, ask, last trade.
So stop or limit orders that happen to occur near the high or low of a bar in historical may never get filled in real life because one or the other of bid or ask prices either never made it that far or went further. What is more, some trades will appear in real time trading near the highs or lows that never occurred in historical.
So the fundamental issue is that bar data is forced to pick one of the 3 prices at the high. Ordinarily, the last trade price for highs lows, open and close gets used. But that's only 1/3 of the market picture and bid or ask nearly always go farther than the last trade price--sometimes by a wide margin. So, again, you will have entire trades that appear in historical but not it real time and vice versa. It's really painful if you ever try it.
Surprisingly, some traders eventually figure out how to make money even with this appalling situation. They may cease using historical testing altogether and do only forward testing but that's very dangerous way to find programming errors in your strategy rules. You'll hear horror stories that happen on occasion due to typos in their strategies. The other was is to test ideas historically but trade them manually in real life so as to force trades to more closely match historical.
Another solution is to use tick data. But Ami, I'm told, only supports bar data. The only way to use tick in Ami is to feed a single tick and treat it as a bar with the ask as the high, bid as the low, open/close as the trade, etc. But that's doesn't come close to solving the real issue. Plus it performs far worse for an equivalent period of time due to the extremely high number of bars.
There's another platform, more expensive, mentioned on this thread which solves all these problems in one of several differents ways for the user to select by having all the following very essential features for true mechanical "beta" extraction:
1. It accepts multiple data input types and granularities all based on tick data--even bar data gets treated like tick data as you will see below.
2. Of course, feeding full tick data to the platform gives the most accurate simulation. Then it generates bar data on the fly and gives you extremely accurate entries and exits that match perfectly real time trading going forward.
3. Another option it supports is to use full tick data to generate bar data but with complete bid/ask/last prices for each of the open/high/low/and close. That means that each bar contains a total of 12 prices associated with it instead of only 4 OHLC. This runs faster that full tick data and about the same as Ami for the same amount of bars. Plus, it assures that the number and timing of trades match real time going forward. Still, since it has to simulate the intrabar data so you get some fill prices with more slippage. People who have tick data like this option to operate at bar data speeds with acceptable forward trading simulation.
NOTE:
The above 2 options require the user to have or purchase tick data whereas the next 2 allow using ordinary bar data with some trade offs to still get accurate forward trading that matches historical.
4. Additionally, the platform allows you to use ordinary OHLC data to convert to tick data as in 3 above but the Bid/Ask/Last prices for each tick hold the same price. A different feature must be enabled to solve the problem because this choice leaves you with only 4 prices per bar which is too little in other platforms for good real time trade simulation. Still, along with the next feature, this solution has been found to allow accurate forward trading that matches historical...
5. This platform offers 2 choices for handling orders in real time trading. Of course, you have the option of sending limit, stop, and such orders to the broker/exchange, but the platform also allows holding them by the platform and treating them synthetically so that the platform internally watches the real time market and fills the limit and stops with market orders.
6. How does the above solve the fundamental problem? Well on more features is needed to complete the picture. The platform allows you to select which price(s) in the real time tick to watch to fill orders. In this case, you must tell it to watch only the last trade price for filling orders. Since that's the only price used to build the bars, you ignore bid & ask during real time trading. That allows the real time trades to produce the same results going forward as historically on bar data. That solution works exceedingly well on very liquid markets without any manual intervention.
However you choose to do it, it's absolutely critical that you find a way to make your forward trading match your historical testing even if you must do it manually to save on software licenses. That's the only way to build any confidence that strategies you build and test historically will ever work in real life.
This whole issue is, by the way, only one of several reasons why so many people on these ET forums have forsaken historical testing altogether. But technology is bringing a solution.
By the way, there are at least 2 other major reasons why historical testing is extremely hard. That platform solves those also making forward testing and trading of historical developed trading closer to a science than a "black art".
And all of that is possible only because the platform in question eats tick data for lunch. Those solutions are impossible on platforms that can't handle tick data to begin with.
Again, as mentioned earlier there's only one platform that makes it possible to historical and mechanical forward trade reliably for smooth beta extraction with a winning trading idea.
