Visualised Algorithmic Trading System for Strategy Prototyping

Transcription

1 Visualised Algorithmic Trading System for Strategy Prototyping 1 Allen Y. Chang, 2 Chia-Han Chou, 3 Chang-Sung Yu 1 Chinese Culture University, zyh3@faculty.pccu.edu.tw 2 Chinese Culture University, ak5511ak5511@gmail.com *3,Corresponding Author National Taiwan University, yucs@ntu.edu.tw Abstract As with any software system development project, the trading strategy generated by technical analysis, has its life cycle. Some only last for a few months, or even only a few days or hours, after when the trading strategy becomes ineffective. We propose a Visualised Algorithmic Trading System (VATS) for designing trading strategies. It provides a visually based tool that allows traders using simple Drag & Draw methods to convert the idea of trading strategy to the program that is ready for execution. At the end of the life cycle of trading strategies, they can easily be modified, updated or deleted. This will enable trading strategies adapt to the rapidly changing market and allow traders generate more profit. This paper presents our experience from the design of VATS and the implications for the design of integrating software engineering technologies in financial applications. Keywords: Algorithmic Trading, Trading Strategy, Visual Programming, UML, XML 1. Introduction According to Greenwich Associates, Inc., more than three-quarters of U.S. institutions and 95% of large institutional traders implement their trading strategies with algorithmic trading (a.k.a. algo trade) technology [1]. The statistical data in Table 1 reveals that from January 3 rd 2011 to July 15 th 2011, on average 30.42% of the trading volume of the New York Stock Exchange comes from program trading. In 1988, program trading accounted for just 10% of the total trading volume of the NYSE. In the foreign exchange market (FX), the volume of electronic trading is over 60% of the total volume, whereas there were only 6% using algo trade in 2010 [2]. The evidence clearly shows that many traders and bankers are looking to one tool that they think will help them better compete: algorithmic trading. Many trading strategies have been developed with very good results [3, 4]. However, as Kim mentioned [5], heuristic algorithms need to react faster than ever before. Kumiega & van Vliet [6] proposed using Excel and VBA as the CASE tool to develop programs for trading strategies. It is relatively simple and fast compared with traditional sequential coding methods. Although VBA is relatively simple, it still requires someone to write the code. For IT programmers, this is not a drawback. However, for most the traders who are not professionally trained in coding, there are still some degrees of difficulty in writing a working program quickly. Table 1. Comparison of average daily volume and the program trading volume of NYSE Average daily Date Average daily volume program trading volume 5/31~6/3 2, /6~6/10 1, /13~6/17 2, /20~6/24 2, , /27~7/1 1, /5~7/8 1, /11~7/15 1, (Source: NYSE [7], Unit: Million USD) Percentage of program trading As with any other software systems, the algorithmic trading strategies within the program trading system have a limited life cycle. It is inevitable to expect to have to modify the system at some point. International Journal of Advancements in Computing Technology(IJACT) Volume5,Number2,January 2013 doi: /ijact.vol5.issue

2 When the system specification cannot satisfy the users requirements, it is possible that the entire system may have to be rebuilt to replace the old one [8]. The same principle can also be applied to the algorithmic trading strategy [9]. A mature algorithmic trading strategy, even having passed rigorous testing, can only last for limited time span. As a strategy cannot include all of the market situations, neither can it respond to all the price changes of the trading instrument. For example, a strategy may make stable profits in a bull market but cannot guarantee to gain the same results in the bear market. Therefore, when the strategy becomes invalid, one should re-examine the algorithmic strategy to ensure that it can maintain stable profitability. If the result of the examination does not meet expectations, then a re-engineering or re-design of the strategy should be considered. The optimisation of a trading system and the modification of a trading strategy require the involvement of IT people. However most IT engineers do not have the financial background, nor do they know trading strategies. Professional traders or fund managers have to develop the strategic rules first and then handover to the IT professionals for program implementation. The problem is that communication between traders and programmers can take quite a large amount of time and system modifications may not be done in time for high frequency trading. Another approach is to use the trading platform with built in script language. Although the syntax of the script language is easier than the traditional procedural programming language, most of the traders do not have an IT background. Writing programs with scripting language may also be too hard for the traders. We would like to propose a visualised strategy-developing tool. Users can simply draw their idea of strategies on the screen [10]. The development tool can convert the graph into executable trading strategy automatically. This strategy can be exported to external trading platforms to conduct rigorous back testing. If the result is positive, the algo strategy can be put into production and start trading in real-time. On the other hand, if the strategy does not work in the testing stage, one can immediately modify or redraw a new strategy quickly. Either way, the visualised algo trade strategy development platform allows users to develop their very own new strategies quickly without writing a single piece of code. For those who do not know how to write computer programs, they can focus on the design of their strategy without worrying about writing the programs. Using this tool, it can take only a few minutes for trading strategy design, to be developed and testing and put into operation. Compared with the traditional white-box algo trade systems, which can take days or months in the software development cycle, our approach has great advantages in rapidly changing markets. 2. Visualised algorithmic trading system architecture In this paper, we use a UML model to construct our visualised algo trade system (VATS) as it has been widely used in both industry and academia [11, 12]. VATS consists of five parts: (1) Visual Interface (VI), (2) Workflow Control Engine (WCE), (3) Script Adaptor (SA), (4) Library and (5) Store Controller (SC). The system architecture is shown in Figure 1. We will describe how the internal details of these parts work in the following sections. Figure 1. VATS architecture. Communication between VI and WCE. 810

