# Grid Trading System Robot (GTSbot): A Novel Mathematical Algorithm for Trading FX Market
## 3 GTSbot: The Proposed Pipeline
### GTShot: Grid System Manager Block  
The aim of this block was to open a grid-trading scheme according to the predicted trend as per the algorithm inside the previously described TCB. As already stated, if the trend predicted was null, the system would not perform any operations. The grid system manager (GSM) block performed a long operation if the TCB estimated the long trend while it performed a short operation if the TCB estimated a short trend. In the first case, we bought the FX cross, while in the second case we decided to perform a short selling of the FX currency. The FX market price at which the GSM performed the operation was the available open currency price. Anyway the GSM block performed the specified operation if and only if the grid condition was also verified. The grid condition represented the additional constraint in  
Figure 4: The trend classification block: An instance of trend prediction (EUR/USD, January 2018). the GSM block we had designed to build a robust and effective trading framework for the proposed pipeline. According to the trend estimation from TCB, the GSM block performed a careful check of the current status of the trading activities. Figure 5 shows the workflow followed by the GSM block. The first target of the GSM block was a further deep analysis of the estimated trend made by TCB. If TCB returned the null trend, the GSM block workflow jumped to \"No Operations\" waiting for the next prediction made by the GSM block. Otherwise, if the long or short trend was detected by TCB, the GSM algorithm checked the overall number of opened operations in the current grid trading system. During the trading activities, a maximum number of operations (long and short) was defined, according to the available investment fund in our trading account. Consequently, the GSM block checked if the maximum number of operations was reached and it proceeded with the next check on the workflow, i.e., the grid distance. Obviously, if the system had already opened all the allowed operations, the GSM algorithm jumped to \"No operations\". Instead, in case the maximum number of operations had not been reached in both the long and short trades, the GSM workflow checked the grid distance constraint, i.e., the minimum distance in number of samples (abscissa axis of the Figure 3) and in the currency price with respect to all opened trades with the same direction. Basically, the GSM block will open a trade (long or short) if and only if the x-distance and y-distance between the current FX cross price at which we want to open the trade and all the corresponding x-values and y-values we still had for each opened trades (with the same direction) was greater than the x-threshold and y-threshold we had defined in our GSM block. Figure 6 reports the described pipeline. From the representation shown in Figure 6 we can better understand the working flow of the GSM block. In the detail of the financial time-series explored in Figure 6, the already opened operation was identified by the green circle. During the normal trading activity, the proposed algorithm proposed the opening of another long position represented by the red circle reported in Figure 6. However, the GSM block discarded this proposal as they were not respecting the grid conditions both in reference  
Figure 5: The grid system manager (GSM) block: The workflow. to the abscissa axis (distance x1) and in relation to the price value (distance y1) as they were both considerably below the pre-set thresholds. On the other hand, the subsequent proposal to open another long position (blue circle) was granted by the GSM block because it respected both the conditions relative to the grid distance with respect to the position already open (distance x2) and the condition relating to the distance of the price value (distance y2).