PDG Borrero Tobar 4.3.0

A SELF-ADAPTIVE CONTROLLER PROTOYPE
FOR AUTOMATED TRADING SYSTEMS
AUTHORS
Andrés F. Borrero Cruz
Juan C. Tobar Núñez
Tutors
Norha M. Villegas Machado, PhD.
Gabriel Tamura Morimitsu, PhD.
UNIVERSIDAD ICESI
SCHOOL OF ENGINEERING
SOFTWARE SYSTEMS ENGINEERING PROGRAM
CALI, COLOMBIA
MAY 2019
i
Table of contents
Figures index .............................................................................................................. iv
Tables index ................................................................................................................ iv
System Logs index ........................................................................................................ v
Acronyms and abbreviations list ................................................................................. vi
Terms glossary ........................................................................................................... vii
1. SUMMARY .............................................................................................................1
2. ABSTRACT ..............................................................................................................1
3. KEYWORDS ............................................................................................................1
4. INTRODUCTION......................................................................................................2
5. MOTIVATION AND CONTEXT ..................................................................................2
5.1. Context ...........................................................................................................2
5.2. Background of the Problem ............................................................................3
5.3. Justification.....................................................................................................4
6. PROBLEM STATEMENT ...........................................................................................5
7. PROJECT OBJECTIVES .............................................................................................5
7.1. General Objective ...........................................................................................5
7.2. Specific Objectives ..........................................................................................6
7.2.1. Objective 1 ..................................................................................................6
7.2.2. Objective 2 ..................................................................................................6
7.2.3. Objective 3 ..................................................................................................6
8. THEORETICAL BACKGROUND .................................................................................6
i
8.1. Financial Markets ............................................................................................6
8.1.1. Forex Trading...............................................................................................6
8.1.2. Algorithmic Trading .....................................................................................8
8.1.3. Portfolio Management ................................................................................8
8.2. Self-Adaptivity ................................................................................................9
8.2.1. Self-adaptive System ...................................................................................9
8.2.2. Feedback Loops .........................................................................................10
9. STATE OF THE ART ...............................................................................................11
9.1. Comparison Criteria ......................................................................................12
9.2. Market Alternatives ......................................................................................13
9.3. Alternatives Evaluation .................................................................................15
10. METHODOLOGY ...................................................................................................16
10.1. Working Scheme ...........................................................................................16
10.2. Project Phases ..............................................................................................17
10.2.1. Development of the SAS model and several concrete SASs ......................17
10.2.2. Development of the self-adaptive controller prototype ...........................17
10.2.3. Performance review ................................................................................18
11. SOLUTION DESIGN AND IMPLEMENTATION .........................................................19
11.1. System’s Architecture ...................................................................................19
11.2. SAS Model ....................................................................................................22
11.3. Controller Prototype .....................................................................................24
11.3.1. Monitor ...................................................................................................24
11.3.2. Analyser...................................................................................................26
ii
11.3.3. Planner ....................................................................................................26
11.3.4. Executor ..................................................................................................27
11.4. Self-Adaptive Strategies (SAS) .......................................................................27
11.4.1. Dragonfly Doji ..........................................................................................28
12. RESULTS ...............................................................................................................29
12.1. Macroeconomic News ..................................................................................30
12.1.1. Consumer Price Index of Great Britain .....................................................30
12.1.2. Tokyo CPI ex Fresh Food ..........................................................................32
12.2. Periodic Portfolio Re-parametrization ...........................................................34
12.2.2. 1st Day Scenario ......................................................................................35
12.2.3. 2nd Day Scenario .....................................................................................37
12.2.4. 3rd Day Scenario ......................................................................................40
13. CONCLUSIONS......................................................................................................43
14. FUTURE WORK .....................................................................................................44
14.1. Future work ..................................................................................................44
14.2. Future Work on Artificial Intelligence ............................................................45
14.3. Reconfiguration with Genetic Algorithms ......................................................45
14.4. Execution of Strategies on Both Demo and Live Funds ..................................46
15. References ...........................................................................................................47
iii
Figures index
Figure 1: A graphical representation of the two types of candlesticks (Bullish and Bearish)
and their components. ................................................................................................................7
Figure 2: Classical block diagram of a feedback control system (Villegas, Tamura, Müller,
Duchien, & Casallas, 2013). ......................................................................................................11
Figure 3: Deployment diagram of the project ................................................................21
Figure 4: Example of a Dragonfly Doji ............................................................................28
Figure 5: Consumer Price Index GBP-related news. Source: Myfxbook Economic Calendar
.................................................................................................................................................31
Figure 6: GBPUSD price chart. Source: TradingView. ......................................................32
Figure 7: Consumer Price Index JPY-related news. Source: Myfxbook Economic Calendar.
.................................................................................................................................................33
Figure 8: USDJPY price chart. Source: TradingView. .......................................................33
Tables index
Table 1: Alternatives comparison. _________________________________________ 15
Table 2: Adaptation scenarios part 1 _______________________________________ 19
Table 3: Adaptation scenarios part 2 _______________________________________ 19
Table 4: List of attributes of the SAS model __________________________________ 23
Table 5: List of parameters of the SAS model _________________________________ 23
iv
System Logs index
System Log 1: Logs of PortfolioController. Source: Grade Project repository .................32
System Log 2: Logs of ThreeWhiteSoldiers Strategy Data (GBPUSD). Source: Grade Project
repository. ................................................................................................................................32
System Log 3: Logs of PortfolioController (From 28-05). Source: Grade Project repository.
.................................................................................................................................................34
System Log 4: Logs of PatternBStrategy (USDJPY from 29-05). Source: Grade Project
repository. ................................................................................................................................34
.................................................................................................................................................36
System Log 6: Logs of BearishDojiStrategy (EURUSD from 28-05). Source: Grade Project
repository. ................................................................................................................................37
.................................................................................................................................................38
repository. ................................................................................................................................39
System Log 9: Logs of PatternAStrategy (EURUSD from 29-05). Source: Grade Project
repository. ................................................................................................................................39
System Log 10: Logs of PatternBStrategy (EURUSD from 29-05). Source: Grade Project
repository. ................................................................................................................................40
.................................................................................................................................................41
repository. ................................................................................................................................42
v
System Log 13: Logs of PatternAStrategy (EURUSD from 29-05). Source: Grade Project
repository .................................................................................................................................42
System Log 14: Logs of PatternBStrategy (EURUSD from 29-05). Source: Grade Project
repository. ................................................................................................................................43
Acronyms and abbreviations list
Algo Short for Algorithmic
API Application Programming Interface
ATR Average True Range
BDD Balance Drawdown
CFD Contract For Difference
CME Current Minimum Equity
DD Drawdown
DU Drawup
EA Expert Advisor
EDD Equity Drawdown
FIX Financial Information Exchange Protocol
FX Foreign Exchange
HFT High Frequency Trading
IDE Integrated Development Environment
KPI Key Performance Indicator
MT4 Metatrader 4
MT5 Metatrader 5
MVP Minimum Viable Product
vi
NYSE New York Stock Exchange
OTC Over The Counter
PF Profit Factor
PMT Portfolio Management Theory
ROI Return Of Investment
SAS Self-Adaptive Strategy
SL Stop Loss
SSV Swiset Side Volatility
TFF Tauro Fitness Function
TP Take Profit
.CSV Comma Separated Value file
Terms glossary
Account Balance
Referred to as just Balance, it represents the total amount of funds an account has.
Account Equity
Referred to as just Equity, it represents the net value of a trader's account. The Equity is
calculated by subtracting the liabilities from the account’s balance, these liabilities may refer to
open market positions that have gained or lost value -a gain of value in a market’s position would
give an equity higher that the balance-. For traders, the equity also equals to the account’s
balance given that all open positions are immediately closed (Investopedia, 1999).
Ask and Bid

They refer to the current Buy and Sell prices of a Security. The Ask equals the lowest price
a Seller is willing to receive in exchange for the security. On the other hand, the Bid equals the
highest price a Buyer is willing to agree on. A trade transaction is made when both Seller and
Buyer agree on a price (Investopedia, 1999).
vii
Asset (Financial Markets)
A financial asset is a liquid asset that gets its value from a contractual right or ownership
claim. Cash, stocks, bonds, mutual funds, and bank deposits are all are examples of financial
assets. Unlike land, property, commodities, or other tangible physical assets, financial assets do
not necessarily have inherent physical worth or even a physical form (Chen, Financial Asset,
2019).
ATR
Average True Range – Technical indicator used for identifying changes in the volatility of
a specific asset and timeframe.
Broker
Private institution that connects natural investors with liquidity providers, allowing
investors to buy and sell financial markets instruments.
CFD
A contract for Difference (CFD) is a financial derivative, more precisely a financial
instrument in which the parties make an agreement for two prices, the entry price and the exit
price.
CME
The current minimum equity measures the theoretical lowest volume a strategy could
present, given that all the market positions are closed in the SL value. This does not consider
positions closing after the SL due to market gaps.
Daily DD
The daily drawdown measures the percentual drop -or loss- a timeseries presents in a
day. It is the DD of the day.
Democratization (Fintech)
Process of make fintech solutions more reachable and available for the B2C segment.
viii
Derivative (Financial)
An underlying asset or financial instrument, in which the agreement between the parties
does not affect the asset price or volume.
Drawdown
A performance indicator used for number series such as prices and accounts balance. It
calculates the difference between the highest historic value of the series and the current value.
Fundamental analysis
It consists in analyzing the market and making predictions based on macroeconomic
indicators, news and economic theories.
Forex
Foreign Exchange (FX or Forex) - A market type, compose by the paper currencies. It is the
world’s most liquidity market.
High-Frequency Trading
An automated trading style featured by exchanging assets on extremely high speeds.
Liquidity Provider
An institution that acts as the buyer and seller of assets, known as the market maker.
Market Gap
Price area where the negotiation between buyers and sellers was not continuous but had
a jump, due to a strong movement in the asset valuation.
Maximum Drawdown
The largest historic Drawdown presented in a number series. It is often used for knowing
the worst scenario of an investment when looking it´s past behavior.
Maximum Daily DD
The maximum daily drawdown is the daily drawdown limit imposed to a strategy to
prevent very large loses in a single day. This validation considers both the current DDD as well as
the theorical value it could reach if all open positions reach SL value.
ix
.NET Core
Computer software framework developed by Microsoft for build and run Web and
Console Apps. A cross-platform version of .NET that supports Windows, Linux and MacOS.
Over the counter