3 VI is the place to develop the strategy workflow. It consists of the design area and the toolbox. The toolbox offers a variety of strategy components, connecting lines and control components. Users can simply drag-and-drop them to the design area. Through mutually combining insert, move, delete, link and compile operations to form the visualised algo trade strategy, the workflow is displayed in the design area in graphical form. The generation and control of the trading strategy workflow is closely related to WCE. Figure 1 shows the communication of VI and WCE. VI sends both requests and data to WCE to complete the entire design cycle. WCE is the kernel of VATS. It is responsible for (1) drawing the strategy workflow to VI, (2) storing the content of the workflow and (3) manipulating events. For example, when the user drags a conditional component A to the design area, WCE calls the graphics component to generate a graph representing A. In the meantime, it will generate an object B in the dynamic memory, which inherits the component A. Therefore, object B owns all of the attributes and events of component A. Any movement that the user does on any of the workflow components will trigger an event. When the user double clicks on the graphical component A in the design area, WCE will activate the WindowOpen event of object B based on the input component identifier. A window will then pop up and let the user fill in the logic predicate and store it to the system. In the meantime, WCE will update the content of the logic predicate in the attribute of B. If the user moves graphical component A, the Move event of B will be triggered. The coordinate attribute (x, y) of B will be updated to the new coordinate (x, y ). If A connects to another component C in the workflow, WCE will call the graphics component and redraw a new line connecting to C based on A s new coordinate (x, y ). As a result, if the user moves the workflow component arbitrarily, s/he can see the lines connected to the component become longer, shorter or even tortuous. SA receives the object data from WCE and then compiles the legal programming language for the external algo trade platform. SA mainly performs two jobs: (1) saving the strategy workflow on the screen to an XML file and (2) reading and analysing the XML file and restoring it to workflow on the screen. These functions allow the users to reuse their own strategies. Figure 1 shows the communication between VI and the Library through WCE. The Library component provides system default functions for planning strategies. Users can use pull down menus to select the ones they preferred when setting up the predicates. 3. The workflow control engine As mentioned earlier, the WCE controls the events in workflow operations. Whenever the user inserts a new component, moves or deletes a component, or edits the content of a component it will trigger a series of events. For example, if a user creates a new strategy component the workflow will trigger the CreateComponent event. If a user moves a component to another location, the MoveComponent event is triggered. When an event is triggered, it will also trigger the WCE to call the corresponding Action to handle the corresponding task. These tasks include: (1) create component, (2) create connector, (3) delete component, (4) delete connector, (5) component move control and (6) component content modification. Figure 2. Sequential diagram for: Create component, Create connector 811

