A lot of traders have asked these sort of questions before; but I am darned if I can find my stock response to the problem, so have made this new post which will hopefully incorporate many of the discussions as I remember them...

There are many problems associated with trading on close which are not easily solved using a single application; the problems in data-responsive applications like MetaStock are even harder for many to comprehend, usually through lack of appreciation of the dependencies and inter-operability requirements of computerized systems, software, markets and data, and especially the limitations of time on those factors.

End of Day (EOD)

Let’s start by looking at the end-of-day trader.

Many EOD or overnight traders download their data at the end of the day. By this time, the market is closed, the numbers finalized and no more trading is possible. The market CLOSE price reflected in the data is exactly that, the market is closed; no more trading is done. So how can a trader enter or exit on the CLOSE price of that day? They cannot. Although it possible to write a trading system which "takes" trades at the CLOSE price of the day, in real-life this is not the case. If your system relies on you trading on the close then I suggest you review the rules to reflect what is possible in reality; the next opportunity to trade is on the next trading day at the market OPEN.

There is an exception, actually, it’s more of a modification than an exception; some data vendors provide intraday snapshots of the market which means traders can download their “EOD” data whilst the market is still open and they can “pretend” the data is representative of the entire trading day, when in fact there is still some of the trading day missing from the data. If their trading system signals an entry or an exit, the trader can place their order and (hopefully) it will be filled by the time the market closes. If it does, their trade will be included in the actual market EOD data that can be downloaded after the market closes. These traders cannot see on their data the current price action at the moment they place their orders because their data reflects what was happening at the time the data was compiled. They can use the time of the data snapshot (within reason) to generate trading signals because they know the bar they are looking at is going to be the last bar of the trading day. (Of course, if they download another snapshot, this last bar might change and this might affect the signal generation, but this is a risk the trader takes by choosing to get more data.)

The trader could also look at their wrist-watch or another clock and make the trade as required which would be reflected in the true EOD data. This is using a third-party system for trading decision making, something I shall discuss more later.

Intraday

On many occasions, the intraday trader often does not want to be left holding positions overnight. (IMHO, many traders fly too close to the wind when trying to exit their positions, leaving it until the very last moment to try to close their positions, but that’s another story.) These traders usually want to write systems which generate signals on the last bar of the chart; but here come the problems? How does the system know the current bar on the intraday chart is the last bar of the day?

Let’s pretend you have a system (crystal ball) which says the current bar is the last bar of the day, so the trader exits their open positions. What effect does this have? New trades have entered the market and been executed, and if the time has sufficiently advanced from the time of the chart a new bar is generated; so what was the last bar is no longer the last bar. This paradox cannot be solved using code.

Another scenario then, the trader knows this market closes at 16:00 so a bar on a 1 minute chart with a time of 15:59 is going to be the last bar of the day and IF (I repeat, IF) they can get their trade into the market, it will be incorporated into the data for that bar. This is a possibility if the data vendor time-stamps their data with the opening time of the bar and not the closing time of the bar. The problem for the trader using MS is that MS is responsive to incoming tick data to initiate the computation of indicators and experts. If no tick arrives, there is nothing to start the computational process which leads to the generation of trading signals. E.g. what happens if there is a tick of data received at 15:59:00 on the 1 minute chart? If the computation process and the trade execution time-lag is short, a signal generated on the new tick can be reacted to and the trade placed (and filled?) in the market before it closes; this would generate a new tick which would be received by MS and the trader will feel happy. (This tick could be used by other traders in the generation of their signals too.) If the 15:59:00 tick arrives and the computational process is too long or there is a delay in getting to the order to the market or the market doesn’t want the order, the market will close and the trader will be left holding a position they don’t want (and maybe cannot afford?) and no new tick will be generated for that bar. What if no tick arrives after, say, 15:57?

In order to escape the last scenario in the example above, some traders move their target time to say 5 minutes before the close of the market. This does not alleviate the fact that on the day, there might not be any trades filled at or after 15:55 in which case there is nothing to trigger their system to generate signals to close their positions. I have seen on slow days in some markets there have been no trades in the last 45 minutes of a day, whereas “normally” there are trades at least every minute of the day. How far back is the trader willing to push the "trigger-time"? How does an algorithmic system deal with this scenario? It’s an even longer story.

There are a couple of ways to algorithmically generate signals without relying on data or using forward referencing, but these are not available in the simple charting applications like MS. As MS doesn’t know what the time is, it only knows the time of the last incoming tick, it cannot be programmed to trigger a time based event in real-life. The simplest solution is to use another application to signal or execute the trade at a specific time (or mechanical device, such as an alarm clock!) These trades will cause new ticks to be generated to which MS can respond. In some other applications it is possible to read the computer system clock or data server clock to generate time-based signals, or enter loops to read the time whilst waiting for the next data tick to arrive; as I said these are not options for MS.

System Testing

If the trader has method that will actually allow them to trade at/near the last bar of the day, how do they test their ideas in the EST?

This is one of the few times when forward referencing is allowed: the EST code can look at the datetime of the next bar in the data series and determine whether it is on the same day or the next day. If the datetime is in the next trading period, this means the current bar is the last bar of the period and the appropriate signal can be generated. There is one small hiccup with this approach; on the last bar of the data series, there is no future bar for the Ref() function to do its comparison with so it retuerns N/A, and no trades would ever be signalled on the last charted bar. To avoid this N/A bar, the forum.dll can be utilized in conjunction with Ref() to return a value and this is OR’d with the LastValue(Cum(1)) to detect the last charted bar. Of course, the CLOSE price at which the EST will take the trade is only going to be representative of what trade could have taken place, but close enough might be good enough in this instance?

Note: although we have discussed the trader looking to exit at the close of a day, the same problems apply with any intraday time. E.g. foreign exchange (FX) traders often want to exit their positions, say, 5 minutes before a news event but if no ticks are arriving in the time window then no signal can be generated, etc.

Summary

Like with a lot of trading systems, computers and software, it is possible to code impossible scenarios and show their success in back-testing. It is vital that during the system development process, traders be mindful of the differences between possibility and reality. A lot has been written about the use of indicators such as Peak() , Trough(), Zig(), LastValue() and redrawing trendlines etc, we know to avoid these because they are not tradable in real-life; the same has to be said about time-based systems and systems reliant on trading at/near the close of a trading day.



Hope this helps.



wabbit [:D]