A category of financial scenario, in which the negotiations between the parties are outside
the organized markets.
PMT
A series of theories that establish rules and guides to manage portfolios.
Quant trader
Short for Quantitative trader, it consists in a trader that creates the trading strategies
based on quantitative analysis. In other words, the market analysis is made using mathematical,
logical and probabilistic approaches.
ROI
The return of investment is the percentual change an investment has made due to its
gains or losses.
SAS
A self-adaptive strategy consists in an automated trading strategy capable of re
parametrizing itself in lieu of achieving optimum performance.
Spread
The price difference of a market found between the Ask and the Bid
SSV
A volatility indicator developed by Swiset. It says if the market is on a bullish trend – values
higher than 1 – or in a bearish trend – values lower than -1 –.
Stop Loss
A numerical tag that can be added to a market order to specify the price at which an open
position must close to prevent further losses. It allows better fund management as the position
will automatically close once the Stop Loss price is reached.
x
Take Profit
A numerical tag that can be added to a market order to specify the price at which an open
position must close for a profit. It works as a tool for managing a position’s close value without
having to actively close it.
TFF
An algorithmic function that gives a quantitative value for measuring the performance of
a strategy in a given time period. It is not static, the function receives both the historical data of
the strategy, and a series of parameters that bias the score – e.g. bias towards more stability,
ROI, DD, and so forth –.
Technical analysis
Also known as Quantitative Analysis, it consists in analyzing the market and making
predictions based on mathematical, logical and probabilistic theories.
Trade Side
Side by which an investor can make a trade, in this case Buy or Sell.
Trading
The process of exchanging both goods and services between many stakeholders, usually
with the intent of achieving a profit. According to Swiset, the trading phases are Chart Analysis,
Find Entry Points, Trade, Manage operations and Close operations (Swiset, 2018), all these must
be done by any complete trading strategy.
Trading Bot
Or simply bot, is a software system that collects data from financial providers to operate
editing, closing or opening trading positions according to some financial logic. It can also be
referred to as trading strategy, strategy, robot, or algo trading. For the rest of the document, the
term strategy will be used instead.
xi
1. SUMMARY
La complejidad de los mercados ha sido siempre un tema de gran debate. No solamente
por los prestigiosos logros que un académico puede alcanzar cuando explica un fenómeno de
forma exitosa, sino también por el potencial económico que suelen tener estos hallazgos. Como
resultado de esto, encontramos la inspiración para conectar teorías de portafolio con los sistemas
auto-adaptativos, desarrollando un prototipo de un controlador para un sistema compuesto por
estrategias de negociación algorítmica. El prototipo aplica y sigue técnicas tanto de
autoadaptación como de autoconfiguración, permitiendo interacciones de tipo preventivas y
reactivas con las estrategias de negociación. El sistema fue probado con sus diversos escenarios
de adaptación, proporcionando una serie de resultados que logran demostrar el potencial de la
autoadaptación y la automatización en los Mercados de Capitales.
2. ABSTRACT
Market complexity has always been a topic of great debate. Not only because of the
prestigious achievements an academic can accomplish when it successfully explains a
phenomenon, but also because of the potential economic reward these findings often have. As
a result of these, we found the inspiration to bind Portfolio Management theories with Self-
Adaptive Software, developing a Controller prototype for a system composed of algorithmic
trading strategies. The prototype applies and follows both self-adaptive and self-configuring
techniques, allowing it to make both preemptive and reactive interactions with the trading
strategies. The system was then tested in its different adaptation scenarios, providing a series of
results that further demonstrate the potential of self-adaptivity and automation software in the
Capital Markets.
3. KEYWORDS
Trading, Self-Adaptive System, Portfolio Management, Capital Markets.
1
4. INTRODUCTION
Market complexity has always been a topic of great debate. Not only because of the
prestigious achievements an accomplish can achieve when it successfully explains a
phenomenon, but also because of the potential economic reward these findings often have. As
a result of these complexities, the development of technologies dedicated to the automation of
trading has been on a rising trend, as observed by the European Central Bank (2019). The
development of automated trading strategies -also known as Trading Bots, or simply, Bots- is
stronger now than ever (European Central Bank, 2019). Still, some companies are reluctant to
adopt automated strategies influenced by a combination of complexity, risk of failure, and
obsolete ideologies.
The realization of an automated strategy is as important as it is complex. It requires

constant update of its behavior, by changing the strategy’s parameters, to keep it from becoming
obsolete and unsafe. Supporting numerous strategies increases complexity exponentially, given
the increasing number of tasks needed when adding new strategies. The maintenance of each
strategy needs to consider all the other strategies for achieving portfolio’s goals. In other words,
the holistic result of all the strategies must be defined by the portfolio’s configuration, even
though some might present a completely different behavior. This hinders the scalability that
trading systems require.
This graduation project focuses on the development of a prototype trading system

composed of trading strategies and a central controller. Said system is designed to be self-
adaptive, having both proactive and reactive actions that allow efficient management of the
portfolio’s funds. Also, a series of scenarios are described and tested to prove the effectiveness
of the system.
5. MOTIVATION AND CONTEXT

5.1. Context
Throughout history, especially in the last two centuries, technology has played a high
impact role in most sectors of society. The financial sector is no exception, how banking, fintech
2
solutions, and investments, have mutated and democratized thanks to technology. This allows
smaller entrepreneurships to continue being competitive despite their lack of resources. Tauro
Systems is an example, a startup in fintech that develops automated tools for the trading process
would have little to no chances of success twenty years ago, when corporate businesses had no
interest in implementing automated strategies, and assets lacked the democratization the have
nowadays. The developments and discoveries achieved in this project make part of Tauro
Systems efforts in achieving smarter and easier to implement trading systems. The developments
and discoveries achieved in this project make part of Tauro Systems’ efforts in achieving smarter
and easier to implement trading systems.
The investment field makes use of the vast computational power available and the
maturity of engineering. These allow large liquidity providers, such as J.P. Morgan Chase or
Goldman Sachs (EURO MONEY, 2018), to develop alternative infrastructures to manual trading.
As a result, hedge funds and natural investors are encouraged to design, create, and deploy
automated strategies that manage several phases of the trading process. Moreover, like other
technology areas in their early stages, a wide variety of platforms and technologies are
developed. Major firms are each creating their technologies, exploring new models, and
discovering innovative ways of participating in the markets. The entry barriers for participating
in this new massive market are few, allowing for new players to enter.
The democratization of assets opened the opportunity for any firm large enough to create
their own framework for developing automated strategies and technologies. Each one competes
for having the best connection, service and community while smaller agents - firms / individuals
that participate in markets – and users suffer the lack of a standard that allows for fully
developing algorithmic tools and systems.
5.2. Background of the Problem
Since October 2008, when the NYSE (New York Stock Exchange) created a new successful
market model to compete with other electronic trading platforms (Markham, 2015), the
algorithmic trading has been widely accepted as a viable investment on most liquidity markets
by financial institutions, investing many resources and efforts on research for this field. It paved
3
the way for the algorithmic trading solutions proliferation. When bearing in mind how the market
volume controlled by automated trading systems passed from being 15% to 85% in under 10
years (Glantz & Kissell, 2013) (Markham, 2015), the high impact of better algorithmic solutions
in markets becomes explicit.
It is critical and complex to formulate a well thought trading strategy, to design the logical
model behind it, to develop the strategy, and finally, to deploy said strategy into the investor’s
portfolio correctly. These are both critical and complex processes every successful quant trader
needs to consider. Besides, with little to no standardization, traders are left with pre-built
solutions that serve well the average enthusiast but end up short for more serious applications.
This lack of standardization raised concerns on 2010, when high frequency algorithmic
strategies allegedly magnified a small market decline resulting in the infamous Flash Crash
(Menkveld & Yueshen, 2017). This event created a bad reputation for both high frequency
trading, and automated strategies, and it took years for the general public to trust again these
technologies.
5.3. Justification
Tauro Systems shares the vision of automating multiple trading tasks and processes to
minimize development and operational costs, and to the amount of work needed to start trading.
It is common for traders to focus on a few trading strategies, big corporations usually create
portfolios where funds are distributed among traders depending on their performance. All the
activities needed to make the initial costs for opening a new portfolio high enough to prevent
smaller firms from creating one. These costs also increment the funds required for opening a new
portfolio as larger funds represent larger income for the company that owns the portfolio.
Therefore, portfolios from smaller companies rarely outperform larger ones, they have similar
operational costs, but the larger fund has better margins for innovating and improving their
investments. A consequence is that some firms can sustain collective investments, and clients
are required to accept the firm’s configuration for a portfolio, even if the client is not comfortable
with the way investments are made.
4
With lower operational costs, the entry barrier for creating new portfolios is lowered,
companies could open more portfolios in addition to those already in place. For a smaller firm
like Tauro Systems, the implementation of automated systems would unlock the possibility of
creating portfolios with lower costs and similar performance to larger companies. The expected
result of more automated and efficient ways for managing trading portfolios is an increment in
the amount of companies offering investment opportunities, as well as a larger amount of
investing products from larger companies. From a client’s point of view, this is an improvement
since he can access with fewer funds a portfolio that is better adjusted to his preferences.
6. PROBLEM STATEMENT
Several issues can be addressed when looking at the identified problems. The inefficiency
of manually operating a portfolio, the costs of a portfolio manager, the time needed for deciding
based on an event, and the poor scalability when adding more strategies, to name a few. For this
project, the inefficiency and lack of scalability when configuring and managing a portfolio of
automated trading systems are addressed. This inefficiency includes:
1. The inaccuracy of an individual to manage the strategy variables or behaviors according
to the market conditions and,
2. In software systems, the lack of a framework for trading systems integration altogether.
This can also be appreciated and better understood in the Problem Tree, that can be seen
in the Project Repository:
https://github.com/camilotobar/grade-project/blob/master/Problem%20Tree.png
7. PROJECT OBJECTIVES
7.1. General Objective
Developing a prototype controller of a trading system that applies self-configuration and