4 3.1. Create component The CreateComponent event is triggered when the user drags a component to the design area. The WCE will initiate a series of operations, as shown in Figure 2. First, the user chooses the component s/he would like to add and drags it to the design area. VI will send the relative information to WCE. WCE then creates an object called ObjectCollection and then calls the Add action to create a sub-object called item. It will record the information of the object with corresponding parameters, which includes the unique ID, component type, caption, content, length/width and its (x, y) coordinates. Finally, ObjectCollection calls the Draw action to display the graphical component in the design area of VI Add connector The connector links two components together with arrows to show the user, as well as the system, which to process first. As Figure 2 shows, the entire sequence starts with the user clicking the connector icon in the toolbox. The user then has to pick two components in the design area. The first component will be treated as the from component and the second will be the to. This information will be sent to VI, which then forwards it to the WCE. The WCE will create an object called LineCollection, which calls the Add action to create the item sub-object to record the corresponding connector information, such as FromObj and ToObj. LineCollection will calculate the location of the connector based on the coordinates of the linking objects on the Cartesian plane. Figure 7 shows an example of connecting component C 1 to C 2 below it. LineCollection adds the x-coordinate of the lowerleft corner of C 1 using half of its width as the starting point. The end point will be the x- and y- coordinate of the lower-left corner of C 2 plus half of its width and height. Finally, LineCollection calls the Draw action, which then depicts a line from the first component to the second component with an arrow pointing to the latter Delete component When a component in the workflow is chosen, the user pressing the delete button will trigger the delete event. The WCE will proceed with the following steps, as shown in Figure 3. After receiving the delete instruction, VI sends the Delete message to WCE. The WCE then creates an ObjectCollection object to call the Delete action and then the Draw action to delete the sub-object that stores the component and uses the Draw object to remove the graph of the component in VI, respectively. Figure 3. Sequence diagram of: Delete component, Delete connector Delete connector Figure 3 shows the sequence diagram of deleting a connector. When the user picks two objects in the design area and presses the delete connector button, it will trigger the delete connector event. VI sends both components identifiers to the WCE, which will create a LineCollection to delete the objects connected to the line and then delete the line on the VI. 812

5 3.5. Component movement control A user moving a component triggers the component movement event. In addition to moving the corresponding component to the new location, the WCE will also have to move all of the connectors that link to it. Figure 4 shows that the old coordinate (x, y), the new coordinate (x, y ) and the unique identifier of the component will be recorded by VI, which sends the Move message to the WCE, which will create the LineCollection object to call the Move action. The Move action performs the following: firstly, it uses the component s identifier to find the FromObj in all of the sub-objects that match this identifier and record the coordinates of FromObj and ToObj as (x, y ) and (x 1, y 1 ), respectively. Secondly, it finds the ToObj in all of the sub-objects that match this identifier and records the coordinates of FromObj and ToObj as (x 1, y 1 ) and (x, y ), respectively. Lastly, LineCollection passes the old coordinate (x, y), the new coordinate (x, y ) and (x 1, y 1 ) to the Draw action, which will use (x, y) and (x 1, y 1 ) to remove the old connector and use (x, y ) and (x 1, y 1 ) to draw a new one Component content modification If a user clicks some of the components, such as the Condition component of the user-defined function, this will trigger the Update event and pop-up the content edit window. It allows a user to modify the content of the component. The WCE precedes the modification process, as illustrated in Figure 4. After the VI receives the component that the user would like to change the content of in the workflow, it will record the identifier of the component before letting the user modify it. After the user finishes the modification and presses the confirm button, VI sends the Update message to the WCE and WCE creates the ObjectCollection object and uses the component s identifier as the key to modify the value of Content of the corresponding sub-object. Figure 4. Sequence diagram of: Component movement control, Content modification. 4. Script adaptor Figure 5. Workflow example. Communication of VATS and the external algo trade platform. The strategy prototype generated by VATS needs an external algo trade platform to do the historical back testing to evaluate the performance of the strategy. In our current implementation, we are able to generate scripts for the Home Trading System (HTS), originally developed by the Korea Exchange, 813

6 which is popular in the Taiwan financial market and deeply rooted in most of the brokerage firms in Taiwan. Figure 5 shows the conceptual diagram, which shows that after the script is generated by the WCE; the SA converts the strategy workflow to the script with legal HTS syntax and sends the text file containing the strategy to the HTS. As we will show in our experimental result later, the script can be executed by HTS and generate the strategy performance report. Figure 5 shows an example of converting the workflow to an HTS script. The workflow in the example is the case of nested if. The underlying data structure of this workflow is actually a binary search tree (BST) rooted at the Start component. The SA uses a Depth First Search (DFS) algorithm to conduct pre-order traversal of the BST. The corresponding output of the workflow depends on the order in which the node is visited. In this example, the order of nodes being output by SA is labelled as <A, B, D, G, E, C, F>. This way, we can ensure the content of the components can be arranged to the correct HTS syntax. 5. Store controller Users can store the strategy they have designed as a system file on the disc. It can be used to combine with other strategies to become a more sophisticated trading system. The SC can also include strategies designed by other people. One can customise it to fit special purposes. This is the concept of reuse. The sequence of converting the trading strategy to an XML file is shown in Figure 6. Figure 6. Sequence diagram for SA. Trading strategy can be converted to an XML file. When the user clicks on the Save button, the VI sends a Store message to the WCE. The WCE will then create a SaveXML component and execute the store strategy action. The SaveXML object calls this action to convert the content into XML format based on the strategy XML table and saves it to the user designated location. The strategy XML conversion table is show in Table 2. Node Name <Amount> <block> <Amount> <line> <Item> <line> <Form> <Item> <line> <To> <Item> <line> <Way> <Item> <block> <Id> <Item> <block> < Type> <Item> <block> < Caption> <Item> <block> <Content> <Item> <block> < Height> <Item> <block> <Width> <Item> <block> <X> <Item> <block> <Y> Table 2. Strategy/XML conversion table Description Number of components in the strategy Number of connecting lines Starting component ID of the connecting line Ending component ID of the connecting line Yes or No if logic predicate, blank otherwise Component ID Component type Component caption External script if the component is user defined function. Component height Component width X coordinate of the component Y coordinate of the component 814

