Agent Brokerage:
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Agent Brokerage:

on

  • 989 views

 

Statistics

Views

Total Views
989
Views on SlideShare
989
Embed Views
0

Actions

Likes
1
Downloads
26
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Agent Brokerage: Document Transcript

  • 1. Agent Brokerage A human-centred approach to automated stock trading Jón Grétar Guðjónsson Gary Alistair MacRitchie Department of Computer and Systems Sciences Stockholm University / Royal Institute of Technology November 2005 The following thesis equates to 20 weeks of full work for each author
  • 2. Abstract An emerging concept in the field of financial products is that of software agents which are able to place trades directly on financial markets. The impetus for this is a perceived reduction in transaction costs, along with the ability to place complex trades that rely on a multitude of criteria being met. The additional benefits of increased speed of reaction and the ability to operate over many more investment opportunities than their human counterparts make software agents an interesting avenue of exploration for those wishing to gain a competitive edge on the financial markets. Following on from the proof-of-concept design of an Agent Trade Server at the Swedish Institute of Computer Science, this thesis shows that implementing a practical trading agent goes beyond the purely technical difficulties and has to consider the many legal, political, security and robustness considerations that are involved when dealing within an environment as significant as the financial markets. By carrying out a full requirements analysis, we show the major attributes from a technical and humanistic point of view required by any system that should work as part of a stock exchange. Further to this we propose a new architecture and offer an architectural design of an Agent Brokerage as a possible solution to support the creation of software agent traders, while meeting the requirements of the financial markets environment. ii
  • 3. Acknowledgements The authors would like to thank the following people, whose valuable assistance made the thesis writing process an enjoyable and educational one. Magnus Boman our thesis supervisor and mastermind behind introducing us to agent trading. Magnus supported us throughout but also gave us enough space to explore our own path. Always available for a chat and kept us on track with great advice and suggestions. Thank you Magnus! Daniel Hilmersson, a former masters student whose work we took as a starting point for our investigations and who was always enthusiastic of our ideas and willing to help wherever he could. Employees of Islandsbanki and Ludvig Sandhagen at Hagströmer & Qviberg whose time spent assisting our research phase was much appreciated and proved invaluable. And finally to Elísabet and Maria for putting up with us spending too much time with our heads in books about the stock market. Jon and Gary iv
  • 4. Table of Contents CHAPTER 1 - INTRODUCTION 1 1.1 Early efforts towards systematic trading 1 1.1.1 The approach of the academics 2 1.1.2 The approach of the industry 3 1.2 Research Question 4 1.2.1 Scope of the work 4 1.2.2 Formulation of a general research question 5 1.2.3 Related work 6 1.2.4 Feasibility of the solution 7 1.3 Goal 8 1.4 Purpose 8 1.5 Method 9 1.5.1 Research phase 9 1.5.2 Design phase 10 1.6 Limitations 10 CHAPTER 2 - RESEARCH AND REQUIREMENTS 13 2.1 The Social Environment 13 2.1.1 Clients 13 2.1.2 Analysts 14 2.1.3 Traders 15 2.1.4 Brokers 15 2.2 Hierarchy and information flow 16 2.3 The technical environment 17 2.3.1 Analyst information providers 17 2.3.2 Online Brokers 18 2.3.3 Trading Platforms 18 2.3.4 Existing exchange software 20 2.3.5 The Agent Trade Server 21 2.4 Complex trading agents 23 2.4.1 Many strategies, one active 23 2.4.2 Many strategies, many active 24 2.5 Reflections on requirements 25 2.5.1 Usability and humanity requirements 25 2.5.2 Performance requirements 26 2.5.3 Cultural and social requirements 28 2.5.4 Security requirements 29 2.6 Reflections on trading strategies 31 2.6.1 Strategy Representation 31 vi
  • 5. CHAPTER 3 - THE BROKERAGE CONCEPT 35 3.1 Structural design 35 3.2 Internal design 35 3.3 Work segmentation 36 3.4 Scalability 36 3.5 Defining roles 37 3.5.1 Strategy Agent 37 3.5.2 Information Agent 37 3.5.3 Information Collectors 38 3.5.4 Portfolio Agent 38 3.6 Information flow 38 3.7 Interfacing with the stock market 39 CHAPTER 4 - DESIGN 41 4.1 Architectural design 41 4.2 Architecture overview 41 4.2.1 The Brokerage 42 4.2.2 The Information Agent 43 4.2.3 The Portfolio Agent 43 4.2.4 The Strategy Agent 43 4.2.5 The Representative Agent 44 4.2.6 Component communication 44 4.2.7 Client portfolios and strategy interactions 45 4.2.8 Information tokens 46 4.2.9 Strategy selection technique 47 4.3 Meeting the requirements 49 4.3.1 Usability and humanity requirements 49 4.3.2 Performance requirements 51 4.3.3 Cultural and social requirements 52 4.3.4 Security requirements 52 CHAPTER 5 - CONCLUDING REMARKS 55 5.1 Lessons learned 55 5.2 Conclusion 57 5.3 Future work 59 5.3.1 Designing a notification service 59 5.3.2 Visualisation methods for strategies 59 5.3.3 Implementation of the design 60 APPENDIX A - REQUIREMENTS SPECIFICATION I vii
  • 6. Chapter 1 - Introduction A stock exchange provides facilities for the trading of securities and other financial instruments on a stock market. Members of the exchange are known as “Stock Brokers” and they work to match buyers with sellers so that trading transactions can take place. On modern stock exchanges, most stock trading is completed by the exchange software matching buy and sell orders that are sent to it by brokers. The brokers are following the instructions of traders; institutional or private investors, who employ varied strategies and methodologies in order to decide what stocks they should buy or sell. An emerging development in this relationship between traders, brokers and the exchange is the possible introduction of a method to allow software agents (Kagel and Roth 1995; Weiss 1999) to trade directly on the exchange. In this first section of our thesis, we will show why there is a need for such a new service, discuss the approach currently taken by industry, introduce the prototype agent trade server (ATS) and discuss how a trading agent can be designed to operate on this server. 1.1 Early efforts towards systematic trading Many traders see investing in the stock market as being a competition between them and the market, hence the term “to beat the market”. In order to beat the market, investors have devised a multitude of means and strategies in order to regulate their activities in the market place and protect themselves from what are seen as the disrupting emotions of greed and fear (Hasselström 2003). Historical methods and strategies such as those developed by Benjamin Graham, called value investing, as early as 1928, (Vanstone, Finnie et al. 2004) or Charles H. Dow’s (Edwards, Magee et al. 2001) introduction of technical analysis by Page 1
  • 7. creating indices of leading shares as indicators of future market behaviour, have been developed into an array of methods, tactics and practices, which modern day investors have at their disposal. Immense amounts of work have been, and still are, spent towards creating new and innovative methods and theories to outsmart the competition, to gain a competitive edge. The financial industry has been relying more and more on the innovation and development within the IT industry and academia (ibid.). 1.1.1 The approach of the academics Academia has been industrious in producing models of the financial market (Kagel and Roth 1995). One of the first attempts to model economical environments, a field within economics called experimental economics, explores economical theories and paradoxes using experimental setups. The method dates as far back as the 17th century and from it classic problems such as the prisoner’s dilemma, the free-rider problem and more originate. Experimental economics have been used to test the prediction of theories, serving as a dialogue between experimenters and theorists and connecting the ideal world to the real world (Kagel and Roth 1995). Another field of academia, computational economics, is mainly interested in the behaviour of markets and many computational models have evolved to simulate trade on a double auction market. One of the tools academia has used to implement these models is the agent oriented approach. Each investor is represented with a surrogate in a multi agent system which behaves according to the computational model’s prescription. These models are either homogeneous (Homme 2005) where the interactions of a few types of traders are being researched, or Page 2
  • 8. mixed, where the market consists of various types of traders utilizing various strategies to benefit from the behaviour of stock prices (LeBaron 2005). For example, artificial neural networks have been used successfully by a number of researchers to classify different types of stock, allowing them to identify undervalued stocks (Kendall and Su 2003; Vanstone, Finnie et al. 2004). Genetic algorithms have also been used to breed artificial investors, in an attempt to weed out the unsuccessful and create a breed of highly successful investors, or just strategies for use by real life traders to invest with (LeBaron 1998; Kendall and Su 2003). The agent metaphor has been used with success to create autonomous software to trade stocks using simple heuristics, both on artificial and real life markets (Sherstov and Stone 2004; Hilmersson 2005). Summarizing all the work previously done in academia is a book in itself and will not be covered in this introductory chapter in detail. Besides proving to be an immensely useful tool to analyze market behaviour, the work done within academia has resulted in researchers gaining insight into the inner workings of trading, and the creation of Artificial Stock Markets, such as the Santa Fe artificial stock market, and the trading agent competition (TAC) (Boman 2004), where agents can compete against each other in business. Recent times have seen the development of many technologies to attempt to allow users to find information, create new strategies, run complex strategies and automate the trading process using the existing stock market. 1.1.2 The approach of the industry Information technology has provided a recent revolution in the way in which non-institutional investors gain access to the stock Page 3
  • 9. market and surrounding information. The rapid growth of online, execution-only brokers has changed the way people are buying stocks, not only in the way a transaction is completed, but also in the method with which a stock is chosen and investment decisions are made. These include various Internet-based information providers, stock screeners, online brokers and sophisticated trading platforms that shall be discussed later which allow the testing and implementation of individual trading strategies. The rise of the online broker has not only come about due to the lower costs incurred, but also due to the fact of the increased ease with which a trade is placed. Investors can monitor their own portfolio in real time (with more expensive accounts) or with a fifteen minute delay for free. 1.2 Research Question We will examine and research what conditions must be met in order for an autonomous agent to trade stocks on the real market. We will also try to capture those conditions in a design fit to trade stocks using multiple complex strategies. Hence our thesis type is of the artefact development type overlapping the areas of improvement of artefact types and need for understanding, cf. (Brash, Björck et al. 2005). In the following subsections we formulate our general research question, setting the scope for our work. 1.2.1 Scope of the work Many stock traders and brokers today spend a lot of time looking at numbers on a computer screen monitoring their investments. Their efforts are mainly spent on responding to market fluctuations, trying to make money on these changes. Very few of Page 4
  • 10. today’s stock brokers actually make sense of all the abundance of information they are presented with every day (Hasselström 2003). The fast response time of the market and ever growing complexity of the exchange leave little time for the professional stock trader to think about tactics and evaluation of actions. According to the websites of the London stock exchange (LSE 2005) and the New York stock exchange (NYSE 2005), the number of listed companies is increasing by the week and new technological advances are made each year, resulting in faster and wider dissemination of information. Furthermore, the increased complexity and speed are straining those members of the public who want to monitor and do business on the stock market. It is our belief that the use of agents, acting on the behalf of investors, can address the complexity-and-speed issues of modern-day trading. We recognise that stock trading is now a global market and we will hence not be limiting ourselves to any local perspective. 1.2.2 Formulation of a general research question We will concentrate our work on the issue of adaptability and the environment of stock trading agents. With adaptability we refer to the agent’s way of determining what action to take on an abstract level, specifically deciding which trading strategy to implement at any given instance of time. Our research question is therefore: Can a sophisticated trading agent, which decides which investment strategy to use at any given point in time, be designed and implemented for the stock market? Furthermore what conditions must that agent meet to be considered a legitimate trader in real life? Page 5
  • 11. Hence, our work will consist of researching the current environment of stock trading, what properties a stock trading agent has to have to meet the requirements of real life, and what environment such an agent must exist in. 1.2.3 Related work Real life stock traders have been mixing trading strategies together for over one hundred years. Agents for trading stocks on real life stock markets have not yet, to our knowledge, been designed to select appropriate strategies, from an arsenal of trading strategies, to maximize their effectiveness. In the coming chapters we will discuss the Agent Trade Server (ATS), a prototype platform which was designed to allow software agents to trade on the Stockholm stock exchange (Boman and Sandin 2005). For an agent running on the ATS, using only one strategy has proved problematic as shown in a previous masters thesis by Daniel Hilmersson (2005). In Hilmersson’s case the strategy chosen was not appropriate for specific states of the market. It is our belief that giving the agent the ability to adapt strategy choice dependent on market conditions would address this problem. Research into the field of designing agents which can employ a variety of strategies has been done before (Kendall and Su 2003; Homme 2005; LeBaron 2005). In those cases, when implementing the adaptation of the choice of strategies, artificial neural networks (ANN) were readily employed. For example, Kendall and Su designed a stock market model, with ANN-based agents, where a number of agents developed strategies. They also showed the necessity of social learning to improve the overall efficiency. There is however, one large drawback to using artificial neural networks; there is no easily understandable way to analyze the network’s knowledge after it has been trained. The network’s Page 6
  • 12. synapses strengths are usually represented as a set of matrices of signed numbers called weights. A matrix of numbers cannot convey a methodology, not even a strategy such as “buy low and sell high”. Another approach to deploying multiple strategies does not involve ANN’s. This approach relies on conventional programming methods. For example, this approach has been taken in trading platform software such as TradeStation, using scripts and specialized command languages (TradeStation Group Inc 2004). We will address a problem not directly targeted before. To our knowledge, the work done so far has been focused towards the implementation, discovery or evolution of specific trading strategies. Since previous work has shown that there might be benefits of having a trading agent implementing different trading strategies based on the state of the market, we will try to devise a methodology to address this problem. This has not been researched in conjunction with trading agents before to our best knowledge. 1.2.4 Feasibility of the solution We will analyze the requirements put forth by the industry which a real life stock trading agent must meet. Our main effort will however be spent towards creating a methodology for running complex trading agents in today’s technical environment and creating a design which meets both our functional requirements and the non-functional requirements imposed by the industry. We will build on the work done by Hilmersson (2004) and Johansson et al. (2003), the analysis performed by Boman and Lybäck (2002) along with various other sources. Page 7
  • 13. 1.3 Goal Our goal with this project is to build an understanding of the requirements and difficulties associated with developing complex agents which can trade alongside their human counterparts on the real stock market. We will seek to accomplish this by attempting to design an agent capable of investing using an arsenal of different investment strategies. By assessing the financial industry standards, conventions and legal requirements we will consider the barriers to the practical use of agents in the real world and propose robust and secure solutions to overcome these barriers. 1.4 Purpose By allowing the programmed strategies to be complex in nature if desired, we will show that agents allow for a new channel of access to investing on the stock-market. Such software could enable the professional stock trader to spend more time thinking about a course of action for managing and planning the trading of stocks, instead of spending efforts towards monitoring a list of orders on his computer screen. Allowing the home investor to create his, or her, own strategies and leave the implementation of these to the agents will also improve the public’s accessibility to the market, levelling the edge that the large financial institutes have on the public. Automating the decision of which strategy to use to trade stocks can also empower the average day user to develop strategies with a degree of security, since the “best” strategy is used at any given time. The client can rest assured that his trader is always investing using its optimal strategy, without him having to monitor his investment constantly. Page 8
  • 14. 1.5 Method This section describes the methodology we will use to design our trading agent. We will base our work in part on software engineering lifecycle models, such as the waterfall model and the spiral model but only to a certain extent. The work will be split and carried out in two main phases: the research phase and the design phase. We will continue our research throughout the project, addressing design issues as they arise. The model that we have chosen is an iterative version of the waterfall model (Bennett, McRobb et al. 2002). The reason behind our choice of the iterative waterfall method is two pronged. On one hand we both have good knowledge of this method and have used it in our previous projects, on the other hand we felt that an easily understandable and well defined model would bring structure to our otherwise unstructured research. Following is a description of each phase. 1.5.1 Research phase The research phase consists of two parts, literature research and a quick and dirty ethnography research. The two parts are carried out in parallel and will be continued throughout the duration of the thesis work. The literature research phase consists of reading and reviewing literature related to the field. The topics of the literature cover all fields related to our thesis, such as technical and fundamental analysis for stock trading, stock trading practices, strategies for stock trading, agent design and programming, anthropology research and software engineering. Page 9
  • 15. Quick and dirty ethnographic research is used to gain knowledge of the environment and practices of stock trading. It consists of a series of short interviews and observations, even a questionnaire, deploying a semi-structured interview technique to capture as much peripheral information as possible. The contents of the questionnaire sent out to Íslandsbanki and modified version used to interview Ludvig Sandhagen at Hagströmer & Qviberg consisted of questions regarding their disposition to their work and workplace, their day to day routines, their job definition, their actual responsibilities at work and their experience and knowledge of computer systems. By capturing this peripheral information we discovered what we could not read in books, but is common knowledge in the field. This builds up our overall understanding and enables our design to conform better to the requirements of real life. 1.5.2 Design phase When all the basic information has been collected and analyzed we will follow a software design methodology. Since software agent design is a relatively new field, we will mainly adhere to the Object Oriented design methodology (Bennett, McRobb et al. 2002), but modify it, were we find necessary. 1.6 Limitations The focus of our thesis will be the development of agent software to choose which strategy to use while investing money, although these strategies are based on specifics of stock trading, we will not go into specific strategies in any detail. Further, we will only consider the trading of company stock and by trading we refer to the process of first buying then selling (also known as “going long”). Page 10
  • 16. We will design an environment for the stock trading agent’s execution, based on the information we have collected. It is important to point out that this thesis is a demonstration of our knowledge in design with respect to social and humanity factors as well as external requirements. We will present our design as a blueprint, or a guideline for whomever wants to implement such a design, we will not delve into implementation specific issues or present the result of any programming efforts. Page 11
  • 17. Chapter 2 - Research and requirements The existing methods of trading stocks have a well defined social structure. This allows us to look at how a trade is executed through the main players involved in the market. These are the client, the trader, the analyst, the broker and the investment houses. Figure 1: The main players in the stock market are the client, the traders, brokers and analysts. There is a constant flow of resources and information between these actors and varying shifts in responsibility depending on the task being undertaken. 2.1 The Social Environment Following is a discussion of the social environment of stock trading. 2.1.1 Clients There are many entities that could be referred to as clients in the world of stock investment. These range from private individuals who choose their own stocks and trade directly with a broker in order to buy or sell, to large investment banks putting forward money to be invested by a team of professionals. When regarding Page 13
  • 18. the individual as the client, investing a sum of money with an institutional investment house, perhaps as a part of a mutual fund or an investment product such as a private pension, we can see the client as filling two roles. Firstly, the clients are the providers of funds to be risked upon the stock market in the hope of increased returns. They provide the fuel that drives the engine of the stock market and as such when acting on mass are a very powerful group. Secondly, the clients are courted by the investment houses and suppliers of investment products by using a multitude of marketing techniques. Probably the most effective of these techniques is the ability to show potential clients good past returns in order to tempt them to invest. This puts pressure on investment house managers to get the best returns and this pressure is passed down to the traders, often with severe consequences for failure and high rewards for success (Hasselström 2003). The individual client in these scenarios may well be the catalyst for the whole process, but is however likely to be the least knowledgeable about the mechanisms of the market and the implications of different events on the market. 2.1.2 Analysts Analysts are employed either internally by investment houses or by specialist companies who sell their results as services to investment houses. It is the analyst’s job to perform various examinations of a stock’s potential and to report this back to a trader. If a trader makes good investments from recommendations from a particular analyst, he is more likely to trust him and use him in the future, which is good for the analyst’s career. Analysts tend to see the traders as gamblers while they think of themselves more as scientists (ibid.). Page 14
  • 19. 2.1.3 Traders The traders have a two way relationship with the managers of the investment houses. These managers decide which traders to recruit and which traders to promote or fire, but the careers and businesses of the managers also depend on the success of the traders. The professional traders themselves tend to know only about 15 or 20 companies in great detail and continually monitor these companies stocks for investment opportunities, perhaps trading the same stock several times a day (Schwager 2001). The traders make the decision about what stocks to buy and sell and when, but they have to use an intermediary called a broker for the execution of the trade on the stock exchange. 2.1.4 Brokers The brokers earn commission for every trade whether it is a profitable one or not. As such, it is in the broker’s interest to try and ensure that a trader uses him for each trade and to achieve this broker’s work hard to build a bond between themselves and traders. They do this through trying to pass traders profitable information and also through a more social scene of entertainment and expense accounts. Traders too, work at building a bond between brokers that they trust in order to be in line when the broker gets some useful information. However, traders tend to hold brokers in quite low regard and consider them as being of lower status than themselves (Hasselström 2003). Information thus tends to flow towards the trader as he makes the decisions on where the money is spent. Analysts take their information from financial reports, stock price trends, etc and construct recommendations for traders to use. Brokers use knowledge of trades that are going through, rumours and word of Page 15
  • 20. mouth in order to make their recommendations to the traders. The traders have to evaluate all the time the quality of the information they receive and learn which sources to trust and which to ignore. Once the trades have been placed, the financial house managers evaluate the traders’ performance and decide which ones get bigger portfolios to manage and which ones are no longer employed. Generally after fixed periods of time, the clients are informed of their investments’ performance. They then evaluate this information and decide whether to invest more money or withdraw their funds and invest elsewhere. 2.2 Hierarchy and information flow We can present the institutional hierarchy and the flow of information using a rather simplistic schematic diagram, see Figure 2. Figure 2: Information flows between the actors in the stock market, with a hierarchy of decision making. Page 16
  • 21. The brokers interact with the exchange placing sell and buy orders. They receive their directions from the traders, who are acting on behalf of the clients. We can also visualize the flow of information, starting at the brokerage and propagating outwards toward the client. The information usually propagates through the layers of the brokers and the traders at the same instance, but the client only receives information a while after the events happened on the stock market. However using today’s technological environment, information can be retrieved from the stock market much faster than it propagates through the different layers of brokers, traders and clients. 2.3 The technical environment In the following subsections we will have a look at the technical environment of today’s stock trading. 2.3.1 Analyst information providers Prior to the widespread acceptance of the Internet, the individual investor would have to rely upon sources such as newspapers, end of year reports and advice from stockbrokers when researching a share. Now, the private investor can access a range of continually updated financial information from his or her desktop for free or low cost subscriptions (Allgood 2001). Web portals such as Yahoo (http://www.yahoo.com) and more specialist sites such as The Motley Fool (http://www.fool.com) offer huge amounts of historical and 15 minute delayed market data, charts, news, broker recommendations, trends, technical analysis, income statements, balance sheets, end of year reports, cash flows, analyst estimates, research reports and much more, all for free. New innovations such as a stock screener that allows investors to Page 17
  • 22. narrow down the thousands of stocks that exist on a market to those that match the individuals basic prerequisites (http://screen.finance.yahoo.com/newscreener.html) allow the investor to complete at the touch of a button a previously unfeasible research task (by the time the individual had researched through thousands of stocks some data may have changed, rendering his research erroneous). The constant supply of high quality financial information available to all those with a modem has in many ways levelled the playing field between individual and institutional investors and has certainly fuelled a belief in many individual investors that they no longer have to rely on brokers or brokerage firms to decide about their market transactions. 2.3.2 Online Brokers According to an article in the Economist magazine (The Economist Newspaper Limited 2000), in the mid 1990s clients of full-service brokers were regularly paying between $100 to $400 USD per trade. In May of 2000, clients of the major off and on-line broker Charles Schwab could place a trade for $14.95 while accessing all the previously mentioned information for free. The ability of an online broker to cope with fluctuations of demand and deliver instant price quotes for thousands of stocks across many markets means that online stock broking provides more than just an automation of the telephone based execution services (Allgood 2001), but actually hides the brokerage stage from the investor and allows him to feel he is dealing with the market directly. 2.3.3 Trading Platforms A step on from the online brokerage and research is the emergence of trading platforms for both institutional and individual Page 18
  • 23. investors. An example of such a trading platform for institutional investors is SunGard’s Front Arena (SunGard 2005) which combines front and back office supportive software as well as tools for analysis and trading across multiple markets. Software to support smaller companies or individual investors such as eSignal (eSignal 2005), Metastock (Equis International 2005) and most noticeably, TradeStation (TradeStation Group Inc 2004) occupy the gap between the existing normal trader/broker relationship and what we will suggest as a possible future scenario in this thesis. It will be illustrative to look at some features of these three packages. Metastock and eSignal allow the software owner to carry out technical analysis on stocks, bonds, currencies and other tradable investment opportunities. The user downloads third-party historical or real time data for the commodity he is interested in and then uses the program to perform the analysis. The programs include different indicators and tools to help in sorting and selecting stocks that meet predefined criteria. Both programs have many features but the main focus of these programs is to allow users to create their own buy and sell strategies based on technical analysis and then run them against historical data to see if they would have been successful in the past as an indicator of possible future performance. Users can also pick certain stocks and run multiple strategies in order to see which strategy is the most effective for a particular investment opportunity. The output of the program is effectively recommendations on which strategy to use, which stocks to buy and sell and importantly, when. Both programs can be linked to an online broker to allow the user to enter their trade orders directly. Page 19
  • 24. TradeStation is similar in many ways to eSignal and Metastock allowing investors to develop and back test strategies on historical data. TradeStation allows users to write their own strategies using a proprietary pseudo-code, allowing simple or extremely complex technical strategies to be tested. One of the most interesting aspects of TradeStation is that trading can be set to be fully automated. TradeStation monitors the market in real time, tick by tick, and once market opportunities are identified that match the investor’s strategy; it can execute the trade without any interaction from a human. The buy/sell orders are sent automatically by the program to an online broker who completes the trade on the real market. The concept of TradeStation is very similar to that of agent trading using the prototype ATS. After the strategy is set, the program takes full responsibility of what stocks to buy or sell and when to make the trade. As far as the user is concerned, the interface between the trading platform and the actual market is seamless. 2.3.4 Existing exchange software At the heart of modern stock exchanges lies complex software systems matching buyers and sellers and distributing information on already executed trades known as trading systems (OMX 2005). In order to be able to trade on an OMX exchange, the broker needs a member SAXESS trade application. Each application connects to a SAXESS trade server which in turn is connected to the core. This all happens using the XTP protocol, which stands for open eXchange Transaction Protocol. The XTP is an OSI layer 7 protocol. In this case, the core is a deterministic program written in C, which matches stacks of buy and sell bids from investors. These systems are utilised by brokers who are either placing trades on their own behalf, or on behalf of traders Page 20
  • 25. who pay them a commission to do so. A schematic description of the general system can be seen in Figure 3. Figure 3: At the heart of modern stock exchanges lies complex software systems matching buyers and sellers and distributing information on already executed trades known as trading systems. 2.3.5 The Agent Trade Server Combining both the work done in academia and the industry, an Agent Trade Server (ATS) has been developed and implemented Page 21
  • 26. at SICS (www.sics.se). The work was done in cooperation with a company, now called OMX, as a proof-of-concept (Boman and Sandin 2005). An ATS is a link between trading agents and the actual stock exchange system. It executes agents, supplies them with stock data and enters their orders into the system. The ATS opens up the possibility for agents to submit complex orders and allows them to follow pre-programmed investment strategies and broker their own deals as if this was a real stock market. Some agents for the ATS have already been programmed. Jesper Johansson and Michael Poijes developed a shell for trading agents (2003). Their work resulted in the implementation of a Java package to use when implementing agents for the ATS. To test their package they developed a simple day trader agent. Their work resulted in proving their hypothesis, that a simple agent can be implemented for the ATS in a few hundred lines of code, while maintaining correct functionality. Another thesis written by Daniel Hilmersson improved previous work done for the ATS. Hilmersson’s work, based on the agent package by Johansson and Poijes, included the business logic known as “Reversal Gap”, (Hilmersson 2005). Hilmersson showed that it was feasible to have a larger, more sophisticated agent run on the ATS. The agent functioned correctly and the business logic was executed as expected. Hilmersson also modified some of the code for the ATS to enable his agent to parse historical data for evaluation. However, these agents have rather been a proof of concept, running on a limited market (for example 10 stocks) with simple single strategies. There is still the issue of complexity to address, combination of strategies and decision making based on Page 22
  • 27. information one cannot mine from stock prices alone. More agent variants are needed, in order to display the flexibility and accessibility of the ATS (Hilmersson 2005), (Jesper Johansson 2003). 2.4 Complex trading agents For his thesis, Hilmerson programmed a simple day trader running on the ATS. One of his findings was that the strategy he used demonstrated varying efficiency depending on the state of the market. He suggested the development of an agent that can run different strategies and invest using the best one. This was the starting point for this thesis; we wanted to design an agent which has many strategies at its disposal and would invest using the strategy which yields the best return at any given point in time. There are different ways of achieving the goal of trading with multiple strategies. 2.4.1 Many strategies, one active The first approach is to create an agent which has a set of strategies and a guideline when to use each strategy. In this case the agent will follow instructions on what strategy to invest with at any point in time. The benefits of this approach are that the design of the agent is very simple, concise and neat. Strategies are active based on market indicators or other predetermined yardsticks indicating which strategy to use. This way has the drawback of being ill adaptable, or not at all. If any of the premises the master strategy uses change during the timeframe of the program, the appropriateness of the strategies changes. For example, if the financial landscape changes in a way that is unforeseen the yardstick used to select the best strategy is useless. This is especially true when many people are using the same strategy, Page 23
  • 28. since the inefficiency in the market exploited by the strategy gets over exploited. In that case the strategy loses its edge and may not be the most appropriate one. 2.4.2 Many strategies, many active This leads us to the second way of trading using multiple strategies. As we have noted before, the selection criteria should be based on which strategy is performing best at any instance in time. To be able to determine the strategy which is performing best at any instance in time we must have some means of evaluating their return in real time. However, evaluating their return in real time implies that we need to have each of the strategies running concurrently; measuring and comparing their performance in real time. These kinds of tasks, repetitive number crunching, are exactly what a computer is best at. Therefore, we suggest that instead of running a single threaded agent, a multi threaded agent is needed to achieve these means. The agent would then have a thread running for each of the strategies, and a number of control threads evaluating the performance of the strategies and doing the actual investing. This method addresses the problems associated with using a static yardstick to determine what strategy to run. By comparing for example, portfolios for each of the strategies, we have a dynamic, adaptable yardstick which will always yield the strategy which is performing best at any point in time. This idea has some implications for the ATS. As Hilmersson work pointed out, an ATS can run day trading agents which each have a single thread of execution. When we add strategies to each of the agents running on the ATS the number of threads managed by the ATS increases considerably. As each agent consumes more Page 24
  • 29. resources, the ATS is able to support fewer agents than before with fixed resources. If the number of agents running on the ATS should stay the same, the resources should be increased considerably, which in turn means more expenses for whomever is responsible for managing the ATS. As our research and requirement analysis progressed we saw that this approach is a simplistic one, there are number of functional requirements that we identified which imply that the software should have more sophisticated facilities for strategy selection, portfolio management and information aggregation, in addition to the evident need for the user to be able to easily express the strategies he wants to use. 2.5 Reflections on requirements Requirement identification and specification are a vital part of any design process. As we worked towards the completion of our task we used a requirement specification template created by the Atlantic systems guild, called Volare (Robertson 2004). The results of the requirement specification can be seen in Appendix A. We captured the requirements by mining them from the data collected by interviews, quick and dirty ethnographic surveys and numerous pieces of literature research, see list of references. Following is a discussion on what we found during our requirement specification steps. We examine different types of requirements and analyse their implication on our design. 2.5.1 Usability and humanity requirements Correct functionality of a system is always an important issue, especially when the stakes are as high as they are in the financial industry. It is imperative that the system provides some way to Page 25
  • 30. analyse its actions. It is not important at this stage what ways are provided as long as they can be used efficiently to correct the system and fix errors or bugs. Another issue surfaces after we identify the need to be able to analyse the system’s actions. The system needs a way to efficiently fix its problems without having to bring the whole system down. For example, if there is a small part of the system needing changes, upgrades or bug fixes it is unacceptable that the whole system has to be stopped and started again once the work has been carried out. An implicit requirement is that the system has clear and well defined boundaries between its subsystems that have different responsibilities. The system must facilitate experimentation and research. Trading platforms in general should provide these functionalities both at the level we mentioned earlier, that the user should be able to see what the system is doing and analyse its actions, and also allow the user to experiment with new strategies and different ways of processing information. 2.5.2 Performance requirements Systems running in the financial market are “hard” real time systems. That is, there cannot be any delays when sending messages and orders back and forth. This real time propagation of information requires the system to be flexible to changes in its environment, both software changes and hardware changes. Routers, hard drives, and even software components might fail due to error correction, updates or bugs. In addition, being a “hard” real time system interacting with the stock market, the system must be available and running at all times appropriate for Page 26
  • 31. a stock exchange. That only leaves a part of the night for maintenance and data backup. Most exchanges have regular opening hours, during which the system must be available. The system also needs to perform other jobs after opening hours, such as evaluating end of day strategies and performing maintenance on databases and perhaps logs. It has been pointed out by Boman and Lybäck that the core systems in the exchange are not allowed to become overloaded. The financial exchange is also a “hard” real time system and must be tractable, that is to carry out all its tasks within an allotted timeframe. Therefore software running on the core system is not allowed to consume too many resources and risk overloading the core system. To ensure this Boman and Lybäck pointed out that all code running on a system tightly coupled with the exchange must be inspected by the authority responsible for the core systems of the exchange. Inspecting and verifying the functionality of all the code is an immense and tedious task. It was suggested that limiting the language, methods, libraries, etc. that agents can be constructed in can be used to make the process of code inspection feasible. Even if it has been a tractable task when running simple agents, it is not an attractive task after having introduced more complexity onto the software, such as thread interaction which can result in deadlocks and other artefacts which are not popular in a tractable “hard”, real time system. Further more, no client’s code is allowed to interfere with the execution of another client’s code. As soon as a single client’s code brings down the system, because of badly written or malicious code, he might become financially responsible for the incurred losses and damage caused by his code. In a high stakes environment such as stock trading, the amount due could easily cripple any investor, Page 27
  • 32. in addition to causing loss of trust and degrading the integrity of the authority responsible for the exchange. 2.5.3 Cultural and social requirements We must also consider requirements based upon social and cultural constraints and conventions. As pointed out by Almberg (2002), when we introduce a new system into the market, the credibility of the institution involved should not be degraded. This is especially true when dealing with an institution such as the stock exchange as it is a barometer for countries and global economic performance and affects government and individuals’ economic decision making and policy (Hasselström 2003). The consequence of a loss of credibility in the financial markets can be seen by the effect of the accounting scandals at firms such as Enron and WorldCom. This contributed to an increasing falling market and new regulation in order to try and restore client confidence (Bonello 2005). It is also imperative that the functionality of the electronic exchange continues to be deterministic and that the functionality does not change in any way. This is important because the exchange has in essence provided the same services for decades. All changes and modifications done to the exchange have been to optimize its operation, not to change its fundamental role as a double auction market, matching buy and sell bids. When any bilateral transaction is conducted, there needs to be an element of trust especially when being the first to act. This factor is increased when dealing with online systems (Kollock 1999) largely due to the inexperience in dealing with the new concept, unfamiliarity with the medium or the lack of a visible physical Page 28
  • 33. presence of the people you are trading with. When discussing the concept of allowing a piece of software self-directing control over a large amount of an individual’s money, we believe that trust will be a major factor. To support trust in such a system, it is important that it be regulated by a trusted financial services authority, then clients know that the company itself meets certain standards of credibility. As for the concept of allowing the agents control over people’s money, we believe that we can support clients’ confidence in the system by allowing them to test their strategies on historical data. This would allow them to build an impression of how they may perform in the future. This is analogous to how a client may choose a mutual fund investment on its previous year performance. 2.5.4 Security requirements We touched on the need for code inspection when discussing performance requirements. There are also other aspects to verifying the code, mainly security reasons. Because it is a highly prominent system and the sheer number of agents running on a system that is coupled to the stock market, it would most likely become a target for hackers and other mal intended individuals. Verifying the functionality of all the code, to try to detect all attempts to break or do harm to a core system in the exchange, becomes an immense task mainly because of the following factors. Using encryption techniques and advanced coding techniques, malicious code can be hid inside seemingly harmless code. Competitions have been held where hackers have written a seemingly harmless program and had other hackers try to locate malicious code masquerading as simple harmless excessive Page 29
  • 34. code, that is code which has no apparent task but is usually included in source code due to various reasons, such as quirks, coding conventions and even ignorance (Craver 2005). The number of clients running on the system could be huge. If we consider trading platforms such as TradeStation, which as of June 30th 2005 had 20,942 clients (TradeStation Group Inc 2005) and then consider the case that each client’s code has to be examined for malicious parts, possibly written using state-of-the-art virus techniques, the business of verifying code becomes a booming business, adding excessive costs to running a client on a centralised system. Further to this, every time the client wanted to make even the smallest of changes to her code, the whole examination process would have to start over again. There is also the issue of authentication; a common strategy used by inventors of malicious code is to impersonate a trusted partner. For example one of the computer viruses to emerge in recent years, Worm-Swen.A, impersonated an email update notification from Microsoft (Symantec 2004). The bullet asked the receiver of the email to install a patch to prevent his computer from being infected by a second virus, by installing the “patch” he infected his own computer with the first virus. This presents the problem of authenticating the programmer of the code running on the core systems. The authority responsible for the core systems must have a way of making sure that the code was programmed by whom it says it was. There are various technologies available today, such as the Java security model which prevents tinkering with the code, Public Key encryption and so on. This however becomes a tedious task if the numbers of Page 30
  • 35. clients reach the numbers using today’s commercial solutions as we have mentioned before. And last but not least, the system must be designed so that full confidentiality is kept. There must be no way for software running on the system to examine the preferences of other programs, eavesdrop on communication between the software and the core systems, and hence gain valuable information which otherwise would not have been available. 2.6 Reflections on trading strategies Strategies are the methods used to narrow down all available stocks to the ones that should be invested in. Strategies can vary in many ways from the simple (for example only investing in stocks with price to earnings ratio greater than x), to the complex, to the seemingly bizarre (such as relying on planetary alignment). Human traders mix and match strategies dependant on market conditions so a complex trader should be able to run multiple strategies simultaneously while able to execute trades from those most likely to succeed. 2.6.1 Strategy Representation Strategies and the data they analyse are a matter of individual investment preferences, but there are four main aspects needed to have a full strategy. The Encyclopaedia of Stock Market Strategies (Katz and McCormick 2000) provides the following definition of the needs of a complete strategy. 1. When and how, and possibly at what price, to enter the market Page 31
  • 36. 2. When and how, and possibly at what price, to exit the market with a loss 3. When and how, and possibly at what price, to exit the market with a profit. To which we add the following… 4. When and how to exit the market after a period of time. This allows for the strategies to be modularised with each strategy consisting of a maximum of four modules. The four strategy modules are the entry sub-strategy, the exit for loss sub-strategy, the exit for period sub-strategy and the exit for profit sub-strategy. Each strategy is made up of these four blocks. This allows for easy creation of multiple strategies from pre-written strategy building blocks, e.g. one for when to enter the market and one for each of the three ways to close out a deal. This could be a very simple method for novice or standard users to customise their own strategy choices by choosing slightly modifiable prewritten blocks from a strategy library. Much research was done into the make up of strategies and the different manners in which technical analysis indicators are used to signal stock buys, however, that topic would be better suited for an economics thesis. The main point of interest with regards to agent trading is how a strategy can be represented easily for processing by a strategy agent. We propose a method to overcome this problem by breaking strategies into Boolean statements that if met produce an action. This way even the most complex of strategies can be broken down into a list of simple true or false statements. For example, the Reversal Gap strategy used Page 32
  • 37. by Daniel Hilmerson would be explained in human terms in the following manner… If the opening BUY price is higher than the highest BUY price of yesterday and the closing BUY price is over both the mean price of the day and the highest BUY price for the last two days, then that day has the potential to be a Reversal Gap Day. If the 50 and 20 day average trends are positive then a buy is entered for execution on the next day at the highest BUY price of the Reversal Gap Day. This could be broken down into a series of Boolean functions that if met produce an action, for example (where n is the stock and t is the date)… • BUY_OPENn(t) > BUY_MAXn(t-1) • BUY_CLOSEn(t) > PRICE_MEANn(t) • BUY_CLOSEn(t) > BUY_MAXn(t-1) • BUY_CLOSEn(t) > BUY_MAXn(t-2) • 50_DAY_TREND > 0 • 20_DAY_TREND > 0 • Action = BUY @ BUY_MAXn(t) If a list of stocks that match each Boolean statement is returned then any stock that is on all lists would be processed according to the action. Each variable in capitals would have to be able to Page 33
  • 38. return a value; we discuss how this could be in section 4.2.8 where we introduce the concept of information tokens later on in the thesis. Page 34
  • 39. Chapter 3 - The Brokerage Concept We have emphasised a number of properties and behaviours our system must possess and demonstrate. Non-vital topics have also been mentioned and in this chapter we will try to tie those vital and non-vital requirements together in a concept we have chosen to name the Agent Brokerage. The following chapter introduces certain issues our architecture addresses and in the next chapter “Design” we present our idea of a design for this brokerage. 3.1 Structural design By structuring the design to be analogous to the current human system, we can take advantage of a tested architecture that users are already familiar and comfortable with. As discussed before, there is a multitude of legal, political, technical and regulatory reasons why it would be unfortunate to allow complex traders to be run on a system tightly coupled to the core systems of the stock exchange cf. 2.5 above. We propose a solution to this problem by introducing the Agent Brokerage. The Agent Brokerage is an additional server for running trading agents. The brokerage is based at a different physical location from the exchange, allowing multiple brokerages to be run by different institutions and companies without involving the authority responsible for the exchange. Its purpose is to allow the running of trading agents on a platform where they are free to access various resources or be modified to fit the needs of a client. 3.2 Internal design We suggest that the brokerage is constructed as a multi agent system (MAS) where labour and responsibilities are clearly divided between agents analogous to the current human Page 35
  • 40. arrangement. It is our belief that this arrangement has several advantages over traditional design approaches as we shall elucidate to in the following sub-sections. 3.3 Work segmentation By assigning different tasks to different agents we achieve a social structure similar to that in use in real life. Although ours is a simplified version of the real thing, it is our belief that it serves the purpose. We need agents that assume the roles of the trader which finds stocks that are profitable, the analyst which looks into historical trends and processes information, and the portfolio manager which manages the portfolio with regards to risk management, money management and so forth. One of the benefits of distributing responsibilities in this way is that standardised agents can be used for various tasks, relieving some of the tedious task of code verification performed by the authority running the brokerage. One of the remaining variable factors within the brokerage is the strategy agents. As we have seen in section 2.6 there are standardised ways of expressing strategies. If we include this standardised way of expressing strategies in our system, we can replace the custom built strategy agent with a standardised agent, without sacrificing the flexibility of a customised strategy agent. 3.4 Scalability One of the most common problems faced by software engineers today is to develop systems which scale gracefully. Our technique of using a MAS approach allows us to split our system up and run it on separate processors and in separate memory spaces. It is our belief that communicating over a network in today’s Page 36
  • 41. technology environment will not pose a problem. The brokerage will be connected to the exchange over a high speed WAN connection, as often is the case. Servers will then be connected to each other, over a high speed LAN, such as a gigabit Ethernet connection. 3.5 Defining roles In order to achieve the requirement of having agents capable of placing complex trades, we suggest a multi layered architecture where recommendations of stocks to buy or sell are delivered to a central decision making agent that decides which recommendations to listen to and instructs a trade to be executed. This can be thought of as analogous to different brokers and analysts recommending stocks to the traders in the human realm. We see the major parts of the brokerage system as consisting of the following components. 3.5.1 Strategy Agent Multiple strategy agents that can be configured to recommend stocks by matching them to a list of criteria given in a strategy file. This agent is analogous to an analyst who passes recommendations to a trader. 3.5.2 Information Agent The Information Agent acts as an aggregator for information collected from the environment. All agents can register for a piece of information using a data structure describing who needs the data and what the data should be. The Information Agent will be the manager of a group of agents which are called Information Collectors. Page 37
  • 42. 3.5.3 Information Collectors The Information Collectors retrieve data from the external data sources such as third party data providers. Each Information Collector is responsible for gathering, monitoring and reporting one particular calculation from the external data. Via the Information Agent, the Information Collectors know which agents have requested information and report directly to them. 3.5.4 Portfolio Agent The Portfolio Agent is responsible for sending buy and sell orders to the Representation Agent. It evaluates whether stock buy recommendations from the Strategy Agents are suitable and is also responsible for maintaining the portfolio of currently owned stocks and maintaining several virtual portfolios for each of the strategies so that the various strategies can be monitored and assessed. The Portfolio Agent decides when to sell a stock by setting up a monitor for every stock in the portfolio or virtual portfolio. These monitors know which Strategy Agent the stock has been recommended by and as such know the exit strategy. This agent is analogous to the human trader, taking recommendations and information from outside sources, deciding who it trusts most to offer good recommendations and then sending off orders to be executed by a broker. 3.6 Information flow By using these ideas for the design, we will achieve an information flow similar to that existing in today’s human environment; see Figure 3. Page 38
  • 43. Figure 4: Information flows into the Agent Brokerage through Information Collectors bringing it back from third party sources and delivering it to the various agents that requested it. 3.7 Interfacing with the stock market We propose that a stock market interface such as the ATS is used to run simple and light “representative” agents that take buy or sell orders from the Agent Brokerages. Our proposal is that only simple “execution only” agent’s trade on the ATS, implementing trade orders that are requested from the Agent Brokerages. This arrangement has a number of benefits: • Only very simple agents are run on ATS which should lead to good performance. Page 39
  • 44. • All agents on the ATS are from trusted sources. • Management of agents is no longer an issue for the ATS operators. • Legal responsibilities are placed on the brokers, just like the present set-up. We envision that the form of these agents would be similar to that outlined in the Agent Shell by Johansson and Poijes (2003). The representative agents would behave in the same way as if they were getting orders from a human source, simply executing trades. This means that only many instances of a single configurable agent have to be written and ran on the ATS, vastly improving the security and reliability. From an analogy to the present human system, the representative agent could be seen as some kind of execution only broker whose sole job is to do as he is instructed. The brokerage itself is a collection of pre-written but configurable agents that each carry out a certain function of the brokerage. We have already introduced these other agents. The major benefit of setting up the brokerage in this manner is that no outside source gets to write executable code for the brokerage. Clients are only able to configure already existing “base” agents in a manner that provides full control over the agent’s actions, but protects the brokerage from malicious attacks or unwanted agent behaviour. Page 40
  • 45. Chapter 4 - Design In this chapter we present our proposed design for an Agent Brokerage based on our observations and analysis covered in the previous chapters, where we looked into ways to achieve our design goal while fulfilling all of our stated requirements. We will present our final design in more detail and try to capture the interactions between objects in greater detail and try to focus on the interaction between objects on a practical level. We will not present a complete implementation of our design in this thesis; however we have implemented parts of the design for exploratory purposes, such as the messaging system. 4.1 Architectural design According to our design methodology discussed in section 1.5 we start by covering the architectural design and then move on to a more detailed design, although we will not cover implementation specific issues in depth. This chapter should be considered as a guideline for those who would like to implement an Agent Brokerage in the future. The architectural design covers issues such as which components the system includes and how they interact with one another 4.2 Architecture overview A schematic diagram for the design can be seen in Figure 4, below. Page 41
  • 46. Figure 5: We can think of the concept of the brokerage as a number of layers. Each part runs on and communicates with the layers directly above and below as well as others in its own layer. Since our design is inspired by the way real stock traders and brokers work together, we will follow the outline of the way in which human actors interact. The system consists of the following components: 4.2.1 The Brokerage The Brokerage is the backbone of our design, it serves as an execution environment for our agents, and hence needs to supply and manage logging facilities, configuration management and the messaging system, allowing each of the components to interact with each other. Detailed designs for each of the components of Page 42
  • 47. the brokerage can be obtained from the authors upon contacting them. 4.2.2 The Information Agent The Information Agent acts as an information broker: The Information Agent manages a collection of information collectors, objects which interface with information sources and process the information presented there. 4.2.3 The Portfolio Agent The Portfolio Agent manages the client portfolios and all associated data structures. It decides what stock to invest in based on the correlation between the portfolio contents, the money management strategy and the investment strategy. The money management strategy is configurable by the client in order to give some constraints to the portfolio agent’s powers. For example, a simple money management strategy might be to never have more than 80% of the total accounts cash invested at the same time and never to invest more than 25% of the account in any single financial sector. The portfolio agent also manages a collection of exit monitors for each of the portfolios, which indicate when to sell a holding from the portfolio. 4.2.4 The Strategy Agent The Strategy Agent is a component which monitors the state of the market and recommends to the Portfolio Agent which stock to purchase and at what price. To this means, the Strategy Agent is equipped with a strategy file describing an entry strategy which the agent should follow. The strategy agent can choose from a list of stocks that are on its “preference list”, a list that is customisable Page 43
  • 48. in order to allow the client to choose which sectors he wishes to invest in. 4.2.5 The Representative Agent And finally, we have The Representative Agent running on the ATS. The representative agent has the role of an execution only brokerage. By running the representative on the ATS we have the possibilities of sending complex orders to the execution only brokerage and transferring the computation associated with them from the brokerage over to the ATS. Once the representative has carried out his task he will respond to the brokerage with either an acknowledgement if the task was successful or an error report if the task was not successful. The representative agent will not be covered in more detail in this thesis. 4.2.6 Component communication Communication in our proposed system is based on the principle of centralised planning. The Portfolio Agent acts as a coordination agent, receiving partial plans from other agents and deciding what actions to take (Wagner 2000). Furthermore, those plans received by the Portfolio Agent are based on information collected and communicated by the meta-agent Information Collector. To address this need of information exchange, we introduce a messaging system. The messaging systems provides a clear way to exchange information for the agents, using standardised representation formats such as the KQML Agent Communication Language (Labrou, Finin et al. 1999). We propose using two layers for the agent communication. The lower layer, layer 5 according to the ISO Open Systems Interconnection reference model [ISO 7498], handles all session control for the agents. This layer is needed to address the problem of authentication and Page 44
  • 49. connection establishment, providing the agents with a seamless communication environment. This way we achieve the illusion of all the agents occupying the same space, and hence enabling all of them to communicate with each other efficiently. (Odell, Parunak et al. 2002) The presentation layer is then reserved for clear text communication using an Agent Communication Language (ACL). This design allows for encrypted communication using the session control layer. Performing encryption on a lower layer frees the agents from having to do any decryption. Figure 6: The protocol for agent communication, KQML, operates in the presentation layer of the ISO stack. 4.2.7 Client portfolios and strategy interactions The Brokerage will be serving many client accounts, analogous to the real world brokerages. Each account will have associated with it at least one portfolio and there will be a number of strategies associated with each portfolio. Since we have all the strategies running as agents in the system, each strategy agent can easily serve a number of portfolios. Each portfolio only has to add an exit monitor for each strategy to its existing collection of exit monitors. Page 45
  • 50. Client Account Portfolio Strategy Figure 7: Each client has at least one portfolio, which in turn runs at least one strategy. The client table includes all information related to the client, and has at least one portfolio. Each portfolio then has at least one strategy, which can be shared with other portfolios. By sharing strategies we achieve optimisation in the strategy evaluation by reducing the number of repeated tasks. 4.2.8 Information tokens As previously discussed, human traders mix and match strategies and try to apply the best one for the given market conditions. Following this methodology, we designed a system which enables us to evaluate strategies with the help of information collectors. Each strategy is expressed as a series of logic expressions, if the expression holds then the associated action is carried out. To provide unlimited extensibility we introduce information tokens. Each logic expression checks whether a set of information tokens, hereafter referred to as tokens, meets the defined criteria. These tokens can be viewed as variables in a mathematical equation which get their value from the information collectors. A token may represent, for example, a moving average for the last X days or any user defined calculation, as long there is an information collector which corresponds to that token request. By allowing the user to introduce his own Information Collectors handling his calculations and information gathering, he can have Page 46
  • 51. the Strategy Agent, and the exit monitor respond to whatever condition he wants. This design adheres to the requirement of running secure code on both the ATS and the brokerage since all the agent communication is sent in clear text through the application layer. Furthermore; we split the strategy into two parts: An entry part handled by the Strategy Agent and then the exit part handled by a set of exit monitors managed by the Portfolio Agent. This way the Strategy Agent registers for the necessary tokens with the Information Agent which informs, and starts up the necessary Information Collectors, and starts screening stocks included in the client’s preference list. When a purchase is made using a certain strategy the holding is added to the portfolio and an exit monitor is informed of the stock. The exit monitor receives his tokens from the Information Collectors and checks whether a sell condition is met for each of the stocks he is monitoring. Once the sell condition is met, he informs the Portfolio Agent which then in turn handles the actual sale of the stock. 4.2.9 Strategy selection technique Having outlined the details of our design in the previous subchapters we now outline our proposed method of strategy selection. The problem faced in this section is how the system will determine which strategy to invest with at any given point in time. To achieve this we re-introduce the virtual portfolios. It is our belief that the best way to keep track of the progress of a strategy is to record all its recommendations in a virtual-portfolio, a portfolio which does not have any real meaning for the client except for serving as a benchmarking tool. Normally, when each strategy finds a potentially profitable stock it recommends it to the appropriate Portfolio Agents, which are Page 47
  • 52. those who are utilising that strategy. That portfolio will consult its money management strategy to check whether an unwanted holding distribution has been reached. If the money management strategy gives a green light for the investment, the investment order is forwarded to the execution only brokerage. Once the execution only brokerage has fulfilled the order, a share certificate is returned along with an acknowledgement of the purchase. The final step is that the portfolio is updated. Figure 8: Which investment strategy to use is decided by the money management strategy looking at each investment strategy’s scorecard and assessing its merits. In our case, we record each recommendation for each strategy into a virtual strategy portfolio. The worth of each of the virtual portfolios can then be calculated and compared on a scorecard object. The money management strategy then determines which strategies to use at any given time, picking it’s strategies from Page 48
  • 53. those who have the highest score on the scorecard. The whole process can be visualised using a block diagram notation, as can be seen in Figure 8: 4.3 Meeting the requirements As we mentioned in section 2.5 there are a number of requirements which our design must meet. We have identified four important categories of requirements and in this section we explain how our proposed design meets those requirements. 4.3.1 Usability and humanity requirements An issue we identified was the need to verify the correct functionality of the entire brokerage. By introducing logging facilities into each of our agents we will be able to trace explicitly and implicitly the execution of each part of the code. The logging facilities should support the most commonly used levels of logging. The most common levels of logging are: • Debugging mode: The log file includes every action and decision made by the software entity being logged. By recording all actions and events, a detailed history of execution can be constructed, which in turn serves as a means of verifying correct functionality of the system. • Detailed Execution mode: The log file includes every business event encountered by the system, so that a semi detailed history of execution can be constructed. This logging mode serves as a means to analyse the interaction between software components as internal execution of the objects is omitted from the log file and instead the logging is focused on the interaction between objects. Page 49
  • 54. • Normal Execution mode: The log file includes all exceptions and errors arising in the system during execution. This logging mode serves the purpose of capturing all abnormal activity and omitting all normal activity, as defined by the designer of the brokerage. This logging mode minimises the overhead of logging, freeing up more of the systems resources for the actual execution of the agents, and their decision making processes. Combining traditional logging facilities with logging at the portfolio level, by keeping a portfolio history database for each client, we are able to support the requirement that the system is deterministic. By this we mean that every action performed by the system is traceable and each effect can be linked with a cause. Another issue surfaced after we identified the need to be able to analyse the system’s actions. The system needs a way to efficiently fix its problems without having to bring the whole system down. We believe that by segmenting our system into software components such as a message router and separate agents, individual components can be duplicated, taken offline and fixed. Once the issue has been solved the duplicate can be replaced without affecting the operation of the entire system. This provides the operators of the brokerage with means to perform software updates and improvements without having to take the entire system off-line, given that the functionality of the updates has been verified in a controlled environment, such as a research lab. Furthermore by introducing modularity we are able to facilitate experimentation and research into our system. For example, by providing a strategy only with a virtual portfolio and disregarding Page 50
  • 55. all recommendations from the strategy agent responsible for that strategy, the user will be able to experiment with new strategies without risking his investments. 4.3.2 Performance requirements After examining the abundance of software and software services available to the general public we are of the opinion that the delays introduced because of the brokerage’s communication with an execution only brokerage is not a limiting factor (TradeStation Group Inc 2004; Equis International 2005; eSignal 2005; Yahoo! 2005). However the question remains, is the delay introduced because of the communication between agents within a brokerage a limiting factor? Even with the most sophisticated high speed Ethernet connections, such as Giga-Bit Ethernet, the answer to the question remains elusive as it is solely implementation specific, and answering that question could be another thesis in itself. As we mentioned in section 2.5.2, it has been pointed out, by Boman and Lybäck that the core systems in the exchange are not allowed to become overloaded. It is our belief that this is not an issue in our design. One of our designs core ideas is to interact with the exchange through a buffer service, such as an execution only brokerage. There are a couple of points that need further elaboration. The original design by Boman and Lybäck was partially based on the principle of locating the ATS next to the core system of the exchange. This would allow for a zero time delay for the agents when interacting with the exchange. The zero delay aspect was one of the driving points of the design as it was seen as means to Page 51
  • 56. encourage investors to use the service, hence allowing the investors to bypass the systematic delay introduced into the system because of the rule of fair dissemination of information. Fair dissemination of information is an agreement ensuring that all those taking part in the stock market have the possibilities of receiving information at the same time, hence eliminating the advantage some investors might have on other investors. Execution only brokerage services are managed by a third party organisation, such as those we have discussed in this thesis. The Agent Brokerage introduces therefore no added strain on the exchange and no code is actually run on or around the exchange. 4.3.3 Cultural and social requirements As we pointed out in section 2.5.3, it is also imperative that the functionality of the electronic exchange continues to be deterministic and that the functionality does not change in any way. By introducing the buffering layer of the execution only brokers and not running any code on the exchange itself our design does not affect the functionality of the exchange. This in turn preserves the trust of the public in the financial institutes, such as the execution brokerages and most importantly the exchange itself. What remains is to establish trust in the public towards an Agent Brokerage, automatically investing their money. We have already discussed means to establish trust in the brokerage in section 2.5.3. 4.3.4 Security requirements We touched on the need for code inspection when discussing security requirements in section 2.5.4. We revisit that discussion here to underline the way our design addresses the code Page 52
  • 57. inspection issue. Code inspection is not an issue in our design as each agent behaves according to instructions stored in a configuration file. The configuration file includes information about which strategies the client wishes to run on the brokerages and how his portfolio should be managed. In more detail, we have introduced the notion of information token processing in the Strategy Agents. The information tokens are products of Information Collectors, which are programmed by a third party and therefore should require code verification. However since the information tokens are ACL formatted messages including data, such as Booleans, numbers or strings, to be processed at the Strategy Agent’s discretion, a global policy can be set regarding how the tokens can be processed and what kind of messages can be processed by the agent. Since the messaging system handles all communication for the agents, the encryption of the communication can be handled by the communication layer. Simply by introducing filters which pass the encrypted message to the socket our design mitigates the risk of a third party eavesdropping on the communication between different parts of the system. We have however not investigated specific encryption techniques as a part of this. Another important point to mention is that if the brokerage malfunctions and tries to execute illegal orders or bring down the exchange all such attempts will be filtered out by the execution only brokerages, who act like a buffer, adding an extra layer of security to the overall process and strengthening the public’s trust in the design. Page 53
  • 58. Page 54
  • 59. Chapter 5 - Concluding Remarks 5.1 Lessons learned The original concept behind this thesis was to expand on the work carried out by previous masters students designing trading agents for the ATS. As our Interactive Systems Engineering degree work at KTH was based upon user driven design, we decided that before looking at the purely technical requirements we should build a good understanding of our wider domain of work. We started by reading a collection of masters theses and development documents obtained from our supervisor on the subject and a few books on stock trading. We spent a month just getting to know what stock broking was really about, the players involved and how they worked. We soon saw that stock trading in general is more related to sociology than to mathematics. The success of our project was dependent on human factors rather than technical. This reinforced our belief that a user-based approach to the subject was more beneficial than a purely theoretical one. We decided to include a user-study as a part of our research phase, which already included reading theoretical books and papers on the subject. We approached a few financial institutions and either met with members of their staff to speak to them and ask them questions regarding their work, or sent out a number of questionnaires. It came apparent that a quick and dirty user study would only probe the surface of the human factor so we added a book on a rather ambitious ethnographic research carried out by a Swedish PhD student to our list of reading material (Hasselström, 2003). Once we were acquainted with how real life stock brokers and traders go about their business, we decided to get better Page 55
  • 60. acquainted with the ATS and the code developed for it by the other masters students. We downloaded the ATS, version 1.0 and had a look at the code. Analysing the code and getting the ATS up and running with a simple home made agent took about four days due to the code modifications needed, and getting the agent package by Jesper and Johansson running on the ATS took a further two days due to lack of documentation regarding the execution of agents. We spent a few weeks learning about trading strategies, what they were, how they were represented in other products and what ways we could potentially express them in our program. We came up with a method, grounded in logic expressions, of expressing complex strategies in a simple way. At this point we started to design an agent which could run on the ATS. We spent about two to three weeks drafting architecture for the agent and two weeks to program a prototype. As we were putting the finishing touch on the agent, ready to start benchmarking the agent we noticed that our design was not suitable due to conflicting requirements regarding security and legal aspects. We revisited an earlier stage in our design phase, the requirement analysis and decided to spend a week on capturing all the non-functional requirements we could think of and capture from the various written sources we had. The outcome of this work was that the focus of the design changed to concentrating more upon an Agent Brokerage which is a supportive execution environment for trading agents. We continued to develop our new idea until we were confident that our design met every requirement noted in our requirement analysis papers. We further spent a week on programming a prototype for the brokerage but it soon came apparent that programming a fully functional brokerage would exceed the timeframe we had for our Page 56
  • 61. thesis which is 20 weeks of work per person. We decided instead of programming an experimental proof-of-concept Agent Brokerage to develop our idea and complete a detailed design up to the level of implementation. Thus anyone who is interested in developing the idea into a product has a solid base to build on. The danger of following a software development model such as the waterfall model is that the developer gets locked in to a set idea and concentrates purely on the technical problems that need to be solved. We could have realistically implemented a trader that was able to choose between multiple strategies and was capable of running on the ATS, the original plan for the thesis research. However, this would be a purely academic exercise as we have discovered that due to the complex non-functional requirements of the financial industry, it would not be viable to use this type of agent in a real world scenario. By taking a human-centred focus on the design we have highlighted many of the requirements and difficulties faced when designing new technology for the financial industry. We have also proposed a possible architecture that we believe would support systematic trading through the use of software agents. 5.2 Conclusion We have developed and presented an Agent Brokerage. The Agent Brokerage was the result of our attempt to design a fully autonomous trading agent running on the ATS developed at SICS. During our design work we noticed that running our design directly on the ATS violated some of the requirements stated by the inventors of the ATS during its development. We have presented our design as a guideline for those who wish to implement such an agent platform. Page 57
  • 62. To be able to consider if we have properly met our initial objectives we can revisit our original goal statements from 1.3: “Our goal with this project is to build an understanding of the requirements and difficulties associated with developing complex agents which can trade alongside their human counterparts on the real stock market” To reach this goal, we performed a number of background researches, namely the “quick and dirty” ethnography research, we sent out a number of questionnaires to banks in Iceland and we did extensive reading on the subjects of stock trading and agent technology. This then enabled us to write a full requirements specification document (see Appendix A). “We will seek to accomplish this by attempting to design an agent capable of investing using an arsenal of different investment strategies“ After having carried out the aforementioned research we came to the conclusion that the single agent approach was not feasible given the complexity of the structure and environment of stock trading. To reach this goal we instead proposed a design for an Agent Brokerage, a concept invented by us to support multi strategy agents trading on the real stock market. “By assessing the financial industry standards, conventions and legal requirements we will consider the barriers to the practical use of agents in the real world and propose robust and secure solutions to overcome these barriers” Page 58
  • 63. By analysing the requirements captured in the previous stage we were able to identify over 75 requirements which would have to be met if any trading platform is to be successful in real life. So we can clearly state that we have reached all aspects of the goals set in the beginning of our work. 5.3 Future work While we have suggested a possible theoretical solution to the issue of running trading agents, there exist many avenues down which our work could be extended. Three suggested further areas of study are included here. 5.3.1 Designing a notification service As mentioned within the thesis, trust plays a large part in the acceptance of any system which involves humans and some kind of trade or exchange of money. It is important for humans to feel in control of what is happening within the Agent Brokerage. The principle used in our design is that of having autonomous agents handle all trades and that takes a high degree of decision making out of the hands of the human. We envisage that by having the agents within the brokerage report important information and facts to the humans, it will increase the trust level between humans and trading agents. Any investigation into a notification service would need to look at factors such as the interaction device for the human and the level of detail of information sent. 5.3.2 Visualisation methods for strategies The Agent Brokerage has the potential to allow the average private investor a new window onto the stock market. The biggest stumbling block for the private investor could be the Page 59
  • 64. implementation of strategies, especially if the method of strategy representation is complex and requires a strong degree of computer programming skills. We have already suggested a Boolean based method to represent relatively complex strategies, but suggest that it may be possible to use information visualisation techniques in order to make the representation of strategies more easily understandable and achievable. We do not wish to influence any further study by making a suggestion in this thesis on how this may be achieved. 5.3.3 Implementation of the design In order to evaluate the effectiveness of our design, the detailed design on paper should be implemented as an actual software system capable of running on a stand alone server. This would allow test agents to be written and executed and would expose many of the technical pitfalls associated with implementing a complex design. As previously mentioned, the authors have carried out work on a detailed design for the Agent Brokerage including the architecture already described and additionally a proposed messaging and agent communication system, logging system, collaboration component and the interaction sequences for each process involved in the Agent Brokerage. The authors would be delighted to hear all comments on our work and from whoever would be interested in taking the concept of the Agent Brokerage forward. We can be contacted through the details shown at the ATS web- page, http://www.sics.se/ATS Page 60
  • 65. References Allgood, B. (2001). "Internet-Based Share Dealing In the new Global Marketplace." Journal of Global Information Management 9(1): 11-15. Almberg, W.-S. (2002). Improved Pricing on the Stock Market with Trading Agents. Department of Computer and Systems Sciences. Stockholm, Stockholm University / The Royal Institute of Technology: 26. Bennett, S., S. McRobb, et al. (2002). Object-oriented systems analysis and design using UML. London, McGraw-Hill. Boman, M. (2004). Accessible Autonomous Software. Vinnova final project report, SICS, Kista, Sweden. Boman, M. and D. Lybäck (2002). Agent Trade Servers in Financial Exchange Systems. ACM Transactions on Internet Technology 4(3): 329-339. Boman, M. and A. Sandin (2005). Implementing an Agent Trade Server. Decision Support Systems, in press. Bonello, F. (2005). Stock Exchange. Encarta Encyclopedia. Brash, D., F. Björck, et al. (2005). Master Thesis Information. D. Brash, Department of Computer and Systems Sciences at KTH/SU. Craver, S. (2005). The underhanded C contest., Binghampton University. Edwards, R. D., J. Magee, et al. (2001). Technical analysis of stock trends. Boca Raton, FL New York, St. Lucie Press, AMACOM. Equis International (2005). Metastock. Salt Lake City: Stock trading software. eSignal (2005). eSignal. Page 61
  • 66. Hasselström, A. (2003). On and Off the Trading Floor: An inquiry into the everyday fashioning of financial market knowledge. Department of Social Anthropology, Stockholm University. Ph.D: 177. Hilmersson, D. (2005). SmartTrader. Stockholm, Mid Sweden University: 85. Homme, C. H. (2005). Heterogeneous Agent Models in Echonomics and Finance. Handbook of Computational Economics. K. L. J. a. L. Tesfatsion, Elsevier Science. 2. Jesper Johansson, M. P. (2003). Agent Shell for Stock Market Systems. Department of Computer and Systems Sciences. Stockholm, Stockholm University / The Royal Institute of Technology: 41. Kagel, J. H. and A. E. Roth (1995). The handbook of experimental economics. Princeton, N.J., Princeton University Press. Katz, J. O. and D. L. McCormick (2000). The encyclopedia of trading strategies. New York, McGraw-Hill. Kendall, G. and Y. Su (2003). A Multi-agent Based Simulated Stock Market - Testing on Different Types of Stocks. Nottingham, University of Nottingham. Kollock, P. (1999). "The Production of Trust in Online Markets." Advances in Group Processes Vol. 16. Labrou, Y., T. Finin, et al. (1999). "Agent Communication Languages: The Current Landscape." IEEE Intelligent Systems 14(2): 45- 52. LeBaron, B. (1998). Agent Based Computational Finance: Suggested Readings and Early Research. Waltham, MA, Graduate School of International Economics and Finance. LeBaron, B. (2005). Agent-based Computational Finance. Handbook of Computational Economics. K. L. J. a. L. Tesfatsion. 2. LSE (2005). London Stock Exchange - Our History, London Stock Exhange. 2005. Page 62
  • 67. NYSE (2005). NYSE, New York Stock Exchange > About the NYSE. Odell, J., H. Parunak, et al. (2002). Modeling Agents and their Environment. AOSE, Bologna, Italy. OMX (2005). Trading systems. Robertson, J. S. (2004). Volere Requirements Specification Template, Atlantic Systems Guild. Schwager, J. (2001). Stock Market Wizards: Interviews with America's Top Stock Traders, Harper Collins. Sherstov, A. A. and P. Stone (2004). Three Automated Stock-Trading Agents: A Comparative Study. Austin, The University of Texas at Austin. SunGard (2005). Front Arena: Stock Trading Platform. Symantec (2004). "Security Response: W32.Swen.A@mm." Semantic Website: http://securityresponse.symantec.com/avcenter/venc/data/w32. swen.a@mm.html. The Economist Newspaper Limited (2000). Going for brokers. The Economist. TradeStation Group Inc (2004). TradeStation, TradeStation Group, Inc.: Stock trading platform. TradeStation Group Inc (2005). "Quarterly Report, Form 10-Q for Tradestation Group." Vanstone, B., G. Finnie, et al. (2004). Applying Fundamental Analysis and Neural Networks in the Australian Stockmarket. Queensland, School of IT, Bond University. Wagner, D. N. (2000). Software Agents Take the Internet as a Shortcut to Enter Society: A Survey of New Actors to Study for Social Theory. First Monday. 5. Page 63
  • 68. Weiss, G. (1999). Multiagent systems: a modern approach to distributed artificial intelligence. Cambridge, Mass., MIT Press: 27-78. Yahoo! (2005). Yahoo Finance, Yahoo! All sources correct as of 8th. of November 2005 Page 64
  • 69. Appendix A - Requirements specification Table of Contents THE PURPOSE OF THE PROJECT II CLIENT, CUSTOMER AND OTHER STAKEHOLDERS III USERS OF THE PRODUCT V MANDATED CONSTRAINTS VIII THE SCOPE OF THE WORK XIII FUNCTIONAL AND DATA REQUIREMENTS XVI USABILITY AND HUMANITY REQUIREMENTS XXXIV PERFORMANCE REQUIREMENTS XXXVI OPERATIONAL REQUIREMENTS XLI SECURITY REQUIREMENTS XLII CULTURAL AND POLITICAL REQUIREMENTS XLV LEGAL REQUIREMENTS XLVI NEW PROBLEMS XLVII Page I
  • 70. A.1 The Purpose of the Project A.1.1 Background of the project effort It is believed that investors in the stock market wish to have the ability to place complex trades which are dependant on a number of conditions being met. To this end the introduction of an Agent Trading Server (ATS) was proposed. We suggest an elaboration of this concept, extending it to create an Agent Brokerage where agents can make decisions on the stocks to buy and sell and then execute the trade through a stock market interface such as the ATS. The motivation with the project is to create a new method for institutional and private investors to access the stocks markets and increase their ability to execute complex trades and strategies. It is believed that investors in the stock market wish to have the ability to place complex trades which are dependant on a number of conditions being met. A.1.2 Goals of the project Our goal with this project is to examine and develop a framework to run a trading agent which can run multiple strategies simultaneously and trade on the stock market. Page II
  • 71. A.2 Client, Customer and other Stakeholders A.2.1 The client The Agent Brokers Ltd. We envisage the client as a body which wants to set up the Agent Brokerage and wants a full system design up to the stage of implementation. By taking the role of system engineers who do the design and then pass it off to programmers, we need to look at all the information a programmer would need to be able to carry out the implementation. A.2.2 The customer We see this section as either individual or institutional investors. These are two quite different groups. The customer for the institutional investor group is likely to be an office manager or head of investment software procurement. The institutional investor company has greater resources at his disposal so may be able to have people employed writing complex strategies in a format that is very powerful with regards to our system. They may also have publicly undisclosed information that they want to interact with. The individual investor is likely to be less sophisticated; with less complex strategies that he would like to program is some kind of Easy Language script. Both could be supported using the same architecture, but perhaps different interfaces. A.2.3 Other stakeholders The programmers of the system: The implementers of the design. This group needs system architecture and detailed design in order to build the product. Page III
  • 72. Financial Standards Authorities: The bodies which set standards within the financial industry to ensure fairness and consumer safety. We have to be aware of what these standards are, potentially varying from market to market. These standards are legal requirements that the system must meet. Legal Experts: Our system cannot leave the company open to prosecution or legal action for unforeseen circumstances arising from use or misuse of the system ATS or other interface to the real stock market: Some manner of interfacing to the stock market, initially proposed to be via the ATS though potentially to be fulfilled by an internet based execution only brokerage service. Whatever interface is used; it is likely to be an existing standard, so we have to understand the format and characteristics of this and allow for our system communicating with it. Third party information providers: Already existing and trusted information providers in a variety of formats. They will not change to accommodate the Agent Brokerage, so the interface has to be able to support the Agent Brokerage processing data from them. Third party developers: Third party developers of strategies. Allow it to be possible for the structure of the system to encourage third party developers to convert clients own strategies into executable code. Page IV
  • 73. A.3 Users of the Product A.3.1 The hands-on users of the product User name/category: Private Investor. User role: Responsible for either creating his own, or choosing from a selection of, suitable strategies to meet his investment preferences. Responsible for managing his own bank accounts etc. Subject matter experience: Most likely a seasoned investor, but unlikely to be proficient in programming of agents. Technological experience: Would be comfortable with computers, used to scripting in simple language, but not necessarily able to program with any complexity. Other user characteristics: Intellectual abilities/disabilities: Likely to be relatively well educated or experienced. Attitude to technology: Likely to be favourable to technology. Education: College/University Gender: Probably Male User name/category: Institutional Trader. User role: Responsible for either creating his own, or choosing from a selection of, suitable strategies to meet his investment preferences. Investment strategies may be implemented by others within the organization. Responsible for managing accounts of their institution and/or the institutions clients. Subject matter experience: Most likely a seasoned investor, but unlikely to be proficient in programming of agents. Page V
  • 74. Technological experience: Would be comfortable with computers, used to scripting in simple languages, but not necessarily able to program with any complexity. Other user characteristics: Intellectual abilities/disabilities: Likely to be relatively well educated or experienced. Attitude to technology: Likely to be favourable to technology. Education: University education/Business degree Gender: Probably Male A.3.2 The priorities assigned to users This section lists the priority of potential users and other stakeholders in the system. Key users: • Private Investor • Institutional trader • Managers and supervisors Secondary users: • IT staff • 3rd party developers writing plug-in and modification Tertiary users: • Hackers Page VI
  • 75. A.3.3 User participation Key users: • Private Investor needed for usability testing and requirement capture and marketing. • Institutional trader needed for usability testing and requirement capture and marketing • Managers and supervisors needed for usability testing and requirement capture and marketing Secondary users: • IT staff needed for usability testing and requirement capture. • 3rd party developers writing plug-in and modification needed for design participation and tool development, likely done in-house. Unimportant users: • Hackers, needed to verify the consistency and integrity of our code. Can be used to discover security issues and problems. A.3.4 Maintenance users The following is a list of maintenance users: • System administrators: Those responsible for the servers and the operating systems running on them. These guys can either be members of the clients IT department or outsourced. Page VII
  • 76. • Server administrators: Those responsible for managing the software we are proposing. They will have to administer databases, maintenance jobs for the system and start and stop the system In many cases these roles can be assumed by the same persons or a team of persons. A.4 Mandated Constraints A.4.1 Solution design constraints Following is a list of solution design constraints within which the system lies. • The solutions communication facilities must use established protocols and standards as appropriate. • The solution must be able to interface with existing information sources/providers, such as Yahoo!, Reuters and Bloomberg. • The solution must be able to interface with databases existing within the clients IT system. • The solution must use existing technology to access the market. A.4.2 Implementation environment of the current system A suggestion of the implementation environment can be seen on Figure 9: Page VIII
  • 77. Terminal Status monitor Solution LAN Client firewall Internet Roluter Stock exchange ATS Firewall High speed LAN Figure 9: Shows the distribution of the system segments across many locations, but connected through the internet. The environment will consist of the following items • Stock Exchange: The software running the exchange is responsible for bid matching. This is the core of the stock market and the correct deterministic behaviour of the software must be guaranteed and cannot be interfered with. • ATS: The ATS is the solutions interface to the exchange. The ATS interacts with the exchange on the solutions behalf. • Firewalls: Firewalls handle access control and serve the purpose of keeping unwanted and unauthorized entities out of the system, such as hackers and other mal-intentioned individuals or organizations. Page IX
  • 78. • Routers: The routers connect the solution to the internet. The routers are assumed to be of industrial grade providing standardized routing algorithms and interfaces. • Internet: Handles message transmission can be replaced with a dedicated communications link such as a dark fiber connection. • The Solution: A piece of software running multiple stock trading strategies simultaneously. • Terminals: Users interact with the solution running client software; all primary and secondary users will interact with the solution through terminals. An exception to this will be home-users who might interact with the solution through a web interface. • Other devices: (Such as a big-screen) display information from the stock market and the status of the solution. A.4.3 Partner or collaborative applications The following is a list of collaborative and or partner applications • The ATS: Provides the solution with an interface to the stock market. • Information providers: Such as Yahoo!, Bloomberg and Routers. Provide HTML access or web service access to information regarding stock prices, including delayed or real time data about prices, historical data and more. • Data sources: Client provided data sources include data which the client has prepared for his trading. The solution must interface with those data sources and make them interpretable by the mechanism running the strategies. • News sources: Human readable news sources such as CNN.com Routers.com and more. The system will interface with 3rd party applications interpreting these news sources and providing business events. Page X
  • 79. A.4.4 Off-the-shelf software There is a number of off-the-shelf software which will implement some of the functionality of the solution • Databases: Clients may have different types of databases in-house which they want to use for making trading decisions. • Web services: Information providers may have web services available to the solution • Analysis software: There is a great deal of 3rd party software available which carries out varied analysis tasks. This software has a wide variation of interfaces A.4.5 Anticipated workplace environment Following is a description of the anticipated workplace environment for users of the solution. Key users: • Private Investor will work at home. • Institutional trader will work in regular offices; have their desk and everything handy. Stress levels might be higher than in a typical office due to the speed and high stakes of the business. • Managers and supervisors, usually work in the same environment as their subordinates, but affected by different things. Secondary users: • IT staff, regular offices and/or service areas or server rooms Page XI
  • 80. • 3rd party developers writing plug-in and modification, regular offices Tertiary users: • Hackers, wherever they can get their hands on computers… A.5 Relevant Facts and Assumptions A.5.1 Assumptions that the team is making about the project • The solution will run in a complex environment consisting of different information sources, responsibilities and architectures. • We assume that there will be an execution only brokerage available for our solution. • The solution will interface with a non-advisory execution only brokerage, implemented in this project using the ATS designed by Magnus Boman and implemented by Anna Sandin. • We assume that most of the plug-in development will be carried out by 3rd party developers. • We assume that the only trading done will be in buying a share of stock in a company on the stock exchange and selling it in the future at an anticipated higher price (also known as “going long”). This is the definition of placing a trade in our work. Page XII
  • 81. A.6 The Scope of the Work A.6.1 The current situation Current systems used by institutional traders consist of portfolio management software, stock price monitors and an order monitor along with messenger software, internet forums and other web pages. The interface is usually very complex, requiring a number of monitor streams for each trader, which the trader must monitor almost constantly. Analysis is usually carried out by a team of experts in a back office. They use analysis software commercially available to identify which stock to trade in. Stock brokers place the order on the stock exchange. They receive instructions from the traders, who base their work on analysis performed by the analysts. A.6.2 The context of the work The following diagram shows how the data flows between players in the existing stock market. Page XIII
  • 82. Recomendations for traders Analyst Price information Analysis from information providers Stock data Stock exchange Stock buy/sell orders Trading information Information News provider Financial reports Analysis information Buy/Sell orders Broker Trading instructions Recomendations for traders Stock Trading Context Stock prices Trader Broker instructions Stock recomendations Evaluation of trader Manager performance Trader performance Puts presure on trader Client Invest Returns Financial services Provide regulations authorities Figure 2: The arrows show data coming in and being given out by each player in the current stock exchange Page XIV
  • 83. A.6.3 Work partitioning Following is a business event list for the process of trading stocks Event name Input / Output 1. Analyst recommends stock to Stock recommendation (out) trader based on information Stock prices (in) analysis News (in) 2. Trader instructs broker on what Recommendation (out) stock to buy Analysis (in) Stock prices (in) 3. Broker places orders for Recommendations from buying stock trader (in) Stock prices (in) Buy order (out) 4. Broker places order for selling Recommendations from stock trader (in) Stock prices (in) Sell order (out) 5. Manager evaluates trader Portfolio development (in) performance 6. Stock exchange sells stock Stock sale order (in) Acknowledgement (out) Return (out) 7. Stock exchange buys stock Stock purchase order (in) Payment (in) Acknowledgement (out) Contract note (out) 8. Information provider performs Stock prices (in) analysis News (in) Trading information (in) Analysis (out) 9. Regulation by financial Market conduct (in) services authority Regulation (out) Page XV
  • 84. A.7 Functional and Data Requirements A.7.1 Functional Requirements General system requirements Requirement 1 Type: Functional Use case number: number: Description: Parts of the system must be able to communicate different things in a standardized manner Rationale: As the complexity of the system increases, parts of the system must be able to communicate their state to other collaborating parts. Source: Fit criterion: Messages are sent from one sub-system to another Requirement 2 Type: Functional Use case number: number: Description: The system should model the different channels of information flow. Rationale: Since strategies can be based on evaluating different kinds of data, different kinds of data must be available in standardized formats. Source: Fit criterion: Decisions can be made based on information from various sources. Requirement 3 Type: Functional Use case number: number: Description: The system must provide a way to measure it’s performance Rationale: Success measurement on today’s stock market is relatively simple. The value of the portfolio has either increased or decreased compared to its original value. If the value has increased you have “won” Source: Daniel Hilmersson: Smart trader v4.0 Fit criterion: It is possible to go check how each strategy is performing. Page XVI
  • 85. Requirement 4 Type: Functional Use case number: number: Description: The system must provide a proper way to process contingency orders Rationale: Only the core of the exchange system can guarantee deals involving more than one trade. The system offers the same possibilities as other systems. There is an external monitor monitoring the state of the market and injecting orders when the specified conditions are met. Source: Lybäck and Boman: Agent trade servers in Financial exchange systems Fit criterion: Ability to process contingency orders. Portfolio Following are functional requirements related to the portfolio. Requirement 5 Type: Functional Use case number: number: Description: The system must provide a way to add holdings to a portfolio Rationale: After the purchase of a stock, the Actual Portfolio has to be updated to contain the name, ticker, quantity, (average?) buy price, current price and the strategy name that recommended it. Any recommended stock has to be added to the Virtual Portfolio for the strategy that recommended it, so that the strategies can be evaluated. Source: Brainstorming session Fit criterion: The actual portfolio contains all transactions; the Virtual portfolio contains all virtual transactions. Page XVII
  • 86. Requirement 6 Type: Functional Use case number: number: Description: The system must provide a way to remove a holding from a portfolio Rationale: Both upon a Virtual and an Actual sale, holdings must be added to a portfolio. Source: Brainstorming session Fit criterion: Upon selling stock holdings are removed from the Actual portfolio. Requirement 7 Type: Functional Use case number: number: Description: The system must record Portfolio History Rationale: It is important to have a record of all past purchases and sales from each portfolio, not just the current contents, but all transactions. This allows analysis of the investment strategies and calculation of overall worth Source: Fit criterion: All transactions made within a portfolio can be reviewed and even recreated. Requirement 8 Type: Functional Use case number: number: Description: The system must provide a way to calculate the worth of each portfolio Rationale: The worth of an Actual portfolio must be calculated so that the client can see how much his holdings are worth. The worth of a virtual portfolio must be calculated so that it can be compared to other virtual portfolios for performance measurements. Source: Brainstorming session Fit criterion: The complete worth of a portfolio can be calculated correctly, according to standards and regulations, reflecting the total worth of all holdings. Page XVIII
  • 87. Requirement 9 Type: Functional Use case number: number: Description: The system must provide a way to Compare Portfolios Rationale: In order to evaluate which strategy is the most acceptable to use when investing for the Actual Portfolio, the various Virtual Portfolios must be able to be compared. This may not necessarily be just a comparison of total value, but also of factors such as volatility. Especially important for Virtual portfolios. Source: Fit criterion: The value of a portfolio can be compared to the value of another portfolio to find out which one is worth more. Entry strategies Following are functional requirement related to entry strategies Requirement 10 Type: Functional Use case number: number: Description: The system must provide a way for an entry strategy to report its findings Rationale: Once an entry strategy finds stocks suitable for investing in it must inform whomever responsible for implementation of transactions of it. Source: Brainstorming session Fit criterion: Each time a strategy finds an appropriate stock to invest in, the subsystem responsible for making the actual trade is informed of this finding. Page XIX
  • 88. Requirement 11 Type: Functional Use case number: number: Description: Logging, The system must keep a history of all actions, exceptions and errors of the entry strategy. Rationale: The correct functionality of the entry strategy must be verified. This can be achieved through logging. Source: Brainstorming session Fit criterion: Each step made by the entry strategy can be traced using a history record. Strategies Requirement 12 Type: Functional Use case number: number: Description: The system must represent strategies in an efficient manner. Rationale: Strategies will have to be presented in a manner which allows for human understanding and machine processing. Source: Brainstorming session Fit criterion: A standardized, human understandable form of strategies can be processed by the system. Page XX
  • 89. Requirement 13 Type: Functional Use case number: number: Description: The system must be able to evaluate whether a strategy has been fulfilled or not. Rationale: Strategies are based on a series of checks. In general, if all of these checks are met a specified action is carried out. Source Brainstorming session Fit criterion When the data for a stock meets the checks set by a strategy the strategy will trigger an associated action, be it purchase the stock or sell it. Exit Strategies Following are requirements specific to exit strategies Requirement 14 Type: Functional Use case number: number: Description: Logging, The system must keep a history of all actions, exceptions and errors of the exit strategy. Rationale: The correct functionality of the exit strategy must be verifiable. This can be achieved through logging. Source Brainstorming session Fit criterion Each step made by the exit strategy can be traced using a history record. Page XXI
  • 90. Requirement 15 Type: Functional Use case number: number: Description: The exit strategy must have a way to report its findings to the subsystem responsible for making transactions. Rationale: The exit strategy only sees whether a series of conditions have been met, the actual exit decision must propagate through the decision making layers. Source: Brainstorming session Fit criterion: Whenever an exit strategy is triggered, the message is sent to the subsystem responsible for placing the actual order. Requirement 16 Type: Functional Use case number: number: Description: The exit strategy must be able to monitor data for the stocks in the portfolio. Rationale: Decisions regarding the sale of a stock form the portfolio are made based to the market status and development. Source Brainstorming session Fit criterion When the current and past prices of stock are in a certain way the exit strategy is triggered Investment strategy Requirement 17 Type: Functional Use case number: number: Description: The system must implement Money Management techniques Rationale: Money management is the technique for distributing ones holdings in a favourable way. Source: Brainstorming session Fit criterion: The sought after distribution of holdings is achieved. Page XXII
  • 91. Requirement 18 Type: Functional Use case number: number: Description: The system must implement Risk Management techniques Rationale: Risk management provides a way to distribute ones holdings between different stocks achieving the desired total risk level of ones investments, not betting everything on red. Source: Brainstorming session Fit criterion: The required distribution of holdings is achieved. Requirement 19 Type: Functional Use case number: number: Description: The system maintains a preference lists for stocks Rationale: Some might be interested in a subset of stocks, a specific market etc. or not interested in others. Source: Brainstorming session Fit criterion: The stocks examined and purchased/sold belong to the preference list. Research Requirement 20 Type: Functional Use case number: number: Description: The system must provide a way to get stock prices for stock symbols Rationale: Current stock prices from a third party or private source. Needed to allow the entry strategies to make decisions on the best stocks to recommend and for the exit strategies to see when they have been triggered. Source: Fit criterion: A strategy can decide to take action based on stock prices. Page XXIII
  • 92. Requirement 21 Type: Functional Use case number: number: Description: The strategy has to be able to evaluate stock prices Rationale: The actions of the strategy might depend on the current or past price of the stock. Source: Brainstorming session Fit criterion: The strategy can obtain the necessary prices for the stock. Requirement 22 Type: Functional Use case number: number: Description: The system must provide a way to get information from News Sources Rationale: Not statistical or technical data, but data that is created primarily for human researchers. This is wide varying and could range from a news agency story (for example, BBC, CNN) or a press release from a company or government agency. Source: Fit criterion: Strategies can make decisions based on news events. Requirement 23 Type: Functional Use case number: number: Description: The system must provide a way to perform Technical Analysis Rationale: Technical analysis is carried out as a method of picking stocks by looking purely at the trends and indicators of their recent stock price and without regard for any knowledge about the actual company or its underlying worth in real world terms. Source: Fit criterion: Strategies can make decisions based on technical analysis Page XXIV
  • 93. Requirement 24 Type: Functional Use case number: number: Description: The system must provide a way to perform fundamental analysis Rationale: Fundamental Analysis looks at the financial reports and other available information on a company’s underlying performance and worth. Fundament Analysis can be used to try and evaluate companies’ actual worth at any time to try and assess what the share price should be. Fundamental analysis can be wide reaching, involving the assessment of a company’s suppliers, customers and potential for growth. Source: Fit criterion: Strategies can make decisions based on fundamental analysis Requirement 25 Type: Functional Use case number: number: Description: The strategy must be able to obtain historical data for a stock. Rationale: The strategy might be based on technical analysis techniques based on calculations based on historical data that stretches over periods in the past. Source: Brainstorming session Fit criterion: Data can be obtained spanning numerous days, in standardized format. Page XXV
  • 94. Requirement 26 Type: Functional Use case number: number: Description: The system must provide a way to evaluate historical data. Rationale: Historical Data is needed for technical analysis. It is simply all the recorded data on a companies share price, traded volume, maximums, minimums etc. Historical data is normally presented in technical analysis as either intra day (the performance of a stock throughout a trading day), or end of day (the opening/closing/max/min prices and volume for a period of historical trading days). Source: Fit criterion: Historical data can be used for technical analysis Requirement 27 Type: Functional Use case number: number: Description: The system must provide a way to evaluate Fundamental Data Rationale: These are the data items used to evaluate the worth, growth potential etc of a company. These are things such as quarterly or end of year financial statements and reports, sales figures, wage figures etc. Source: Fit criterion: Data from fundamental analysis can be used for trading. Page XXVI
  • 95. Sell Stock Requirement 28 Type: Functional Use case number: number: Description: The system must provide a way to create regular sales orders Rationale: Regular orders are probably when a sell trigger is met, the portfolio manager is told to make a sell execution and it is executed. Source: Fit criterion: The system can place standardized sell orders for single stock. Requirement 29 Type: Functional Use case number: number: Description: The system must provide a way to create complex sales orders Rationale: A complex order is likely to be orders which depend on another action such as an earlier trade being executed at a predefined price before it will be executed. Source: Fit criterion: The system can place complex orders. Requirement 30 Type: Functional Use case number: number: Description: The system must provide an exit strategy. Rationale: Exit strategies should cover the three ways of completing an investment. These are, Exit for Period, Exit for Loss and Exit for profit. Depends on the research requirements. Source: Fit criterion: The system can decide when it should sell stock Page XXVII
  • 96. Requirement 31 Type: Functional Use case number: number: Description: The system must provide a way to send an acknowledgement of sale. Rationale: We must receive a notification that the sale has went through before the stock is removed from the portfolio. Otherwise, the portfolio would still own the stock but think that it does not. Source: Fit criterion: Once a sale has been carried out, a message acknowledging the sale is sent out to all relevant systems. Requirement 32 Type: Functional Use case number: number: Description: The system must provide a way to pay a brokerage fee Rationale: There will be some fee for either selling or buying a stock. This fee must be taken into account through money management. The fee could be fixed or dependant on the volume of stock. This can depend on what country or market i.e. most stocks in the US cost $ while in the UK they cost X p. Source: Fit criterion: The account associated with the portfolio is credited the appropriate amount. Page XXVIII
  • 97. Buy Stock Requirement 33 Type: Functional Use case number: number: Description: The system must provide a way to create complex purchase orders Rationale: A complex order is likely to be orders which depend on another action such as an earlier trade being executed at a predefined price before it will be executed. Source: Fit criterion: Complex purchases have to be executed as planned. Requirement 34 Type: Functional Use case number: number: Description: The system must provide a way to create regular purchase orders Rationale: Regular orders are probably when a selector strategy recommends an order, the investment strategy agrees and it is executed in an orderly fashion. Source: Fit criterion: Regular purchases have to be executed as planned. Requirement 35 Type: Functional Use case number: number: Description: The system must provide one or more entry strategies Rationale: The system has to be able to select/filter stocks following some predefined strategy. Entry Strategies should recommend investment opportunities to the portfolio manager. Source: Fit criterion: Multiple entry strategies. Page XXIX
  • 98. Requirement 36 Type: Functional Use case number: number: Description: The system must provide a way to decide how many stocks to buy Rationale: From money management techniques, the amount to risk in any one investment should be known. By calculating the current buy price (perhaps quoted) then we should know the quantity of shares to be ordered. Source: Fit criterion: Awareness of the amount of cash, shares available and possible buy quantities. Requirement 37 Type: Functional Use case number: number: Description: The system must provide a way to update portfolio Rationale: Same as add holding. After the purchase of a stock, the Actual Portfolio has to be updated to contain the name, ticker, quantity, buy price, current price and the strategy name that recommended it. Any recommended stock has to be added to the Virtual Portfolio for the strategy that recommended it, so that the strategies can be evaluated. Source: Fit criterion: Portfolio is always up to date. Requirement 38 Type: Functional Use case number: number: Description: The system must provide a way to get acknowledgement of purchase. Rationale: We must receive a notification that the purchase has went through before the stock is added to the portfolio. Otherwise, the portfolio would own the stock but think that it does not. Source: Fit criterion: Portfolio is always accurate. Page XXX
  • 99. Security Requirement 39 Type: Functional Use case number: number: Description: Privacy Rationale: No entity should be able to interfere with or view data belonging to a separate entity or client. Source: Fit criterion: Information about a user and his affairs are only available to that user Requirement 40 Type: Functional Use case number: number: Description: Encrypted Communication Rationale: Ensure that no-one can listen in. Regular packet sniffers can be used to listen in on data transmission, encryption will make sure that the data contained in those packages is not readable to humans or other entities. Source: Fit criterion: Messages sent back and forth between systems are not readable by 3rd party. Requirement 41 Type: Functional Use case number: number: Description: Integrity, the integrity of the code must be insured. Rationale: The integrity of code must be verifiable, so that malicious code cannot be masqueraded as innocent code. Source: Fit criterion: Code cannot be modified without permission. Page XXXI
  • 100. A.7.2 Data requirements Requirement 42 Type: Data Use case number: requirement number: Description: The system must maintain at least one actual portfolio for keeping track on actual investments. Rationale: The system has to use multiple types of portfolios; some are to keep track of actual investments while others are used to keep track of virtual investments. Source: Brainstorming session Fit criterion: An Actual portfolio reflects actual investments made by the system, and has its contents changed appropriately when holdings are added or removed. Requirement 43 Type: Data Use case number: requirement number: Description: The system must maintain one Virtual portfolio for each of the strategies running in parallel. Rationale: Virtual portfolios are used to keep track of each strategies performance. Each recommendation made by the strategy is entered as a virtual transaction to the portfolio Source: Brainstorming session. Fit criterion: A Virtual portfolio reflects all transactions recommended by a strategy. Enables the evaluation of the worth of the portfolio recommended by the strategy. Page XXXII
  • 101. Requirement 44 Type: Data Use case number: requirement number: Description: Each Portfolio, Virtual and Actual, must have zero or more holdings. Rationale: Holdings represent the amount of stock owned by the user Source: Design session Fit criterion: Holding represents all vital information about stock, the price it was bought on, the amount of shares bought, the date it was bought on etc. Requirement 45 Type: Data Use case number: requirement number: Description: The system can have numerous user accounts Rationale: An user account represents a system user and all his vital information Source: Design session Fit criterion: The system contains all necessary information about a user, contact and billing information. Requirement 46 Type: Data Use case number: requirement number: Description: The system will have a list of preferred stocks for each Actual portfolio Rationale: The preference list tells the system what stocks should be considered for a particular portfolio Source: Design session Fit criterion: For each portfolio, the system only trades in stocks included in its preference list. Page XXXIII
  • 102. A.8 Usability and Humanity Requirements The system is to be used by human users, so the limitations and requirements of humans are considered in this section. Requirement 47 Type: Use case number: number: Description: The system should make it clear what responsibilities lay where and what each components responsibility is. Provide a clear semantic Rubicon. Rationale: The design of a complex extendible system must provide clear boundaries for the responsibility and functionality of its parts so that modifications and changes can be made without interfering with the correct operation of other parts of the software. Source: Fit criterion: The software supports the user building a correct mental model of the system and its boundaries. A.8.1 Ease of use. Requirement 48 Type: Use case number: number: Description: The system must provide a clearly understandable and transparent way to express strategies Rationale: The system will be running a number of strategies, which must be analyzed and modified during the course of their execution. Source: Fit criterion: Ability for non-expert users to express strategies. Page XXXIV
  • 103. Requirement 49 Type: Functional Use case number: number: Description: The system must provide ways to analyze its actions. Rationale: If a trader makes a mistake, very few conclusions can be drawn to avoid a similar situation the next time, as there is no clearly defined next time. Logging all actions of the software can enable the software to identify that next time and avoid the mistakes. Source: Lybäck and Boman: Agent trade servers in Financial exchange systems Fit criterion: The actions of the system can be traced. Requirement 50 Type: Functional Use case number: number: Description: It shall be clear for the end user when his software/service is not running. Rationale: Agent owners might think that their agent is running but because of some unknown problem it might not be. The agent’s owner must be able to know whether his agent is running, and if not, he should be able to find out why the agent is not running. Source: Lybäck and Boman: Agent trade servers in Financial exchange systems Fit criterion: The end user can clearly see that his software is not trading on the market Requirement 51 Type: Use case number: number: Description: The system must serve as a support mechanism for humans. Rationale: Humans participate in the market. Humans are the users and the stakeholders in the use of the system. Source: Johansson and Poijes: Agent shell for stock market systems Fit criterion: Human investors have a new way to access the stock exchange. Page XXXV
  • 104. A.8.2 Ease of learning. Requirement 52 Type: Use case number: number: Description: The system must facilitate experimentation and research. Rationale: Although in the beginning the system will employ a few archetypal agents, it is not unreasonable for the user to expect some customizability and means to experiment within the system Source: Lybäck and Boman: Agent trade servers in Financial exchange systems Fit criterion: Strategies can be run without performing actual trades involving real money or the real stock exchange. A.9 Performance Requirements A.9.1 Speed and latency requirements Requirement 53 Type: Use case number: number: Description: The system must be flexible to changes in its environment. Rationale: “The system must withstand variable load, various failures in supporting systems, faulty user commands et cetera, and must not by erroneous internal actions cause serious economic damage to the participants of the exchange.” From source. Source: Lybäck and Boman: Agent trade servers in Financial exchange systems Fit criterion: System is rugged and reliable. Page XXXVI
  • 105. Requirement 54 Type: Use case number: number: Description: The system must enable near-real time propagation of information. Rationale: “A real-time scenario trigger must evaluate the current market situation within specified timing constraints, quite short-termed, possibly slightly trading-off the quality of its own analysis if needed. Thus, even the trigger in itself is under Quality-of-Service control.” From source. Source: Lybäck and Boman: Agent trade servers in Financial exchange systems Fit criterion: No delays which cause data to be possibly lagged with regards to other stock market information channels. A.9.2 Precision or accuracy requirements Requirement 55 Type: Use case number: number: Description: The system must offer exact accurate prices and market data. Rationale: Decisions are made based on the data flowing into the system. This data must be accurate with regards to the real market values or the decisions could be erroneously made. Source: Design Session Fit criterion: Use trusted and proven market data suppliers. A.9.3 Reliability and Availability requirements Requirement 56 Type: Use case number: number: Description: Availability. The system must be available and running at appropriate times. Rationale: “If the system is not running it cannot capture market events and/or perform the necessary calculations needed for optimal operation.” From source Source: Johansson and Poijes: Agent shell for stock market systems. Fit criterion: Real-time, always-on system. Page XXXVII
  • 106. Requirement 57 Type: Use case number: number: Description: The financial exchange must be completely tractable, as it is a real time system. Rationale: The financial exchange is a real time system used by many at the same time. Because of convention in addition to legal and trust issues, the functionality of the exchange must be deterministic and tractable. Source: Lybäck and Boman: Agent trade servers in Financial exchange systems Fit criterion: The financial exchange’s performance does not degrade upon activating the additional services Requirement 58 Type: Use case number: number: Description: Software running on core systems must not overload them. Rationale: “It should be noted that agent/server communication also has its own set of problems. An agent server is under constant threat of overload, due to malicious intent or bad agent code.” From source. Source: Lybäck and Boman: Agent trade servers in Financial exchange systems Fit criterion: The core systems resources are not reduced or compromised. Requirement 59 Type: Use case number: number: Description: All code running on the ATS must be inspected and its functionality verified before it can be run. Rationale: “The sheer amount and variability of the code running on an agent server makes code verification a practical impossibility. It is not acceptable in a high stakes environment such as the banking/stock broking environment that supporting systems cause people to loose money.” From source. Source: Lybäck and Boman: Agent trade servers in Financial exchange systems. Fit criterion: Malicious agents cannot interfere with properly designed agents. Also just inefficiently written agents or “Monster” agents who disrupt the system. Page XXXVIII
  • 107. Requirement 60 Type: Use case number: number: Description: One trade agent is not allowed to interfere with the execution of another trade agent Rationale: “It is vital that an add-on service that executes according to best-effort does not in any way compromise the overall ambition of a fair and orderly marketplace.” From source Source: Lybäck and Boman: Agent trade servers in Financial exchange systems. Fit criterion: Malicious agents cannot interfere with properly designed agents. Requirement 61 Type: Use case number: number: Description: The functionality of the system cannot be degraded because of congestion and bottlenecks Rationale: “Overhead because of communication or redundant calculations must be minimized. Network congestion is (to a reasonable extent) avoided through the use of dedicated leased lines to the exchange system gateways.” From source Source: Lybäck and Boman: Agent trade servers in Financial exchange systems Fit criterion: The system can withstand reasonable loads without loading down. Requirement 62 Type: Use case number: number: Description: The system must be tolerant for hardware failures. Rationale: “Fault tolerance techniques provide services compliant with the specification after a fault has occurred. For hardware errors, or catastrophic situations like flooding or fire, exchange systems provide hot fail-over mechanisms (based on active replication), i.e. a hot standby replica is ready to take over in a very short time after a serious problem occurred in the primary site.” From source. Source: Lybäck and Boman: Agent trade servers in Financial exchange systems Fit criterion: Ability to not be reliant on single hardware locations and devices. Page XXXIX
  • 108. Requirement 63 Type: Use case number: number: Description: The system must be tolerant for software failures Rationale: “Fault tolerance techniques provide services compliant with the specification after a fault has occurred. For hardware errors, or catastrophic situations like flooding or fire, exchange systems provide hot fail-over mechanisms (based on active replication), i.e. a hot standby replica is ready to take over in a very short time after a serious problem occurred in the primary site.” From source Source: Lybäck and Boman: Agent trade servers in Financial exchange systems Fit criterion: The system cannot be reliant on a single software entity. Requirement 64 Type: Use case number: number: Description: The system must provide exception handling. Rationale: “Exception handling deals with the undefined and unanticipated conditions that, if left unchecked, can propagate through the system and cause a serious fault. Self verifying software is an ad hoc method used in many important systems already deployed in our society, including electronic exchange systems, phone switches, and aircraft. A typical exchange system uses a rollback procedure from disk-based transaction logs for a restart, and in problematic cases, the operations staff must identify and (technically) nullify the transaction causing the problem, to enable a successful restart of the system.” From source Source: Lybäck and Boman: Agent trade servers in financial exchange systems Fit criterion: Follow good software engineering practices and exception handling techniques. Page XL
  • 109. A.10 Operational Requirements A.10.1 Expected physical environment The product will be used in an office environment or in a home office. The server will be kept in a server room and serviced by experienced personnel. A.10.2 Expected technological environment Clients will run on a windows machine or through a web interface. The server will run in a Microsoft environment. The web interface may eventually run on a UNIX machine or a machine running an UNIX clone. A.10.3 Partner applications There are various third party content providers public and private which may be required to be interfaced with. These are primarily existing services with existing interfaces. Our product must be able to interface with these in a precise and stable manner. It is unfeasible to provide a data providing service which outperforms and is more suitable than the existing providers. Our product must be able to utilize these existing channels of data. Page XLI
  • 110. A.11 Security Requirements A.11.1 Access requirements Requirement 65 Type: Use case number: number: Description: Management and those responsible for the exchange must be able to verify the integrity of the code running on the exchange. Rationale: How can agent developers be certain that no one has changed the preferences of the agent? Source: Johansson and Poijes: Agent shell for stock market systems. Fit criterion: Method of verifying code authenticity post and prior to any execution. Requirement 66 Type: Use case number: number: Description: Authentication, ATS-administrator must be able to authenticate agents and be convinced that the agent code comes from the source that is claimed. Rationale: Mal intentioned actors or stakeholders could masquerade as other stakeholders to sabotage the ATS or cause problems on the ATS. Source: Johansson and Poijes: Agent shell for stock market systems. Fit criterion: Method of verifying code authentication, post and prior to any execution. Page XLII
  • 111. Requirement 67 Type: Use case number: number: Description: Confidentiality. How can the agent developer be certain that no one has examined the preferences of the agent during transaction to the ATS? Rationale: “In today’s marketplace, the technology and technique used by different traders are very valuable and can aid in beating the market. Therefore it is important to stakeholders that the preferences and configuration of their agents don’t fall in the hands of the competitor, destroying their competitive advantage.” From source Source: Johansson and Poijes: Agent shell for stock market systems. Fit criterion: Privacy and segmentation of code so that it cannot be eavesdropped upon. A.11.2 Integrity requirements Requirement 68 Type: Use case number: number: Description: The integrity and reputation of the stock exchange can be in no way degraded Rationale: Political and economical decisions of countries, companies and individuals are based partly on the performance of the stock market. The stock exchange is central to this and its integrity must not be jeopardized. Source: Fit criterion: Segmentation of the agent traders from the core of the exchange. Agent traders must trade through the same channels as the human traders to ensure fairness. A.11.3 Privacy requirements Requirement 69 Type: Use case number: number: Description: Confidentiality. No information can be made available to others showing the financial status of any client. Rationale: Simply the right to confidentiality and ensuring trust between the client and the system. Source: Brainstorming session Fit criterion: Security infrastructure ensuring that a client’s financial records and account information remain private. Page XLIII
  • 112. Requirement 70 Type: Use case number: number: Description: Confidentiality. No information can be made available to others showing the holdings of any client. Rationale: Ensuring trust between the client and the system and avoiding snooping on sensitive data by other clients or bodies. Source: Brainstorming session Fit criterion: Security infrastructure ensuring that a client’s account information remains private. Requirement 71 Type: Use case number: number: Description: Privately held strategies can not be analyzed or discovered through mal-use of the system. Rationale: A great deal of time and effort can be used to create a strategy that gives a client an edge on the financial market. The client must be sure that he can trust the system to execute his strategies without the fear of others being able to copy or steal his strategy. Source: Brainstorming session Fit criterion: Security infrastructure ensuring that a client’s strategies remain private. A.11.4 Audit requirements Requirement 72 Type: Use case number: number: Description: Changes to agents or strategies must be logged. Rationale: The system must be protected from possible legal action from a disgruntled client by ensuring that all changes to agents or strategies etc. are logged and authenticated. Source: Brainstorming session Fit criterion: Affective logging to allow an audit of what has happened and who carried out the tasks. Page XLIV
  • 113. Requirement 73 Type: Use case number: number: Description: Every system decision must be logged to provide accountability when a decision is queried by a client. Rationale: Any system which passes responsibility of decision making over to a computer must allow for queries on why these decisions were made. By logging the actions of the systems and the data they were based on, it becomes possible to back-track and explain why decisions were made. Source: Brainstorming session Fit criterion: Affective logging capabilities. A.11.5 Immunity requirements Requirement 74 Type: Use case number: number: Description: System must have security features which stop hackers and other mal-intentioned users from breaking into the system. Rationale: Much like banks and other financial software, the effect of a hacker breaking into the system and deleting portfolios, moving money around etc is a major risk factor. Any software must have adequate protection to try and stop this. Source: Brainstorming session Fit criterion: A.12 Cultural and Political Requirements A.12.1 Cultural requirements Requirement 75 Type: Use case number: number: Description: The systems on the market cannot degrade the credibility of the institutions involved. Rationale: For an institution running a marketplace high credibility of the marketplace is of utmost importance Source: WahSui: improved pricing Fit criterion: Trusted system architecture that cannot influence the exchange due to technical or mis-use issues. A.12.2 Political requirements Page XLV
  • 114. Requirement 76 Type: Use case number: number: Description: The functionality of the electronic exchange must be/continue to be deterministic. Rationale: The electronic exchange is a high-confidence complex system that has to behave in a very well understood and predictable fashion. If the functionality of the electronic exchange can not be verified the integrity of the exchange is compromised. Source: Lybäck and Boman: Agent trade servers in Financial exchange systems Fit criterion: All actions of the exchange are deterministic and can be foreseen. A.13 Legal Requirements A.13.1 Compliance requirements Requirement 77 Type: Use case number: number: Description: The system must comply with all regulations from the Financial Services Authorities within the countries in which it operates. Rationale: There are various safeguards in place to protect users of financial services. To be a legal service we have to understand and comply with these regulations Source: Fit criterion: Comply with existing regulations Requirement 78 Type: Use case number: number: Description: The system must comply with the rule of fair dissemination of information. Rationale: It is a legal requirement in some countries that important information and data is released to everyone at the same time and as such various lags have been built into the exchange system to ensure this. A system running parallel to the stock-exchange can not circumvent these. Source: Fit criterion: Comply with existing regulations Requirement 79 Type: Use case Page XLVI
  • 115. number: number: Description: Personal information regarding clients must be held under the terms of the privacy of information act for the countries in which we operate. Rationale: There are various safeguards in place to protect users from the information held about them on computer systems. We must meet these regulations. Source: Fit criterion: Comply with existing regulations A.14 New Problems A.14.1 What problems could the new product cause in the current environment? Content It is not clear at this stage the format the new system shall take, but if it were to be implemented it would involve the nature of trading moving towards a mixture of computer science and economics. We envisage that future human traders using this system would act as managers for a number of computer agents. It is not envisaged that the system would replace the current methods of trading, but offer an additional channel to access the stock market. The system can in no way be allowed to harm the reputation or efficacy of the existing stock exchange. Page XLVII