auto-adaptive system strategies, maximizes profitability, and aids the deployment of new trading
subsystems.
5
7.2. Specific Objectives
7.2.1. Objective 1
Determine the most relevant risk and profitability parameters of any trading systems,
based on the market conditions and on-time performance, to have a better understanding and
make them self-configurable.
7.2.2. Objective 2
Design and develop a SAS model that allows better integration of future trading strategies
into the system, these strategies must be manageable by the system controller.
7.2.3. Objective 3
Develop the controller prototype, with basic self-adaptive techniques, that will be able to
support the deployment of trading strategies, reconfigure them, and reallocate their funds. All
these at runtime.
8. THEORETICAL BACKGROUND
8.1. Financial Markets
8.1.1. Forex Trading
Trading consists of the process of exchanging goods and services between stakeholders.
In the forex market, only currencies (paper currencies) are assets are exchanged between the
parts, and all transactions are speculative looking to generate positive returns in a defined period.
Japanese Candlesticks
Although ancient, this technique for viewing price changes throughout time remains the
norm for showing price charts for stocks, forex, commodities, and other markets. These were
invented in the 18th century for visually representing price movements in rice in Japan (Levisohn,
2008). Japanese candlesticks, or simply candlesticks, are a simple way or representing a series of
values, prices in this case, during a time-boxed period.
6
Each candle consists of three different parts for four values. The values are open, close,
high and low. They represent the price of the asset for the moment the period started (open),
the moment the period ended (close), the highest value during that period (high), and the lowest
value (low) during the period. There is also the upper shadow, which is represented by a line that
starts at the same value of the high and ends in the largest between the open and close. The
body represents the net price movement during the time period, it is a rectangle that starts in
the open price and ends at the close price. Opposite to the upper shadow, the lower shadow
starts in the lowest value between the open and close (the lower part of the body) and ends in
the low price point. The candlestick and its parts can be observed in Figure 1.
Figure 1: A graphical representation of the two types of candlesticks (Bullish and Bearish) and their
components.
Candlestick patterns are useful for visualizing trading data, they summarize information
and present it in a readable format. A series of technical analysis strategies have resulted from
years of experienced traders looking for patterns. These patterns are completely technical, and
lack fundamental analysis, but this doesn’t mean they cannot be profitable. Candlestick patterns
are a good match for validating the system’s ability to self-adapt since they require less
information to be communicated and the development is less complex than more developed
strategies.
7
8.1.2. Algorithmic Trading
Algorithmic trading plays a fundamental role throughout the entire project since the main
goal is to improve the efficiency in the deployment and management of algorithmic trading
systems. Algorithmic trading is defined as follows:
“…the process of using computers programed to follow a defined set of instructions (an
algorithm) for placing a trade in order to generate profits at a speed and frequency that is
impossible for a human trader. The defined sets of rules are based on timing, price, quantity or
any mathematical model. Apart from profit opportunities for the trader, algo-trading makes
markets more liquid and makes trading more systematic by ruling out the impact of human
emotions on trading activities” (Investopedia, 1999).
8.1.3. Portfolio Management
Portfolio management is one of the most important activities in the trading process.
According to Investopedia, portfolio management can be understood as “the art and science of
making decisions about investment mix and policy, matching investments to objectives, asset
allocation for individuals and institutions, and balancing risk against performance”. Indeed, there
are three key elements on which any portfolio management plan should be considered
(Investopedia, 1999):
Asset Allocation: Asset allocation is based on the understanding that different types of
assets do not move in concert, and some are more volatile than others. Asset allocation seeks to
optimize the risk/return profile of an investor by investing in a mix of assets that have low
correlation to each other (Investopedia, 1999).
Diversification: Diversification is the spreading of risk and reward within an asset class.
Because it is difficult to know which subset of an asset class or sector is likely to outperform
another, diversification seeks to capture the returns of all of the sectors over time but with less
volatility at any one time (Segal, 2019).
Rebalancing: is a method used to return a portfolio to its original target allocation at

annual intervals. It is important for retaining the asset mix that best reflects an investor’s
8
risk/return profile. Otherwise, the movements of the markets could expose the portfolio to
greater risk or reduced return opportunities (Chen, Asset Allocation, 2019).
When the term active portfolio management is used instead of just portfolio
management, it is meant to emphasize that the activity acts upon investments at runtime. For
this project, there is a bigger concern for active portfolio management since the role of a self-
adaptive controller assimilates more this behavior rather than just a passive or static portfolio
management. The goal of active portfolio management is to outperform a portfolio that only has
a broad diversification (Fabozzi, Martellini, & Priaulet, 2006).
For an investor or financial institution who develops or uses automated trading systems,
it is necessary to have a fourth additional key element on portfolio management, the strategy's
allocation -or trading systems allocation-. This can impact the performance of a portfolio, and the
faster strategies can be allocated and executed, the better. Hence, the relevance of applying self-
adaptive models and software engineering theories at runtime arises. These models seek to
improve efficiency of defining new parameters in algorithmic trading systems. They are also
tasked to automatically respect a portfolio-s risk profile and strive for a better profitability.
8.2. Self-Adaptivity
8.2.1. Self-adaptive System
The purpose of this graduation project is to apply techniques that can automatically
evaluate and mutate at runtime, all in accordance to specific moments where the market trend
changes. These techniques are to be complemented with the current technologies on which the
strategies are implemented.
Self-adaptive systems are the focal point for the project’s problem solution. Self-adaptive
software are systems “able to modify their behavior and/or structure in response to their
perception of the environment and the system itself, and their goals” (Giese, et al., 2013). Hence,
for this graduation project, each trading strategy is part of a monitored system. Said monitoring
is made according to financial technical analysis specifications. By implementing a self-adaptive
software, the system can adjust its own behavior, e.g., by changing parameters, or intervening in
9
running strategies. The software is instructed to respect the risk profiles of each portfolio and
prioritize the strategies that are specific to each market moment. As a result, the management
several trading strategies becomes more efficient and economic.
8.2.2. Feedback Loops
Feedback loops “provides the basis for automation in many fields of engineering and for
self-adaptation in computing and software engineering. (...) the feedback loop or also closed
loop, is the model used to automate the control of dynamic systems.” (Villegas, Tamura, Müller,
Duchien, & Casallas, 2013).
The main elements of a feedback control system are diagrammed in the Figure 2 (Villegas,
Tamura, Müller, Duchien, & Casallas, 2013)
1. Controller: Defines the mechanisms to manage the target system, according to rules that
seek to obtain measured outputs according to references inputs.
2. Target System: Defines the core business system that will be adapted. In this project the
target systems are represented by the strategies.
3. Measured Outputs (A): Lists the output obtained from the target system’s behavior. For
the current project, they are the runtime performance of each trading strategy in terms
of risk and profitability.
4. References Inputs (B): Used as benchmarks for the Measured Outputs. In this project, they
are the multiple risk/trend relations of the market.
5. Control Error (C): The difference between the measure output and the reference input.
This value is used by the controller to adjust the system being adapted.
6. Controlling Inputs (D): The signals or mechanisms used to adapt the target system. In this
project, they are the parameters that can be modified by the controller.
7. Disturbances (E): Any context variable that may affect the behavior of the target system.
For this project’s context, disturbances can be caused by sporadic market events, false
signals, system or strategy malfunction, among others.
10
8. Noise (F): Affects the measured outputs but is caused by the system adaptation itself. For
example, if a strategy is adapted in the wrong way, the measured output would indicate
the need for further intervention affecting it even more.
9. Transducers (G): Translates the data and signals coming from sensors, when applicable.
For this project, a transducer is implemented in the function that calculates the fitness
level, how well it performed, of a strategy.
Figure 2: Classical block diagram of a feedback control system (Villegas, Tamura, Müller, Duchien, &
Casallas, 2013).
9. STATE OF THE ART

As it has been thoroughly mentioned, portfolio management is not an easy task.
Companies spend many resources in having their investments well managed; this includes hiring
portfolio managers and trading analysts. According to a study made by Emolument on 3,531
trader salaries, the average trader analyst earned in 2018 $USD 67,000 year (Emolument, 2018).
Trading companies are seeking to invest thousands of dollars in the development of automated
strategies to reduce costs of traders and increase profits.
Human traders more expensive to operate, but also lack several of the qualities
automated strategies present. While a person might be limited by its biological abilities, software
can easily calculate, operate, and analyze thousands of assets at the same time. Moreover, the
moment a person is being pushed to its limits, a new trader is needed, an automated strategy
would only require to be deployed in multiple instances for achieving better performance.
11
Humans also require rest, vacations, and get sick. On the other hand, a computer can function
24/7 or according to the strategy specification. Even on weekends, when the market is closed,
these automated strategies can still work performing big data analysis, intensive optimizations,
and many more operational tasks.
Limitations make it impossible for a person to monitor and detect changes on all the
relevant variables at runtime and without aid, a task that can be achieved by a computer. Not
being able to keep track and on time monitor of these relevant variables affects the context
management capacity of a person. For systems that are context-based such as a trading portfolio
that relies heavily on available data and indicators, decisions are provided by a context manager
based on past, current, and foreseeable future states of context (Villegas, Tamura, Müller,
Duchien, & Casallas, 2013).
An investment portfolio is a collection of all the current investments. When investing,