7 Figure 7 shows a simple example of how the SC converts a trading strategy workflow to XML. The ovals represent Action(START, END). The rhombus is the logical predicate Condition. The rectangle represents Action(BUY). If signal RSI is greater than 51, the flow of the strategy goes to the direction of Y, which will execute the BUY action. Otherwise, it executes the End action. When the workflow is converted to XML, the number of nodes is saved in the <Amount> node. The sub-node <block> stores the total number of control components and strategy components, while the sub-node <line> stores the number of connectors. In this case, they are 4 and 3, respectively. <Root> <Amount> <block> 4 </block> <line> 3 </line> </Amount> (c) Figure 7. Connector coordinates calculation. Sample trading strategy workflow. (c) XML for the number of objects In the XML code block of Figure 8, the node <Item> stores the attributes of the component. Its child node can be either <line> or <block>. Sub-node <line> stores the attributes of a connector. The <From> node is the head of the connector and the <To> node stores the identifier of the tail of the connector to which it is pointed. If the connector links with predicate component, the <Way> node stores either Y or N, which means the path of the line is Yes or No, respectively. Otherwise, the value of <Way> node is empty. In Figure 8, <block> is also a child node of <item>. It stores the attributes of a control component. In this case, it is the Start component. The <id> stores the unique identifier of the component. <Type> tells us what kind of component is it. <Caption> is the title of the component. <Content> stores the detailed substance of the component, which is empty for the control component. The nodes <Height>, <Width>, <X> and <Y> stores the height, the width and the reference coordinate of such component, respectively. <item> <line> <Form> id1 </Form> <To> id2 </To> <Way></Way> </line> <line> <Form> id2 </Form> <To> id3 </To> <Way> Y </Way> </line> <line> <Form> id2 </Form> <To> id4 </To> <Way> N </Way> </line> <block> <Id> id1 </Id> <Type> Start </Type> <Caption> Start </Caption> <Weight> 30 </Weight> <Width> 70 </Width> <X> 183 </X> <Y> 45 </Y> </block> (c) <block> <Id> id2 </Id> <Type> Condition </Type> <Caption> RSI; GRATER; 51 </Caption> <Content> RSI; GREATER; 51 </Content> <Height> 70 </Height> <Width> 30 </Width> <X> 396 </X> <Y> 80 </Y> </block> Figure 8. XML code block: Connector. Start control component. (c) Condition predicate component. The <block> node in Figure 8(c) stores a predicate component. <Id> is the unique identifier of the component. <Type> stores the type of the component. <Caption> is the title of the component. The <Content> in this case, stores RSI; GREATER; 51 which means RSI > 51 to prevent confusion of the > symbol as it has special meaning in XML syntax. The meanings of other fields are the same as before. 815

