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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
• 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
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
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
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
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
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
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
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
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
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
• 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
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
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
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
Page 54
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
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
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
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
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
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
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
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
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/[email protected].
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
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
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
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
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
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
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
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
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
• 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
High speed LAN
LAN
ATSStock exchange
Solution
Roluter
Firewall
Terminal
Client firewallInternet
Status monitor
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
• 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
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
• 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
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
StockTradingContext
Information provider
Trader
Analyst
Broker
Manager
Client
Stock exchange
Financial services
authoritiesProvide regulations
Financial reports
Analysis information
Trading information
News
Broker instructions
Stock recomendations
Stock prices
Price information
Analysis from information providers
Recomendations for traders
Evaluation of trader performance
Trader performance
Invest
Returns
Puts presure on trader
Stock data
Stock buy/sell orders
Trading instructions
Recomendations for traders
Buy/Sell orders
Figure 2: The arrows show data coming in and being
given out by each player in the current stock exchange
Page XIV
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 trader based on information analysis
Stock recommendation (out)Stock prices (in) News (in)
2. Trader instructs broker on what stock to buy
Recommendation (out) Analysis (in) Stock prices (in)
3. Broker places orders for buying stock
Recommendations from trader (in) Stock prices (in) Buy order (out)
4. Broker places order for selling stock
Recommendations from trader (in) Stock prices (in) Sell order (out)
5. Manager evaluates trader performance
Portfolio development (in)
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 analysis
Stock prices (in) News (in) Trading information (in) Analysis (out)
9. Regulation by financial services authority
Market conduct (in) Regulation (out)
Page XV
A.7 Functional and Data Requirements
A.7.1 Functional Requirements General system requirements Requirement number:
1 Type: Functional Use case 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 number:
2 Type: Functional Use case 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 number:
3 Type: Functional Use case 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
Requirement number:
4 Type: Functional Use case 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 number:
5 Type: Functional Use case 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
Requirement number:
6 Type: Functional Use case 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 number:
7 Type: Functional Use case 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 number:
8 Type: Functional Use case 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
Requirement number:
9 Type: Functional Use case 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 number:
10 Type: Functional Use case 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
Requirement number:
11 Type: Functional Use case 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 number:
12 Type: Functional Use case 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
Requirement number:
13 Type: Functional Use case 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 number:
14 Type: Functional Use case 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
Requirement number:
15 Type: Functional Use case 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 number:
16 Type: Functional Use case 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 number:
17 Type: Functional Use case 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
Requirement number:
18 Type: Functional Use case 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 number:
19 Type: Functional Use case 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 number:
20 Type: Functional Use case 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
Requirement number:
21 Type: Functional Use case 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 number:
22 Type: Functional Use case 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 number:
23 Type: Functional Use case 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
Requirement number:
24 Type: Functional Use case 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 number:
25 Type: Functional Use case 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
Requirement number:
26 Type: Functional Use case 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 number:
27 Type: Functional Use case 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
Sell Stock
Requirement number:
28 Type: Functional Use case 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 number:
29 Type: Functional Use case 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 number:
30 Type: Functional Use case 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
Requirement number:
31 Type: Functional Use case 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 number:
32 Type: Functional Use case 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
Buy Stock
Requirement number:
33 Type: Functional Use case 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 number:
34 Type: Functional Use case 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 number:
35 Type: Functional Use case 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
Requirement number:
36 Type: Functional Use case 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 number:
37 Type: Functional Use case 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 number:
38 Type: Functional Use case 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
Security
Requirement number:
39 Type: Functional Use case 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 number:
40 Type: Functional Use case 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 number:
41 Type: Functional Use case 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
A.7.2 Data requirements
Requirement number:
42 Type: Data requirement
Use case 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 number:
43 Type: Data requirement
Use case 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
Requirement number:
44 Type: Data requirement
Use case 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 number:
45 Type: Data requirement
Use case 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 number:
46 Type: Data requirement
Use case 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
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 number:
47 Type: Use case 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 number:
48 Type: Use case 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
Requirement number:
49 Type: Functional Use case 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 number:
50 Type: Functional Use case 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 number:
51 Type: Use case 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
A.8.2 Ease of learning. Requirement number:
52 Type: Use case 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 number:
53 Type: Use case 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
Requirement number:
54 Type: Use case 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 number:
55 Type: Use case 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 number:
56 Type: Use case 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
Requirement number:
57 Type: Use case 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 number:
58 Type: Use case 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 number:
59 Type: Use case 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
Requirement number:
60 Type: Use case 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 number:
61 Type: Use case 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 number:
62 Type: Use case 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
Requirement number:
63 Type: Use case 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 number:
64 Type: Use case 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
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
A.11 Security Requirements
A.11.1 Access requirements Requirement number:
65 Type: Use case 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 number:
66 Type: Use case 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
Requirement number:
67 Type: Use case 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 number:
68 Type: Use case 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 number:
69 Type: Use case 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
Requirement number:
70 Type: Use case 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 number:
71 Type: Use case 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 number:
72 Type: Use case 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
Requirement number:
73 Type: Use case 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 number:
74 Type: Use case 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 number:
75 Type: Use case 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
Requirement number:
76 Type: Use case 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 number:
77 Type: Use case 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 number:
78 Type: Use case 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
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
Recommended