diversification is critical, while it often reduces the profits a firm might make if it trusted all the
funds to the best strategy, diversifying reduces risks and stabilizes the profits. In the world of
finance, a stable investment with consistent low profits is more valuable than a high-risk high-
return investment. Being a key role in a firm, a portfolio manager has an average base pay of
$USD 132,591 each year (Glassdoor, 2018). Good management is the last line of defense a
portfolio has against market drawdowns and economic shifts, it can represent the difference
between a profitable year for the company or one with losses. Like the human trader, a portfolio
manager is limited, and the more diversified the investments are, the harder it becomes to keep
up for the manager.
9.1. Comparison Criteria
Just like technology aids the application of trading strategies, several tools have been
developed to help a portfolio manager keep track of the investments. During the research of this
project, it was not possible to find a solution that autonomously manages a trading portfolio.
Most software solutions just present a toolset for making a follow up on the investments,
providing data analytics and periodical reports. Only a few alternatives offer the ability to
12
automatically do tasks such as fund redistribution based on performance, stop loss and take
profits overrides, or alert interventions when high impact news are revealed.
A pre-established criterion is used for comparing the different alternatives. Each solution
is evaluated according to their Scalability, Reliability, Complexity, and Percentage of the problem
is solved with it. The latter describes, out of a hundred, how much is the project’s problem solved
or how much can it be solved, with the alternative.
9.2. Market Alternatives
StockMarketEye
This software allows a high detailed monitoring for different securities. Provides data
from news sources, reports tracking, price alerts, and performance reporting. It lacks any
automated controlling functionality, it is intended to be used as a tool for aiding the analysis of a
portfolio (Stock Market Eye, n.d.). It also lacks the integration with trading strategies in real time,
requiring the data to be imported through a .csv for making the analysis.
Auto Trade Driver

This alternative provided by Auto FX Pro allows the management of risks and the control
of orders. The biggest advantage of this software is the ability to protect investments with some
degree of personalization. By allowing the trader to choose his exit strategy and conditions, it
facilitates trading since the analyst has to worry about trading his strategy without the need for
reviewing open operations (Stock Market Eye, n.d.). It lacks the ability to control any of the
strategy’s behavior, and it only allows connection through a Metatrader’s platform.
Metatrader 4 & 5
The Metatrader platforms, MT4 and MT5, are the most used platforms for trading thanks
to their long-time participation in the markets (United States Patent No. 0292786 A1, 2016), the
MT4 platform became available in 2005 when Metaquotes released it (Metaquotes, 2005). The
Metatrader platform provides a built in IDE (Integrated Development Environment) for
developing automated strategies (EAs). There is also no simple way to control the strategies of a
similar system automatically.
13
CTrader / CAlgo
Second only to the Metatrader platform, the CTrader is one of the most popular platforms
for trading different assets. While many traders use CTrader for doing manual trades or for
connecting it to another account through third party software, the CTrader Spotware API
(Application Programming Interface) provides an IDE within the platform that allows the
development, backtesting, optimization, and execution of strategies. Developers can work with
C# as the default coding language supporting the installation of .NET libraries to expand the
capabilities of existing automated strategies.
The only supported environment for developers is Windows, and it lacks the ability to
automatically control strategies. While a communication could be established between
strategies and a controller, the platform is not designed to allow any parameter changes at
runtime. Automated backetestings, optimizations, or the execution of new instances through
code is not supported. Also, Tauro Systems empirically found that having several strategies
running concurrently, deeply compromises the stability of the platform, crashing the entire
operating system in the worst scenarios.
Spotware Connect API

The Spotware Connect consists in an open API that allows developers to use the CTrader
functionalities from their own developing platforms. As stated by the Spotware’s documentation
(n.d.) The API is divided into two main parts, the Accounts API and the Trading API. To access to
the trader’s balance, trade history, credentials, available symbols, and other services, the
Account API is used. Connection is made via HTTP request/response, and the authentication is
made with a token. These connections are limited by the terms and agreements that Spotware
defines, and if they consider it necessary, the connection could be destroyed abruptly. This is a
concern for systems that need a reliable connection. To obtain information on the market or
execute trading operations, the Trading API is used. This API establishes a full duplex connection
channels over TCP and WebSocket connections (Spotware, n.d.).
14
9.3. Alternatives Evaluation
The technologies and platforms described provide different services and each one of
them partially addresses the project’s problem. The first evaluation that can be made from all
the alternatives is that none of them provides a solution, at least not on their own or without
further development. This makes the project’s evaluation more challenging since there is no
technological baseline to compare with.
Stock Auto Trade Metatrader Bots CTrader/CAlgo Bots Spotware Connect API
MarketEye Driver
Scalability Very poor. Poor. Medium, Medium, depends on Depends on system’s design
depends on strategy’s and service connection
strategy’s configuration and policy.
configuration. scope of solution.
Reliability Relies on Relies on human Depends on bots Can be reliable under Best if well implemented.
human intervention and and load. small loads. (Multiple
intervention. pre- Communication instances work
configuration. between better)
components is
unreliable.
Complexity Easy to Easy to Hard to Average difficulty to Very hard to implement.

implement. implement. implement. implement.
Degree of It only solves Solves most of Requires Requires Requires development to

the the the control development to development to solve the problem. It could
problem monitoring aspects. But solve the solve the problem. It provide a complete solution
solved aspect lacks ability to problem. Could can successfully with high dependence on the
self-adapt and be a working provide part of the service quality.
change its solution with bad solution, but not all
behavior. scalability. of it.
Table 1: Alternatives comparison.
Based on the analysis made and the comparison provided in Table 1, the CTrader platform
has been chosen for developing a connection provider. This CTrader component will establish a
connection to the markets and the traders account, as well as exposing our own API that can be
consumed by the system’s self-adaptive controller and strategies. The endpoints for this API can
be created using CTrader’s built-in IDE. This approach allows for a black-box implementation for
connecting and authenticating to the Broker. The CTrader platform can also have multiple
15
instances running concurrently with the same credentials. In addition, the API exposed is meant
to be stateless, the scalability and reliability of the system can be improved by having multiple
Connection Providers.
The other components of the system can be developed using other technologies without
having the limitations of the CTrader platform. All the automated strategies, as well as the self-
adaptive controller will be implemented on separate projects using the .NET Core. Having the
projects running independently allows for a distributed solution for a more scalable and capable
system.
One main disadvantage of this approach is that the solution has a dependency on CTrader.
This dependency means that if the platform changes or stops its services, the project’s system
could stop functioning as it was intended to. It is also true that the system relies strongly on
having an available Connection Provider, an element prone to failure. None the less, with the
services being stateless, a load balancer could distribute the requests within several Connection
Providers, this way, if one fails, it can be automatically redeployed without an impact in the
system’s performance.
Even if the CTrader platform becomes unavailable, or the system needs to migrate to a
market that does not accept CTrader credentials, the effect is minimized since the only
component affected would be the Connection Provider. Solving this issue would require repairing
or developing one component instead of the entire system.
10. METHODOLOGY
10.1. Working Scheme
Since the agreement on the project topic in mid July 2018, a series of meetings were
arranged with the advisors. These meetings had the purpose of establishing a common
knowledge base among both authors and tutors.
The development of the self-adaptive trading system proposed in this thesis was realized
through three phases that are described as follows:
16
1. Development of the self-adaptive controller prototype
2. Development of the SAS model and several concrete SASs
3. Performance review
Each phase was developed by applying an incremental life cycle. This model was chosen
with the goal of producing a minimum viable product (MVP) since the early stages of the project,
and then upgrading their capacity and functionalities without compromising the system’s
integrity and completion.
After each of the development phases provides a finished product, a final testing phase
is executed in order to obtain and compare the results of the self-adapting system with the
manual approach.
10.2. Project Phases
10.2.1. Development of the SAS model and several concrete SASs
One of the main requirements for this project is the possibility to facilitate further
development and integration of strategies to the system. Therefore, a whole development phase
was dedicated for creating a Self-Adaptive Strategy (SAS) model. The specific objective achieved
in this phase is the second objective of the project:
Objective 2: Design and develop a SAS model that allows better integration of future
trading strategies into the system, these strategies must be manageable by the system controller.
The SAS model must include the needed interfaces to communicate with the controller
as well as the implementation of the distributed controller’s functions. These interfaces include
both providing the required information as well as allowing for a parametrization of the strategy.
10.2.2. Development of the self-adaptive controller prototype
The self-adaptive controller prototype is what provides the most value to this project and
field of study. The holistic result of the combination of the different project components with a
self-adaptive controller provides a new value not addressed in other investigations and projects.
During this phase, objectives one and three were achieved:
17
Objective 1: Determine the most relevant risk and profitability parameters of any trading
systems, based on the market conditions and on-time performance, to have a better
understanding and make them self-configurable.
Objective 3: Develop the controller prototype, with basic self-adaptive techniques, that
will be able to support the deployment of trading strategies, reconfigure them, and reallocate
their funds. All these at runtime.
Considering the self-adaptive theories, the controller prototype includes the four core
components of a self-adaptive system; a monitor, an analyser, a controller, and an executor. And
while all four stages are present in the system’s controller, an approach to distribute the
controller within the system’s nodes is implemented. This distribution achieves a reduced
workload in the controller making each node of the system (the automated strategies)
responsible for self-evaluating and computing some processes of the controller.
10.2.3. Performance review
The moment the system is ready for execution, a testing phase is implemented. The main
purpose of this phase is to review the effectiveness of the new controller for managing the
system.
This phase provides an insight into the capabilities of the controller and allows for a more
educated speculation on how this prototype can be further developed, and how it can be
valuable for the industry. Different scenarios are defined for evaluating and reviewing the
system’s effectiveness, these are detailed in Table 2 and Table 3.
Scenarios Period Source Source Input Format