8 6. System implementation and validation The graphical user interface (GUI) of VATS is shown in Figure 9. It can be divided into three parts. The task menu bar can be used to create a new strategy, store it, or read an existing strategy and to compile it. On the left-hand side is the component toolbox. This offers the available components that can be used by the user. On its right is the workflow design area, which displays the strategy prototype. Figure 9. Overview of the system GUI. The sample strategy in Export to HTS First, the user picks the Start component and drags it to the design area. A Start component will be shown in the strategy design area. The user then drags a Condition component to the design area, which will open a condition component content edit window. The user can start editing the content of the predicate. The first condition is named Condition1, the second, Condition2 and so on. To define a customised function, the user can drag the user defined function component to the design area. The system pops up a window, which allows the users to edit their very own functions. The naming convention of the function is similar to the Condition component. i.e., the first function is called Function1; the second function is called Function2 and so on. After the user is finished with the editing, clicking the store button will save it to the file system. If the user wants to delete a strategy component that is no longer necessary, s/he can select such component, click on the right mouse button and choose the Delete Component option. An alternative way to delete the unnecessary strategy component is to click on Delete Component in the toolbox. Either one will do. To connect two components, the user should first choose the starting component and then the ending component and click on the connector component. There will be a line connecting these two components with an arrow pointing to the second one. This means that when the workflow starts, the one that is clicked first will be executed before the second one is executed. After the workflow design is done, the user can go ahead and store it so that this strategy can be reused another time. Ideally, the Compile option in the task menu bar can translate the strategy workflow into any language that can be executed and tested in the external algo trade platforms. We use HTS in our current implementation. However, the modular design means that it can be easily extended to other platforms such as Wealth-Lab or TradeStation. Figure 9 shows the result of the sample strategy in Figure 9 successfully imported into HTS. Once the strategy is imported into HTS, it can execute the strategy, generate buy/sell signals, conduct back testing and show the performance analysis report, as shown in Figure 10 and. This validates the correctness of our implementation. If the performance of the trading strategy does not meet the trader s expectations, s/he can perform modifications of the strategy in VATS, using only drag and drop on the preferred components. The entire process of our sample strategy, from the design of the trading strategy to the generation of the performance analysis report takes less than three minutes, which is much faster than writing the script language from the scratch. 7. Conclusion Algorithmic trading technology has been accepted by most of the major financial markets. Its applications include stocks, futures, options, currency exchange and many other derivatives. Statistical results show that it accounts for an increasing portion of the total trading volume. In response to fast 816

9 changing market cycles, the update frequencies of the algorithms and strategies are getting shorter and shorter. Although there are many program trading platforms that allow users to design customised trading algorithms and strategies, for most traders who are not familiar with computer programing, the entry threshold to the field of program trading is still quite high. This is because it requires years of experience in coding and is not something entry-level programmers off the street can do. Figure 10. Buy/Sell signals generated by HTS platform. Performance analysis of the strategy. If we distribute the job of strategy design and programming to different persons, not only does the communication between people come for two different fields can cause big communication gap, the program implementation, coding, testing and maintain takes a huge amount of time. The life cycle of the trading strategy may be over even before the strategy development is done. As a result, we may take a long to develop a strategy that is invalid. The visualization approach that we proposed in this paper makes the programing requirement to the very low, and let the user to design their trading strategy very quickly. The simple user interface makes VATS extreme easy to use. With very short term of practice, traders can easily use the system in no time. VATS has the advantages of affinity, reliability, speed, and easy to use. We believe that it is a valuable trading tool for the modern algorithmic trading age. 8. References [1] Apama, "Managing risk across the trading lifecycle", Progress Apama White Paper, [2] Greenwich. "Electronic Trading Tops 60% of Global Foreign Exchange Trading Volume", April 02, 2012; [3] S. J. Lee, and S. J. Jeong, Trading strategies based on pattern recognition in stock futures market using dynamic time warping algorithm, Journal of Convergence Information Technology, vol. 7, no. 10, pp , [4] M. Pemy, Optimal algorithms for trading large positions, Automatica, vol. 48, no. 7, pp , [5] K. Kim, Electronic and Algorithmic Trading Technology: The Complete Guide, Elsevier, [6] A. Kumiega, and B. v. Vliet, A Software Development Methodology for Research and Prototyping in Financial Markets, Quality Financial Management, [7] NYSE. "New York Stock Exchange"; [8] N. Nurmuliani, D. Zowghi, and S. Powell, Analysis of requirements volatility during software development life cycle, in Software Engineering Conference, Proceedings Australian, pp , [9] R. Pardo, The Evaluation and Optimization of Trading Strategies, Wiley, [10] B. Shneiderman, C. Plaisant, M. Cohen et al., Designing the User Interface: Strategies for Effective Human-Computer Interaction, 5th edition, 5 ed., Addison Wesley, [11] X.-D. Zhu, H.-C. Gan, C. Liu et al., Modeling traffic model driven route choice simulator in UML, International Journal of Digital Content Technology and its Applications, vol. 6, no. 5, pp ,

10 [12] Y. Yang, and H. He, Description logic based semantics checking for UML activity diagram, International Journal of Advancements in Computing Technology, vol. 3, no. 11, pp ,