Type
Macroeconomic D1 FX economic calendar External Natural language
news
Portfolio re- D1 Performance data for each Internal Strategy Performance

param deployed strategy (Object from Tauro Utilities)
SSV H1 Broker ECN network External Number (double)
18
Bot MDDD Order Bot's strategy Internal Boolean
reached request
Table 2: Adaptation scenarios part 1
Scenarios Analysis Process Intervention Values Expected Behavior

Macroeconomic news Economic calendar High impact news in less Pause opening orders
for the day is than an hour for strategies
requested. News depending on
are categorized per affected asset
importance and
affected assets.
Portfolio re-param Once the period Bots balance and
has ended, the MDDD are re
Controller's parametrized based
Analyser proceeds on TFF
to apply the TFF
according to PMTs
SSV For each hour, the Above 1(Bullish Side) Pause opening orders
SSV value is and below -1 (Bearish on a specific trend for
requested for the Side) strategies depending
active assets within of affected asset
the portfolio
Bot MDDD reached True if a bot is True The request is denied
requesting a within the Strategy
position that would
change the CME to
a point that
exceeds the MDDD
Table 3: Adaptation scenarios part 2
11. SOLUTION DESIGN AND IMPLEMENTATION

11.1. System’s Architecture
Before implementing any component of the system, an exercise on developing the

architecture was made. This included several validations the Software Architect from the Icesi
University, Gabriel Tamura PhD, for ensuring that the design was able to meet the requirements
of the project, as well as to address the following quality attributes that were identified as most
architecturally significant.
19
1. Configurability – Since the prototype is a self-adaptive software, it must be able to allow
for different configurations.
2. Scalability – Since the motivation for making this project was the development of a system
that allows the management of multiple trading strategies, the solution requires to scale
for supporting an increasing number of strategies.
3. Portability – For using the solution in different industries, the software needs to be able
to work under different environments, hence it must be portable.
The architecture diagram is made as a Deployment Diagram following the UML standard.
As seen in Figure 3 or in the Project repository:
https://github.com/camilotobar/grade-project/blob/master/Deployment%202.3.1.jpg.
The Deployment Diagram has three types of nodes, these represent the Connection
Provider, System’s Controller, and Self Adaptive Strategy (specified twice for indicating multiple
instances).
20
Figure 3: Deployment diagram of the project
21
11.2. SAS Model
For designing the SAS model, it was first necessary to clarify the role it was to have in the
system. For a system to be coordinated by the controller, each component needs to be compliant
with the interfaces provided by the controller both for providing required information, as well as
receiving instructions from the controller.
Also, the model must consider allowing the strategy to obtain the required market and
account information as if it was working with direct communication with the broker. This
communication is made possible by establishing a connection with the API provided by the
Connection Provider.
The design of the SAS model specifies what this component needs. Since it must not be
possible for the developers of the concrete strategy to adjust the way it communicates with the
other components, or to provide false data regarding performance, these functionalities are
included in the SAS model and it is not an option to modify them from a developers perspective.
First, a series of attributes are listed. These define the information and state of a strategy
and are essential for the system controller to know how a strategy is performing. The selected
attributes that each strategy must include are presented in Table 4.
Attribute Description Value
Name The name of the strategy running, it must be unique A string sequence
among the strategies deployed in the system.
Balance The net balance provides the funds a strategy has before A numeric value of double precision
the execution of the current open orders. equal or greater than zero.
Equity The equity of the strategy describes the current balance A numeric value of double precision
considering open positions and their results. equal or greater than zero.
Margin The margin represents the funds that are currently A numeric value of double precision
compromised for maintaining the orders opened. equal or greater than zero. It is always
equal or lesser than the balance.
Free Margin The free margin represents the available funds for A numeric value of double precision
executing new market operations. equal or greater than zero. It is always
equal or lesser than the equity.
22
Current The current minimum equity is the balance that would A numeric value of double precision. It
Minimum be left if all the opened positions close in their set Stop can be lower than zero, but it should
Equity Loss. never reach that range of values.
Active The active positions are currently open positions in the A list of objects of type Position.
Positions strategy. Not the active positions in the system.
Historic The historic positions are all the positions that have A list of objects of type Position that
Positions been opened and closed by the strategy. were previously in the Active Positions
list.
Strategy The asset analyzed by the strategy for operating. An object of type Asset that contains
Asset the information regarding the market
the strategy acts on.
Strategy The time frame used for analyzing the asset. An object of type TimeFrame that
Time Frame specifies the length of the time period
the strategy acts on.
Is Selling True if the strategy can perform operations on the Sell A Boolean value.
Active side. False if it is not allowed.
Is Buying True if the strategy can perform operations on the Buy A Boolean value.
Active side. False if it is not allowed.
Table 4: List of attributes of the SAS model
After defining the attributes, the definition of the parameters that needed to be defined
by the controller is made. The parameters are the values meant to change the SAS’s behavior to
achieve the portfolio’s goals. The chosen parameters for this model are in Table 5.
Parameters Description Value
Initial Balance The initial balance defines the funds trusted to a A numeric value of double precision
strategy by the controller. above zero.
Max Daily Drawdown The maximum daily drawdown establishes the A numeric value of double precision
maximum accepted drawdown a strategy can equal or greater than zero.
tolerate.
Table 5: List of parameters of the SAS model
The set of interfaces and functionalities of the model are defined. These include the
functionalities for providing information and allowing for re-parametrization. Some of the
functionalities are extended from the controller and distributed among the SASs. The reason
23
behind distributing a component meant for being centralized -the system’s controller-, is that
several protection mechanisms and levels of data analysis don’t require a holistic view of the
system and are compute-intensive. So, to achieve better performance and safety, the controller
within the SAS model examines all market orders, authorizes their execution and provides data
reports on the SAS’s performance.
As it was mentioned before, the SAS model allows itself to be re-parametrized by the
system’s controller. This re-parametrization is made possible by providing the controller’s monitor
with the performance reports for the present period (historic positions, balance, equity, among
others) it requires. The controller’s planner considers all the information provided by the SASs in
the portfolio, as well as the information from the knowledge base, then it proceeds to compute
the values for the parameters of each strategy. These plans are then given to the executor so that
it can communicate to each SAS their new parameters. It is, therefore, necessary that the SAS
model allows for the high-level parameters to be defined by the controller for changing its
behavior accordingly. Under the scope of this project, the selected high-level parameters for a SAS
are the balance (allocated funds the strategy is responsible for), and the Max Daily DD (maximum
loss a strategy can afford in a single day).
11.3. Controller Prototype
Since several of the actions made by the controller can be made without the global context
of the system, distribution of some controller tasks is made throughout the Strategies. These
actions include, but are not limited to, obtaining and preparing the metrics and performance of a
strategy, evaluating that the strategy is within its acceptable values, and limiting the execution of
market orders in compliance with the limitations imposed by the controller.
11.3.1. Monitor
The controller’s monitor is responsible for maintaining a constant connection with each of
the system’s nodes. These nodes can be either SASs or Connection Providers. While the monitor
makes no processing of the data it collects, it is designed to fetch only the required information
to reduce both the load on the computing node and the network. The monitor is also responsible
24
for knowing the analyser’s location since all the information it collects need to be forwarded to
the analyser unchanged.
In addition to the services the monitor consumes from other components, it has different
interfaces exposed for allowing the SASs in the system to communicate. In other words, interfaces
for being notified of events, critical behaviors in a SAS, and more, are implemented in the monitor.
These interfaces are known by other components to allow a better monitoring of the context and
current strategies.
When a new strategy is deployed, it is the strategy's responsibility to notify the monitor of
its existence. The SAS does this by calling an exposed interface of the monitor specifically meant
for registering new strategies to be monitored. When this interface is called, the monitor proceeds
to register the SAS’s location (route and port) and it then communicates the new connection to
the analyser for it to keep in mind the existence of this strategy. This is the only functionality of
the monitor where the component has some degree of interaction with the information it
receives, for all the other functionalities, when the monitor receives or fetches information, it is
responsible for forwarding it without interacting with the data.
For each SAS in the system, the monitor keeps a record of their route and port to
periodically fetch the information it requires from them. This information is forwarded without
modification to the Analyser every time a re-parametrization is scheduled. Since these
connections are a responsibility assigned to the monitor, this component is the only one
responsible for calling the information from other bots and starting the parametrization of
strategies.
Some monitor’s functionalities are distributed among the SASs in the SAS model. This
foreign -distributed- part of the monitor observes any operation made within a strategy and
reports it accordingly. It allows for other functionalities from the controller to take place within
the SAS, such as detecting critical behaviors and prohibiting the execution of market orders that
would risk the system, among others.
25
Although some functionalities that correspond to the monitor are distributed, a dedicated
component for the distributed monitor is not developed due to the lesser complexity it presents.
Instead, the behavior and functionalities are ensured within the SAS model’s code. A similar
pattern is observed with the other distributed components of the system’s controller.
11.3.2. Analyser
The analyser component, as mentioned earlier, processes the raw data obtained from the
monitor. It is meant to filter information and create useful data that can be interpreted and
treated as an input for the planner. The analyser processes a strategy’s performance for a given
period and provides useful information such as the fitness score a strategy is rewarded for the last
period.
After processing the information, the analyser oversees that the planner gets all the
information it needs for working correctly. Like the monitor, some functionalities of the analyser
are distributed among the SASs. These distributed parts of the controller create different degrees
of data processing to reduce the load made in the centralized controller.
11.3.3. Planner
After the information has been analyzed and processed, the planner takes it as an input to
make the decisions regarding fund allocation and reparameterization of the Max Daily Drawdown
of each bot. The planner has the responsibility of deciding when a strategy must be intervened,
which assets are limited and on which side, and how the funds should be distributed on the
portfolio.
For making these decisions, the planner uses a pre-set knowledge base as well as the
different inputs originally taken by the monitor and passed to the analyser. These inputs include,
but are not limited to, each of the strategy’s fitness, economic calendar events, and Swiset’s side
volatility.
As a result, the planner can consider 3 different scenarios that require some degree of
intervention. The first scenario is the periodic re-parametrization the system performs to maintain
the funds distributed according to the performance of each SAS. The second scenario is the
26
reception of high impact economic events, where the strategies that work on assets likely to be
affected are set to a pause from all trading. And the third scenario, like the economic events, is
when the Swiset’s side volatility indicates a strong trend in a specific direction for an asset, this
results in preventing any SAS to open a position that goes against the detected trend.
As the system is developed further, more complex scenarios will be included. This will both
provide more interfaces for new types of decisions to be executed, as well as requiring more
information and analysis from the system. It could also mean a higher level of customization of
the whole portfolio as well as more accurate self-adaptations.
11.3.4. Executor
After all the decisions by the planner have been made, the executor receives them and
bears the responsibility of taking the planner’s command to the rest of the system. For achieving
this, the component interacts with the interfaces exposed by the SASs that are meant to receive
this input for achieving the new set of instructions.
While new instructions replace the current ones, the Strategy’s behavior follows its last
commands, defining its available funds, limiting trade operations for one or both, and preventing
the execution of market orders that would risk surpassing the Max DD set for the strategy.
11.4. Self-Adaptive Strategies (SAS)
For the implementation of the prototype, a series of SASs were developed. The majority
were strategies used in Tauro System’s operations. Since these were not based in the SAS model
and were created for being executed in the CTrader platform, a refactoring was needed for
reflecting the logic in compliance with the model.
The main advantage of having the automatic strategies in their own standalone version,
free of any platform, is how different frameworks or technologies can be applied hassle free. Also,
since the communication of the SAS with the broker is transparent, there is little substantial
difference between connecting the boat directly to the market, or simply connecting it to the SAS
model and allowing the model to handle connections.
27
The trading strategies are based on Japanese candlestick patterns. These strategies
analyze technical indicators looking for patterns and conditions that dictate when to execute
market orders. Under the scope of the project, a total of 8 SASs were developed and deployed.
For better illustration, a more detailed definition of how a strategy works is provided below.
11.4.1. Dragonfly Doji
Description
For identifying the opportunity of trading a Dragonfly Doji, the market must be on a
downtrend. If a candlestick closes with no head or body, and a very long shadow, then the
necessary conditions for making a trade are met. Once the bar closes and it shows that a Dragonfly
Doji occurred while on a downtrend, a Long position is opened. In Figure 4, it is possible to identify
the downtrend preceding the signal (moment the strategy instructs to open a trade), followed by
a Doji, and then a strong rising price trend.
The downtrend is detected using a SMA indicator with parametrizable period length. Also,
the time period for calculating each candlestick can also be set by a given parameter. Additional
validations can be implemented for having a better confirmation of the trade, and different
approaches can be made for setting the SL and TP values.
Figure 4: Example of a Dragonfly Doji
28
Logic behind it
The idea behind this strategy is to detect a point in time when the market trend is reversed,
thus providing a trading opportunity to buy. When the price is falling, it can be understood as if
the bears are stronger and push the price downwards. A Dragonfly Doji indicates that during the
time period, the bears initially pushed the price even lower, but the bulls regained enough
strength to level it back to the opening price. The presence of a bullish trend can be confirmed
more by waiting for the next candle and checking if it continued to have a net price increment.
The opposite strategy of the Dragonfly Doji is called the Gravestone Doji. It works under
the same logic, but everything is the opposite. This means that instead of a downtrend, there must
be an uptrend, and instead of having a long lower shadow, there must be a large upper shadow.
Both strategies were developed and included in the system as SASs.
12. RESULTS
For evaluating the controller prototype, the self-adaptive scenarios were tested using real
time market data and several strategies in execution. Apart from the SSV (Swiset’s Side Volatility)
scenario, all the stated adaptation scenarios were successfully observed. The performance review
consisted in having several automated strategies operating and logging all the interaction
between the strategies and the controller.
Unfortunately, the SSV only triggers with specific market conditions, and while the system
was placed under review for a fortnight, none of the observed markets triggered the event. For
this to happen, either a modification in the SSV needs to be made, or a longer period needs to be
tested. This is inconvenient due to the time limitations faced in the project, yet since it works
similarly to the Economic Calendar scenario, there is a positive feeling that the scenario would
work and can be included in the system.
All raw documents, logs and reports generated by the implemented system and the
financial broker can be viewed and downloaded in the repository of the Final Grade Project:
https://github.com/camilotobar/grade-project.
29
12.1. Macroeconomic News
The first adaptation scenario is based on the macroeconomic news. There are many
financial markets assets that are sensitive to macroeconomic and political news, such as the main
currencies or commodities. These events signal technical strategies (based only on price, volume
or indicators) to stop acting in situations where news volatility can affect the strategy’s
performance.
The control flow of the macroeconomic context begins with the Monitor module. Every
hour the Controller's Monitor downloads the scheduled economic and political news from the
MyfxBook’s Economic Calendar, and the Controller's Analyser filters the high-impact news that
would be announced or triggered in less than one hour. Then, the Controller's Planner finds the
strategies that trade with the affected assets and the Controller's Executor intervenes on those
strategies so that they can't execute buys or sells one hour after the news.
The scenario was validated with the two following economic news:
12.1.1. Consumer Price Index of Great Britain
For example, the 22nd of May was a day with many high volatility news, such as the
Consumer Price Index-CPI of Great Britain (News description in Figure 5). The Consumer Price
Index is the input for the inflation rate, one of the most critical and market-sensitive
macroeconomic indicators.
30
Figure 5: Consumer Price Index GBP-related news. Source: Myfxbook Economic Calendar
In the price chart of GBPUSD (British Pound vs. US Dollar Figure 6), it can be seen the
sideways market resulting from the news, this can have negative effects for any strategy based on
technical analysis due to unexpected changes in the trend.
31
Figure 6: GBPUSD price chart. Source: TradingView.
Therefore, on the system's side, it can be seen in the PortfolioController logs (System Log
1) that some strategies would be stopped 4 minutes before the news was announced, due to
fundamental volatility. In this portfolio configuration, the only strategy stopped was the
ThreeWhiteSoldiers (System Log 2), which analyzed the GBPUSD asset.
System Log 1: Logs of PortfolioController. Source: Grade Project repository
System Log 2: Logs of ThreeWhiteSoldiers Strategy Data (GBPUSD). Source: Grade Project repository.
12.1.2. Tokyo CPI ex Fresh Food
Another relevant adaptation case of the system according to the macroeconomic context
was seen in the Tokyo CPI ex Fresh Food annual report. A high-impact and highly sensitive report
for any asset matched with the Japanese yen or JPY. On May 30, the result of the report was
announced (Figure 7). Just after it happened, a sharp drop in the USDJPY price (Figure 8) could be
observed in less than two hours, a scenario that would have left any technical strategy analyzing
the USDJPY under more uncertainty conditions.
32
Figure 7: Consumer Price Index JPY-related news. Source: Myfxbook Economic Calendar.
Figure 8: USDJPY price chart. Source: TradingView.
In the trading system, it could see how the Controller (System Log 3) monitored the Tokyo
CPI ex Fresh Food news 9 minutes before it was come out, stopping the buying or selling to the
only strategy that analyzed the USDJPY currency (System Log 4).
33
System Log 4: Logs of PatternBStrategy (USDJPY from 29-05). Source: Grade Project repository.
12.2. Periodic Portfolio Re-parametrization
The portfolio periodic re-parameterization allows giving higher relevance to the strategies
that have the best performance of the period, seeking for improving the overall profitability of the
portfolio while decreasing the risk in the diversification process.
For this re-parameterization process,
1. First, the Controller's Monitor asks each of the strategies for the performance of the
period.
2. Then the Controller's Analyser calculates the Fitness value of each strategy based on the
theory of high-frequency trading portfolio (While greater the Fitness value, better), finding
at the end the relevance or weighting of each strategy for the new period (Weight over
the summation of Fitness).
3. Subsequently, the Controller's Planner calculates what would be the New Balance and New
Max Daily Drawdown for each strategy.
4. The process is finished with the Controller's Executor who re-parameterizes each of the
strategies with the values given by the Planner.
Three-day scenarios were performed to validate the coherent re-parameterization by the

controller with the performance data per strategy.
34
12.2.2. 1st Day Scenario
The first testing scenario of the periodic re-parameterization by the Controller took place
from May 28 to May 29, 2019.
Scenario Conditions
The system conditions before starting the reparameterization process for the day of the
scenario were the following:
1. There were 6 automated technical strategies (Only analyze prices or prices-based

indicators) running trading analysis.
A. BearishDoji
B. BullishDoji
C. ThreeWhiteSoldiers
D. ThreeBlackSoldiers
E. MorningStarBullish
F. MorningStarBearish
2. None of the 6 strategies had executed any buy or sell according to their technical entry
conditions, due to being swing trading strategies that are more complex to be triggered
during an average week.
3. An account balance of 10000 USD to date (Trading Account annexed in Repository).
Expected Behavior
The expected behavior in this scenario was that the Controller's Analyser would calculate
the same Fitness value in all the strategies, due to the investment performance of each strategy
brought by the controller's Monitor module.
After calculating an identical Fitness for each strategy, it was expected that the Controller's
Planner will weigh the same balance and max daily drawdown to each strategy for the new period:
• New expected balance (For all strategies) = 10000 USD / 6 strategies ≈ 1666.66666667 USD
/ strategy.
35
• New expected max daily drawdown (For all strategies) = 1666.66666667 USD * 10% ≈
166.66666667 USD.
System’s Response
The result obtained, and registered in the PortfolioController logs (System Log 5), in the
process of periodic re-parameterization by the Controller was as follows:
1. The Controller’s Monitor module asked each of the strategies the trading performance of
the period.
2. Then, the Controller's Analyser module calculated the Fitness of each strategy. The Fitness
value for each one was 0.01, default value if some strategy doesn't close any buys or sells
trade in the period.
3. Finally, the Controller's Executor module reparametrized each of the strategies attached
to the system. Allocating a New Balance of 1666.6666666667 for the period and a New
Max Daily Drawdown of 166.666666667 that is adjusted to 10% of strategy balance. In the
BearishDojiStrategy logs (Chart 10) it is possible to appreciate the request to
AdjustParameters endpoint, request received with the indicated parameters.
36
System Log 6: Logs of BearishDojiStrategy (EURUSD from 28-05). Source: Grade Project repository.
12.2.3. 2nd Day Scenario
The second testing scenario of the periodic re-parameterization by the Controller took
place from May 29 to May 30, 2019.
Scenario Conditions
In order to test the re-parametrization based on each of the strategies’ profitability, the
portfolio configuration was changed. Therefore, the system conditions before starting the re-
parameterization process for the day of the scenario were the following:

A. BearishDoji
B. PatternA
C. PatternB
2. Two (Pattern A and Pattern B) of the 3 technical strategies were executed and closed at
least one buy or sell trade in the period.
3. An account balance of 9992.98 USD to date (Trading Account annexed in Repository).
Expected Behavior
In this scenario, the expected behavior was for the Controller's Analyser to calculate a
different and coherent Fitness for each of the strategies' performances.
37
After calculating the Fitness value for each strategy, it was expected that the Controller's
Planner would weigh a New Balance and Max daily drawdown to each strategy according to the
value of their Fitness.
System’s Response
the period.
2. Then, the Controller's Analyser module calculated the Fitness of each strategy. In this case,
the fitness value was not equal between the three strategies.
Chart 11. Logs of PortfolioController (From 28-05). Source: Grade Project repository.
3. For the BearishDoji strategy (System Log 8), a 0.01 period Fitness was obtained because it
was the only one of the three strategies that didn't execute or close any buy or sell trade.
Fitness value that means a change to the following parameters:
• New balance = 9992.98 USD * Fitness weighting ≈ 5943.68 USD.
• New max daily drawdown = 5943.68 USD * 10% ≈ 594.368 USD.
The request to the endpoint to parameterize the strategy is seen on the logs.
38
4. For the PatternA strategy (System Log 9), an approximately Fitness value of 0.00634 was
obtained due to its performance of the period. Fitness value that means a change to the
following parameters:
System Log 9: Logs of PatternAStrategy (EURUSD from 29-05). Source: Grade Project repository.
5. For the PatternB strategy (System Log 10), an approximately Fitness value of 0.00046 was
39
System Log 10: Logs of PatternBStrategy (EURUSD from 29-05). Source: Grade Project repository.
12.2.4. 3rd Day Scenario
The third testing scenario of the periodic re-parameterization by the Controller took place
from May 30 to May 31, 2019.
Scenario Conditions
For purposes of expecting constant buys or sells on the portfolio strategies, the same
portfolio configuration was retained. The system conditions for re-parametrization of the day of
the scenario were the following:

A. BearishDoji
B. PatternA
C. PatternB
2. All the technical strategies had executed and closed at least one buy or sell trade in the
period.
3. An account balance of 9994.39 USD to date (Trading Account annexed in Repository).
40
Expected Behavior
In this scenario, the expected behavior was for the Controller's Analyser to calculate a
different and coherent Fitness for each of the strategies' performances.
After calculating a Fitness value for each strategy, it was expected that the Controller's
Planner would weigh a New Balance and Max Daily Drawdown to each strategy according to the
value of their Fitness. In addition, a Fitness value different than 0.01 was expected due to all the
strategies closed at least one trade.
System’s Response
the period.
2. Then, the Controller's Analyser module calculated the Fitness value of each strategy. In
this case, the Fitness was not equal between the three strategies and was different from
0.01 (default value).
3. For the BearishDoji strategy (System Log 12), an approximately Fitness value of 0.00633
was obtained due to its performance of the period. Fitness value that means a change to
the following parameters:
• New max daily drawdown = 1979.24 * 10% ≈ 197.924 USD.
41
4. For the PatternA strategy (System Log 13), an approximately Fitness value of 0.00179 was
System Log 13: Logs of PatternAStrategy (EURUSD from 29-05). Source: Grade Project repository
5. For the PatternB strategy (System Log 14), an approximately Fitness value of 0.02384 was
42
System Log 14: Logs of PatternBStrategy (EURUSD from 29-05). Source: Grade Project repository.
13. CONCLUSIONS
The development of this graduation project leaves us with many questions, some answers,
and software we have a high interest in further developing. It comes to no doubt that, resembling
other trading technologies, the complexity of financial markets is one of the most important
challenges in this system. This project leaves us with a humble sense of better understanding and
domain over these markets.
First and foremost, this project provides a path to follow. We are left with a roadmap that
still needs much work to be done. The project’s achieved scope still falls short due to all the
different technologies and developments that can be included. None-the-less, we see this as a
huge success, the project taught a lot to those involved. Also, it reinforced the belief that self-
adaptivity and related theories can be useful for complex and uncertain contexts such as financial
markets.
The developed system, being a prototype, lacks the features and maturity required for
being deployed to a production environment. We are in a context where the control of uncertainty
must be paramount to satisfy a sensible and objective management of investment portfolios. This
necessity for uncertainty control, along with the timely feedback from our tutors, made us realize
that it is necessary to include at least one more level of control that allows the current controller
prototype to adapt according to other kind of business and investment objectives. As for the
43
market’s uncertainty, while solving it and making it predictable is out the question, certain control
and adaptive measures need to be included in the system to provide better risk avoidance and
safety during operation.
For improving the previously mentioned uncertainty control, two important factors need
to be addressed. First, a broader set of preemptive adaptation scenarios must be included,
allowing intervention of the strategies according to market analysis. An example of this is the
scenario we, unfortunately, were not able to validate, the SSV (Swiset’s Side Volatility). Second,
the inclusion of better fundamental analysis tools for the controller can provide a better grasp
over market events that are both risky and difficult to foresee with technical analysis.
Another conclusion is that, with the current system, a degree of value is provided to the
industry. This happens because, not only tasks such as portfolio re-balancing are made
automatically, the adaptation of the system for making strategies follow an investor’s profile is a
feat very useful for both traders and clients. The self-adaptive scenarios that were implemented,
can be a baseline for future automatization developments at Tauro Systems. And as it was
previously mentioned, it starts the path for more capable and robust trading self-adaptive
systems.
Finally, we can proudly say that this project has risen interest from the private sector, with
corporate firms pushing forward for its completion. This happens due to the degree on how the
problem of managing a portfolio is shared among the different actors of the industry. With the
future work stated below, we hope that this software and its future versions take industry to new
standards and gives self-adaptivity the recognition it deserves.
14. FUTURE WORK

14.1. Future work
There are several things that were left for future development according to the scope
selected for the project. For instance, different components can be improved, added, or modified
to the prototype. Some of these additions can bring new functionalities, improve existing ones,
or, if the client requires it, make a trade off by sacrificing some functionalities to achieve others.
44
Future work includes to enable the self-adaptive controller with artificial intelligence mechanisms
and make the portfolio a self-adaptable entity in lieu of escalating the solution to a system with
dynamic portfolios instead of only strategies.
14.2. Future Work on Artificial Intelligence
A big concern in these systems is the uncertainty of markets. Even though markets appear
to be a randomized change of prices, both fundamental and technical traders believe that markets
present a rhythm (Kosakowski, 2018). Still, the complexity and shifting rhythm of the markets
make them near impossible to predict, especially with a static set of rules that do not consider
how markets’ behavior change constantly. In other words, the patterns that guide the shifts in
market states are of such complexity that it would be nearly impossible for a human to analyze
them, detect them, and put them on practice on time. Therefore, different data analytics
approaches could be applied to anticipate and manage these market shifts.
For the self-adaptive controller, these predictions could distribute funds and take
preemptive measures for the most possible scenarios. These models would be part of the analyser
component, and their results would be an input for the planner. Different approaches and models
can be developed and tested for selecting those with the best results, and just as the SSV (Swiset’s
Side Volatility) attempts to predict a trend for prohibiting the strategies to go against the trend,
these models could be inputs for controlling the strategies behavior or interceding if necessary.
14.3. Reconfiguration with Genetic Algorithms
Genetic algorithms tackle problems that other optimization solutions can’t solve. Their
ability to optimize complex systems has already proven to be very useful in the automated trading
industry. Every major trading platform that allows the development of automated strategies
includes an optimization function that uses genetic algorithms. And considering that automated
trading strategies often have a long list of parametrizable values, optimizing for the best historic
outcome is a logical step to make in further developments.
These techniques are not perfect, and they do not come in cheap. It is very common for
developers to over-train their systems on historic data. This creates a strategy so perfect for the
45
past, that can be considered useless for the future, in the data science field of study, this is called
overfitting. Still, there are several techniques already developed to prevent overfitting the
solution.
Another consideration when implementing genetic algorithms is the computational cost

bared by the system. Making a backtest is no trivial task, it takes time to run all the strategy’s logic
through the historic data. And, having to make a backtest for every different configuration,
generation after generation, takes hours, if not days, on a fast computing processor. This
computational cost needs to be carefully considered, since it could present a negative impact on
the system’s scalability. Each strategy could be responsible for running these algorithms to reduce
the workload on centralized computers.
14.4. Execution of Strategies on Both Demo and Live Funds
When trading strategies are executed, they can run in two different modes, demo and live.
The only difference between these two is whether the market operations are made with fake or
real funds. In other words, the automated strategy thinks it is trading with real funds and behaves
accordingly, but, the market orders and their results are simulated with real market data.
Since there is no significative difference between the results obtained by a strategy

running in demo mode, to one running live, the controller can assess the performance reports of
strategies running on demo the same way it treats those running with real live funds. This provides
more data for the planner, giving it a better insight for distributing funds and weighting more the
best performing strategies.
Also, if a strategy is obtaining undesired results, it can be executed in demo mode allowing
it to continue providing a measured output so that if it becomes an effective strategy once again,
the controller can distribute live funds once again.
46
15. REFERENCES
AutoFXPro. (n.d.). Auto Trade Driver. Retrieved from Auto FX Pro:
https://www.autofxpro.com/auto-trade-driver/
Chen, J. (2019, May 5). Asset Allocation. Retrieved from Investopedia:

https://www.investopedia.com/terms/a/assetallocation.asp
Chen, J. (2019, May 9). Financial Asset. Retrieved from Investopedia:

https://www.investopedia.com/terms/f/financialasset.asp
Emolument. (2018). Average salary for Traders. Retrieved from

https://www.emolument.com/salary-reports/jobs/trading/38489
EURO MONEY. (2018, May 30). Euromoney FX Survey 2018 -Press Release. Retrieved from
EUROMONEY: https://www.euromoney.com/article/b18f5s6kqtcr6m/euromoney-fx-
survey-2018-press-release
European Central Bank. (2019, 02 13). Algorithmic trading: trends and existing regulation.
Retrieved from BANKING SUPERVISION:
https://www.bankingsupervision.europa.eu/press/publications/newsletter/2019/html/ss
m.nl190213_5.en.html
Fabozzi, F. J., Martellini, L., & Priaulet, P. (2006). Advanced Bond Portfolio Management: Best
Practices in Modeling and Strategies. London: John Wiley & Sons.
Giese, H., Müller, H. A., Shaw, M., Andersson, J., Litoiu, M., Schmerl, B., . . . Villegas, N. M. (2013).
Software Engineering for Self-Adaptive Systems: A Second Research Roadmap. Berlin,
Germany: Springer Berlin Heidelberg. Retrieved from
https://link.springer.com/chapter/10.1007/978-3-642-35813-5_1
Glantz, M., & Kissell, R. (2013). Multi-Asset Risk Modeling: Techniques for a Global Economy in an
Electronic and Algorithmic Trading Era. Academic Press.
Glassdoor. (2018). Portfolio manager salary. Retrieved from Glassdoor:

https://www.glassdoor.com/Salaries/portfolio-manager-salary-SRCH_KO0,17.htm
47
Investopedia. (1999). Basics of algorithmic trading: Concepts and examples. Retrieved from
Investopedia: https://www.investopedia.com/articles/active-trading/101014/basics-
algorithmic-trading-concepts-and-examples.asp
Investopedia. (1999). Bid and Ask. Retrieved from Investopedia:

https://www.investopedia.com/terms/b/bid-and-ask.asp
Investopedia. (1999). Equity. Retrieved from Investopedia:

https://www.investopedia.com/terms/e/equity.asp
Investopedia. (1999). Portfolio Management. Retrieved from Investopedia:

https://www.investopedia.com/terms/p/portfoliomanagement.asp
Khizhnyak. (2016). United States Patent No. 0292786 A1. Retrieved from
https://patentimages.storage.googleapis.com/07/a3/8e/28ef9094d63c5f/US2016029278
6A1.pdf
Kosakowski, P. (2018, January 16). Financial Markets: Random, Cyclical or Both? Retrieved from
Investopedia: https://www.investopedia.com/articles/financial-theory/09/markets-
cyclical-vs-random.asp
Levisohn, B. (2008, November 26). Making and Understanding Candlestick Charts. Retrieved from
Bloomberg: https://www.bloomberg.com/news/articles/2008-11-25/making-and-
understanding-candlestick-charts
Markham, J. W. (2015). A Financial History of the United States: From Enron-Era Scandals to the
Subprime Crisis (2004-2006); From the Subprime Crisis to the Great Recession (2006-2009).
Chapel Hill, North Carolina, United States of America: Routledge.
Menkveld, A. J., & Yueshen, B. Z. (2017, November 15). The Flash Crash: A Cautionary Tale About
Highly Fragmented Markets. Management Science. United States: Institute for Operations
Research and the Management Sciences.
Metaquotes. (2005). Company. Retrieved from Metaquotes:

https://www.metaquotes.net/en/company
48
Segal, T. (2019, April 5). Diversification. Retrieved from Investopedia:
https://www.investopedia.com/terms/d/diversification.asp
Spotware. (n.d.). API-reference. Retrieved from Spotware:

https://connect.spotware.com/docs/api-reference
Spotware connect. (n.d.). Accounts API. Retrieved from Spotware: https://

https://connect.spotware.com/docs/api-reference/accounts-api
Spotware. (n.d.). Trading API. Retrieved from Trading: https://

https://connect.spotware.com/docs/api-reference/accounts-api
Stock Market Eye. (n.d.). Stockmarketeye, Home. Retrieved from StockMarketEye:

www.stockmarketeye.com/
Swiset. (2018, July 05). Swiset home page. Retrieved from Swiset: https://swiset.com/
Villegas, N. M., Tamura, G., Müller, H. A., Duchien, L., & Casallas, R. (2013). DYNAMICO: A
Reference Model for Governing Control Objectives and Context Relevance in Self-Adaptive
Software Systems. Software Engineering for Self-Adaptive Systems II. Heidelberg, Berlin:
Springer.
49

PDG Borrero Tobar 4.3.0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PDG Borrero Tobar 4.3.0

Uploaded by

Copyright:

Available Formats

A SELF-ADAPTIVE CONTROLLER PROTOYPE

FOR AUTOMATED TRADING SYSTEMS

Tables index ................................................................................................................ iv

System Logs index ........................................................................................................ v

Acronyms and abbreviations list ................................................................................. vi

Terms glossary ........................................................................................................... vii

5. MOTIVATION AND CONTEXT ..................................................................................2

5.1. Context ...........................................................................................................2

5.2. Background of the Problem ............................................................................3

6. PROBLEM STATEMENT ...........................................................................................5

7. PROJECT OBJECTIVES .............................................................................................5

7.1. General Objective ...........................................................................................5

7.2. Specific Objectives ..........................................................................................6

7.2.1. Objective 1 ..................................................................................................6

7.2.2. Objective 2 ..................................................................................................6

7.2.3. Objective 3 ..................................................................................................6

8. THEORETICAL BACKGROUND .................................................................................6

8.1.1. Forex Trading...............................................................................................6

8.1.2. Algorithmic Trading .....................................................................................8

8.1.3. Portfolio Management ................................................................................8

8.2. Self-Adaptivity ................................................................................................9

8.2.1. Self-adaptive System ...................................................................................9

8.2.2. Feedback Loops .........................................................................................10

9. STATE OF THE ART ...............................................................................................11

9.1. Comparison Criteria ......................................................................................12

9.2. Market Alternatives ......................................................................................13

9.3. Alternatives Evaluation .................................................................................15

10. METHODOLOGY ...................................................................................................16

10.1. Working Scheme ...........................................................................................16

10.2. Project Phases ..............................................................................................17

10.2.2. Development of the self-adaptive controller prototype ...........................17

10.2.3. Performance review ................................................................................18

11. SOLUTION DESIGN AND IMPLEMENTATION .........................................................19

11.1. System’s Architecture ...................................................................................19

11.2. SAS Model ....................................................................................................22

11.3. Controller Prototype .....................................................................................24

11.3.1. Monitor ...................................................................................................24

11.3.4. Executor ..................................................................................................27

11.4. Self-Adaptive Strategies (SAS) .......................................................................27

11.4.1. Dragonfly Doji ..........................................................................................28

12. RESULTS ...............................................................................................................29

12.1. Macroeconomic News ..................................................................................30

12.1.1. Consumer Price Index of Great Britain .....................................................30

12.1.2. Tokyo CPI ex Fresh Food ..........................................................................32

12.2. Periodic Portfolio Re-parametrization ...........................................................34

12.2.2. 1st Day Scenario ......................................................................................35

12.2.3. 2nd Day Scenario .....................................................................................37

12.2.4. 3rd Day Scenario ......................................................................................40

14. FUTURE WORK .....................................................................................................44

14.1. Future work ..................................................................................................44

14.2. Future Work on Artificial Intelligence ............................................................45

14.3. Reconfiguration with Genetic Algorithms ......................................................45

14.4. Execution of Strategies on Both Demo and Live Funds ..................................46

15. References ...........................................................................................................47

Figure 3: Deployment diagram of the project ................................................................21

Figure 4: Example of a Dragonfly Doji ............................................................................28

Figure 6: GBPUSD price chart. Source: TradingView. ......................................................32

Figure 8: USDJPY price chart. Source: TradingView. .......................................................33

Table 1: Alternatives comparison. _________________________________________ 15

Table 2: Adaptation scenarios part 1 _______________________________________ 19

Table 3: Adaptation scenarios part 2 _______________________________________ 19

Table 4: List of attributes of the SAS model __________________________________ 23

Table 5: List of parameters of the SAS model _________________________________ 23