UNIT CODE: ACFIM0015

UNIT NAME: Algorithmic Trading

DEADLINE: Monday 28 April 2025 before 13:00 BST

SUBMIT TO BLACKBOARD UNIT SUBMISSION POINT

Overview

•          Your summative coursework represents 100% of the final mark for the unit.

•          The coursework is in the form of a written report, in the style of an academic research paper.

•          Your report should  describe the design, implementation, and testing/evaluation of an algorithmic trading system. The evaluation will  require you to  run a suitably large  number of computer simulation experiments which are likely to take many hours (or days) of continuous computation: plan your time accordingly and do not leave this assessment to the last minute!

•           Penalties will apply if the coursework is submitted late.

•          Penalties will apply if the coursework is submitted in a format other than the one specified.

•          The coursework is an individual piece of work – you should work on this yourself and not as a group. You will be required to make a plagiarism statement and your submission will be tested for originality.

•          Use of AI text generators such as ChatGPT is prohibited. The text of your report should be written by you, in your own words. If we find that you have used ChatGPT, that will be treated with the same seriousness/severity as if you had been found guilty of plagiarism.

Coursework Requirement

Eight-page research paper on algorithmic trading strategies

The Brief:

For this coursework submission you will be given pre-existing Python code for an algorithmic trading system known as PT2, which operates as an intra-day proprietary trader (often abbreviated to a “prop trader”) of a cryptocurrency, i.e. a trader that starts each day with a sum of money and then buys and sells cryptocoins on a financial exchange, trading for its own profit, rather than on behalf of a third-party client, and at the end of the day liquidates any holdings into cash. Your assignment for this coursework is to modify, and potentially adapt, extend, or replace, the code for PT2 in an attempt at improving its performance relative to another prop trader algorithm known as PT1, which you will also be given the Python code for. You should compare the performance of PT1 and your version of PT2 in a market simulator where the dynamics of the price for the cryptocoin is modelled on time-series data from one or more cryptocurrencies. For this coursework you should use the Bristol Stock Exchange (BSE) market simulator, which is freely available on GitHub.

BSE is a minimal simulation of the core mechanism within most technology-enabled financial markets: the Limit Order Book (LOB) and its associated Matching Engine. BSE is written in Python, and includes code for six different types of algorithmic trading “robots” called Giveaway, ZIC, Shaver, Sniper, ZIP, and PRZI, each of which trades according to some simple algorithm, and several of which were introduced in Lecture 3. ZIC is an implementation of the Zero-Intelligence Constrained strategy introduced by Gode & Sunder (1993); Sniper is inspired by, but not identical to, Kaplan’s Sniper (Rust et al., 1992). Giveaway, Shaver, ZIP, and PRZI are all by Cliff (Cliff, 1997, 2018, 2023). In keeping with the tradition for trading algorithms being referred to  by a short sequence of letters  reminiscent of a stock-market ticker-code, within  BSE the Giveaway algorithm is referred to as GVWY, and the Shaver algorithm is referred to as SHVR.

The source-code for BSE (a single file, BSE.py) is freely available under the MIT Open Source License, and can be downloaded from the GitHub repository: https://github.com/davecliff/BristolStockExchange.

Documentation for BSE is in the repository’s Wiki: https://github.com/davecliff/BristolStockExchange/wiki.

In the Python code for BSE you will see that PT2 is a verbatim clone of the simple prop trader algorithm called  PT1.  For  this  assessment,  you  should  alter/extend/replace the  PT2  code  and  then  explore  the behaviour of your new PT2 trader by running a series of sensibly structured comparative experiments, and then analyse the results from those experiments using appropriate visualization and statistical methods. You may want to adapt and extend the existing PT2 algorithm code, or you might want to instead implement someone else’s trading algorithm, such as “GD”  by  Gjerstad  &  Dickhaut  (1998),  which,  like  ZIP,  was demonstrated by Das et al. (2001) to outperform human traders, or one of its extensions such as MGD (Tesauro & Das, 2001) or GDX (Tesauro & Bredin, 2002) – see also (De Luca & D. Cliff, 2011); or you may want to try your hand at developing your own novel trading algorithm from scratch – maybe involving contemporary machine learning methods such as XGBoost (Chen & Guestrin, 2016; Chen, 2023), or LSTM Deep Learning (Hochreiter & Schmidhuber, 1997; Wray, Meades, & Cliff, 2020; Cismaru 2024).

Finally, you should write a brief report in the style of an academic research paper, as if you were going to submit it to an international conference for peer-review. It should clearly explain how your PT2 trader robot works, the design of the experiments to evaluate the performance of PT2, their outcomes, and your analysis of the results and whatever conclusions you draw in response to your analysis.  You are free to choose how to structure your paper, but it should at least include a clear introduction and explanation of: 1) your PT2 algorithm, citing any publications that influenced your design; 2) your choice of performance evaluation metric; 3) your design of experiments to evaluate PT2; 4) statistical analysis of the performance of your PT2; and 5) the conclusions you draw from the analysis of your experiment data.

Your report should be formatted according to the Springer Lecture Notes in Computer Science (LNCS) conference-proceedings format, details of which (including templates for Microsoft Word and for LaTeX) are available here:

https://www.springer.com/gp/computer-science/lncs/conference-proceedings-guidelines

The target word-count for your report is approximately 2000 words of text, but the hard length-limit is that it should be no more than eight pages in the required format (specified below) – in this format an entire page full of written English is about 500 words, so 2000 words of pure text would be only four pages, but to do a good job of this you will need to have figures/graphs/tables etc as well as the written narrative. should be no longer than eight pages in LNCS format, including all figures, references, equations, tables, and any snippets of code or pseudocode that you include to explain your PT2 algorithm. The full code for your Trader_PT2 algorithm should then be included as an appendix. The additional pages for appendices showing your code are not counted in the 8-page limit. Your paper That is, you can write eight pages of content explaining your work, and then the content on Page 9 and onwards should be just the code for your PT2, along with details of any edits you made elsewhere in BSE.py.

Background:

All of the robot trader strategies available in BSE other than PT1 and PT2 have been implemented to act in a manner inspired by the job of sales traders in real financial markets. A sales trader receives orders to buy and/or orders to sell from her clients, and then tries to best execute the order in the market: the client supplies the limit price, and the sales trader tries to get a deal at a price better than the limit.

In all the published research literature that we looked at in the lectures, the robot trading algorithms such as GD/MGD/GDX and ZIP have been tested in their capacity as sales traders: the robot is given an order with a limit price, and then the robot tries to get a deal at a price better than the limit.

However, in most markets there are not just sales traders. Another type of trader that a financial firm might employ is a proprietary trader, or “prop trader” . Prop traders buy and sell using the firm’s own money, or their own personal money: the job of the prop trader is to make a profit on these transactions, so basically the name of the game is to buy things when their price is low and sell them when their price has risen. Sometimes it may be necessary to sell for a lower price (e.g., if the market it is crashing, it is better to sell at a small loss now than wait and then have to sell for a larger loss later). Prop traders are usually allowed to buy and sell any type of financial instrument that they can make money on, although usually they will specialize in various asset classes: one person might be a prop trader in currencies; another might prop trade in tech stocks only; and so on. The most specialized a prop trader can be is to buy and sell just a single financial instrument, and BSE has only one tradable instrument, so you are being asked to develop a single-instrument intra-day prop trader for your PT2.

Recent intra-day cryptocurrency price time-series, binned at 5-minute time-resolution, are freely available for download from finance.yahoo.com. CSV-format data files for three example intraday cryptocurrency price time-series are available on the Blackboard page for this assessment, along with instructions for how to download more from finance.yahoo.com.

BSE.py (version 1.95) has been edited and extended to make it as simple as possible for you to complete this coursework assignment. PT1 and PT2 are initially identical, and the PT1 algorithm is explained in its class-definition docstring  (to find  this  in  the  code,  search for TraderPT1 (Trader) -- the explanatory “docstring” text follows immediately after this). In the code you download from GitHub, PT2 is a verbatim copy of PT1: your task for this coursework is to edit PT2, changing it to use whatever signals and algorithm you decide to implement; please only edit the definition of PT2, you should leave all the other trader-types as they are. It's important that you leave PT1 unchanged because that way you can compare the profitability of your revised/extended PT2 to that of the original PT1.

BSE.py offers two ways by which to specify the intra-day price-changes that are used to set the pattern of movements in the prices of the "customer order" assignments that the non-prop-trader agents execute in their role as automated sales traders, which in turn affect the bid and offer prices on the LOB and thereby influence the series of transaction prices seen in the market: the price changes can be specified by calling a price-offset function that returns a time-varying offset value determined by an equation; or the price-changes can be specified via an external data-file that is read in by the if name == "__main__" code at the end of the BSE.py file. In the __main__ code you can see instructions and three local function definitions that implement this functionality.

The three local functions are:

schedule_offsetfn_read_file(...) -- this reads in intraday prices from a .csv file and returns the sequence of [time, price] pairs in a single list.

schedule_offsetfn_from_eventlist(time, params) -- this returns the price offset for the current time by reading it from the list of [time, price] pairs.

schedule_offsetfn_increasing_sinusoid(t, params) -- this returns the price offset for the current time by calculating it from a sinusoidal equation that increases in amplitude and frequency over time.

To switch between offsets coming from a file or from an equation, you can edit the __main__ code that sets up range1 and range2 for the supply_schedule and demand_schedule respectively. In BSE.py, the supply and demand schedules are set to read their price-offsets from a file. Immediately after the opening test for if name == "__main__" come three lines of code that deal with assigning a value to the variable price_offset_filename, which is the name of the data-file that will be read in. The first is a simple assignment: price_offset_filename = 'offset-BTC-USD-20250210.csv' -- this reads in a CSV file of intra-day BTC-USD prices recorded at 5-minute time resolution on 10th   February 2025. If you press "run" in your integrated development environment (IDE, such as PyCharm or Idle) or if you execute from your PC's terminal command-line interface (CLI) via a command such as:

python3 BSE.py

then the BSE market session(s) you run will use the movements of BTC-USD stock on 10/02/25 to generate the  price offsets. Thus, one way of altering what data-file  is  read from  is to just  edit that assignment of price_offset_filename to some other filename. However, another way of altering the name of the price data file  is  available  if you're  using the  CLI:  if you  supply  an  additional argument to the call of BSEv.1.95.py then that filename overrules the default BTC-USD filename. For example, if you enter on the CLI:

python3 BSE.py offset_BTC_USD_20250211

then your BSE price-offsets will be based on the data from that CSV file (which is a time-series of movements in the USD price of BTC on 11th February 2015) instead.

As an example, Figure 1 shows the sinusoidal offset function produced when using a positive value as the scale parameter for schedule_offsetfn_increasing_sinusoid:the prices offsets get progressively larger and the average price steadily rises (if scale is negative, the price offsets get progressively more negative and the average price declines over the session).

Figure 1: Sinusoidal price offset function with scale>0, resulting in peak prices progressively rising.

And Figure 2 then shows the sequence of transaction prices in BSE when that offset function is used.

Figure 2: Transaction prices for a single 7.5hour BSE market simulation using the equilibrium price-offset function shown in Figure 1. Horizontal axis is time measured in hours; vertical axis is transaction price measured in cents. Each blue data-point marker on the graph is an individual transaction.

As can be seen from Figure 2, the time series of transaction prices in BSE follows the shape traced by the offset function of Figure 1, but there is quite a lot of noise/variance in the actual transaction prices because of the presence of "noise traders" such as ZIC in this market. Figure 3 shows the accumulated bank-balance of a single PT1 trader operating in the market experiment of Figure 2.

Figure 3: Account balance of a single PT1 trader operating in the market session for which transaction prices were illustrated in Figure 2. Horizontal axis is time measured in seconds; vertical axis is account balance in cents.

Figure 4 shows the 24-hour time series for intraday price movements in the example offset data file for BTC- USD on 11th  February 2025.

Figure 4: 24-hour time-series for USD price of Bitcoin at 5-minute intervals over 11th February 2025.

And Figure 5 then shows the transaction-price time series for a one-day BSE session using that 11/2/25 BTC- USD data-file for the offset function: the pale blue markers are the transaction prices; the red markers show the simple moving average (SMA) of the most recent 100 transaction prices. As you can see, the SMA matches the movements of the BTC-USD input data very well.

Figure 5: Transaction-price time-series in a market session for which the price offset function was illustrated in Figure 4. Format as for Figure 2. Blue markers are individual transaction prices; red markers are the simple moving average (SMA) of transaction prices over the preceding five minutes (300sec).

As can be seen from Figure 5, the rises and falls in the SMA(300) very closely match those of the original BTC-USD time-series, and the difference in absolute values of prices (i.e., the BTC prices are all in the $90,000 range, while the BSE prices are in the range $1-$2) is merely a result of a constant scaling coefficient applied within BSE.

Figure 3 shows that the PT1 trader has periods (when the market price is rising) where it is trading profitably and its bank-balance is growing, and periods (when the market price is falling) where it is no longer making a profit but is not actually losing money either. Your job for this assessment is to try to come up with something more profitable than PT1: good luck!

You are certainly not limited to using only the three one-day BTC-USD price time-series data available on Blackboard: similar intra-day price time-series for very many cryptocurrencies are available online, and you should use as many one-day price series as you think appropriate. If you are using a data-intensive machine- learning approach such as Deep Learning neural networks, you may find that you need a lot of training data, more than is available from sources of real-world intraday price series. In that case you may want to write a synthetic data generator (SDG) that uses a known/accepted mathematical model of financial asset price changes such as Geometric Brownian Motion with Jumps, to create plausibly realistic fictional intra-day data: see, for example: https://mtns.math.nd.edu/papers/19046_4.pdf .

You may initially want to place a hard limit on the size of any one trader’s inventory: this should help keep the market liquid, as it will prevent one trader amassing a huge inventory. For example, if the limit on inventory size is three, any AMM trader can buy stock until it is holding three items, at which point its only allowable action is to sell. Similarly, if an AMM trader sells an item and thereby reduces its inventory to zero items, its only allowable action will be to buy (that is, the AMM trader cannot “short” the stock, selling items it does not currently own: so technically we are asking you to implement a long-only AMM trader). Traders holding one or two items in their inventory would be free to sell or to buy (or to simply wait), depending on what their strategy indicates is best to do, given the current market conditions.

It is fine if you want to start by using a previously-published algorithm like ZIP or MGD and then alter or extend it – that’s how a lot of progress in science and engineering is made. But if you want to start from scratch, that is absolutely fine too. We’re not requiring you to write a new (or revised) algorithm, but you can probably pick up some extra marks by at least trying to do so: your algorithm certainly doesn’t have to be world-beating, but  you are expected  to  explain  the  design  choices  you  made  and  to  show  that  you  know  how  to experimentally evaluate a new trading algorithm in the relatively simple context of BSE.

Also, your  PT2 is  not  required to  be better than  PT1:  it could  be that you decide to  implement  some interesting-looking new machine learning method, Method X, in your PT2 but then in evaluation testing you realised that for some reason Method X does not work well in the context of intra-day crypto trading. You will not lose marks for negative results such as this, so long as the design decisions you make in creating your PT2 are well explained and justified, and so long as your implementation and evaluation/testing analysis is appropriately designed and rigorous.

You should write your PT2 code using the current stable release of Python (Version 3.11, as of Feb. 2025). Along with your paper, we would like you to submit the source-code for your trader class, as an appendix. If you make any changes to other parts of BSE (e.g. to produce additional output files from a market session), please also explain those in an appendix to your paper,but note that we expect your PT2 to run in the GutHub version of BSE.py. Please do not include all of your version of BSE.py: we are not interested in the code you didn’t edit: all that matters is the code for your new PT2 trader, and specific details of any changes you made elsewhere in BSE.py.

Please add the trader code as an appendix to your paper, and also any code snippets for edits elsewhere in BSE.py, so that everything required is all in one PDF file. Please only submit a single PDF file and nothing else (that is, no source-code other than your Trader_AMM, no data files, no gzip files, no tarballs).

We will randomly select some of your submissions for test-runs: we’ll take your trader code and run it in the GitHub release of BSE.py, to check that the results in your paper are independently replicable. If we can’t replicate your results within reasonable error margins, then the final grade you get is likely to be severely reduced. The bottom line is: (a) to be safe, don’t make any substantive changes to BSE.py except for the Trader sub-class that you edit; (b) don’t fake or edit your results, because falsifying results is academic misconduct on the same level as plagiarism or cheating in an exam.

Marks will be awarded for:

• Quality of Experiment Writeup: 25%

How well is the paper structured? How clearly does it explain the background to your work, and what you have done?

• Quality and Presentation of Results: 25%

How thoroughly is the experimental evaluation carried out? How clearly are the results presented?

• Quality of Statistical Analysis and Conclusions: 25%

Are appropriate statistical analyses chosen and conducted correctly? Are correct conclusions clearly drawn from the analysis, and explained well?

• Challenge and Originality: 25%

How challenging is the task you set yourself? How comprehensive are your PT2 and the experimental setup? How extensive is the analysis?

Marks will be deducted for:

•    Your paper is not submitted in LNCS format.

•    The text of your paper is longer than 8 pages. The 8-page limit includes everything: title, abstract,

main text, all figures/graphs/diagrams/tables, the References/Bibliography, all footnotes and endnotes, and any appendices other than the source-code appendix. The source-code appendix   showing your Python code should start no later than at the top of page 9. You can use as many pages as you need to print your Python code.

•    You have set a smaller font-size than the LNCS standards, and/or you have set the margins to be

thinner, and/or you format graphs/diagrams/figures/tables to occupy ridiculously small amounts of page-area, all of which are common (but idiotic) attempts to fit more content on each page, in the  hope that we don’t notice that actually you’ve written much more than the 8-page maximum in standard LNCS format.

•    You have set a larger font-size than the LNCS standards, and/or you have set the margins to be wider, and/or you format graphs/diagrams/figures/tables to occupy disproportionately large amounts of page- area, all of which are common (but idiotic) attempts made to fit less content on each page, in the hope that we don’t notice that actually you’ve written much less than the 8-page maximum in standard LNCS format.

Please note that the LNCS format sets specific margin widths on all four edges of the page and uses a 9- point (9pt) font for the text of the Abstract, for Footnote text, and for the References, and a 10pt font or the main text of the paper. The conventional advice for the labelling in figures/diagrams/graphs/tables is that the font-size used for the labels should be no smaller than the font used for footnotes, so please ensure that the font size on all label-text in your figures/diagrams/graphs/tables, when sized to print in your paper, is no less than 9-point.

References

H. Ashton (2022), Law-breaking trading algorithms: Emergence and Deterrence. PhD thesis, Department of Computer Science, University College London. https://discovery.ucl.ac.uk/id/eprint/10155509/3/Ashton_10155509_Thesis_id_removed.pdf.

T. Chen, (2023), XGBoost Documentation. https://xgboost.readthedocs.io/en/stable/index.html.

T. Chen & C. Guestrin (2016), XGBoost: A Scalable Tree Boosting System. In Proceedings 22nd ACM International Conference on Knowledge Discovery & Data Mining (KDDM2016) pp.785-794. https://arxiv.org/abs/1603.02754.

A. Cismaru, (2024) DeepTraderX: Challenging Conventional Trading Strategies with Deep Learning in Multi-Threaded Market Simulations. Proceedings of the 16th International Conference on Agents and Artificial Intelligence

(ICAART2024). SSRN: https://ssrn.com/abstract=4692622.

D. Cliff (1997), Minimal-Intelligence Agents for Bargaining Behaviours in Market-Based Environments. Hewlett- Packard Labs Technical Report HPL-97-91. https://www.researchgate.net/publication/235963415_Minimal-

Intelligence_Agents_for_Bargaining_Behaviors_in_Market-Based_Environments#fullTextFileContent.

D. Cliff (2018), BSE: A Minimal Simulation of a Limit-Order-Book Stock Exchange. In: Bruzzone F (ed) Proceedings of 30th European Modeling and Simulation Symposium (EMSS2018), pp 194-203. https://arxiv.org/pdf/1809.06027.

D. Cliff (2023), Parameterized Response Zero Intelligence Traders. Journal of Economic Interaction and Coordination, 19:439-492. SSRN: https://ssrn.com/abstract=3823317.

R. Das, J. Hanson, J. Kephart, & G. Tesauro (2001), Agent-Human Interactions in the Continuous Double Auction. In: Proceedings IJCAI-2001, pp. 1169-1176. https://dl.acm.org/doi/10.5555/1642194.1642251.

M. De Luca & D. Cliff (2011), Agent-Human Interactions in the Continuous Double Auction, Redux:  Using the OpEx Lab-in-a-Box to explore ZIP and GDX. In Proceedings of the 3rd International Conference on Agents and Artificial

Intelligence (ICAART-2011), pp. 351-358. https://www.scitepress.org/papers/2011/32939/32939.pdf.

S. Gjerstad & J. Dickhaut (1998), Price Formation in Double Auctions. Games and Economic Behavior, 22(1): 1-29. https://www.sciencedirect.com/science/article/abs/pii/S0899825697905765 .

D. Gode & S. Sunder (1993), Allocative efficiency of markets with zero-intelligence traders. Journal of Political Economy, 101(1): 119-137. https://www.jstor.org/stable/2138676.

A. Guarino, L. Grilli, D. Santoro, F. Messina, & R. Zaccagnino (2022), To learn or not to learn? Evaluating

autonomous, adaptive, automated traders in cryptocurrencies financial bubbles. Neural Computing and Applications,

34: 20715-20756. https://dl.acm.org/doi/abs/10.1007/s00521-022-07543-4.

S. Hochreiter & J. Schmidhuber (1997), Long Short-Term Memory. Neural Computation, 9(8): 1735-1780.

https://direct.mit.edu/neco/article-abstract/9/8/1735/6109/Long-Short-Term-Memory.

J. Rust, J. Miller, & R. Palmer (1992), Behavior of trading automata in a computerized double auction market. In: D. Friedman & J. Rust (eds.) The Double Auction Market: Institutions, Theories, & Evidence , pp.155-198. Addison-

Wesley. https://www.santafe.edu/research/results/working-papers/behavior-of-trading-automata-in-a-computerized-dou.

P. Shinde, I. Boukas, D. Radu, M. de Villena, & M. Amelin (2021), Analyzing Trade in Continuous Intra-Day Electricity Market: An Agent-Based Modeling Approach. Energies 14, 3860. https://www.mdpi.com/1996-1073/14/13/3860.

G. Tesauro & R. Das (2001), High-Performance Bidding Agents for the Continuous Double Auction. In: Proceedings of the 3rd ACM Conference on Electronic Commerce, pp.206-209. https://dl.acm.org/doi/10.1145/501158.501183.

G. Tesauro & J. Bredin (2002), Sequential Strategic Bidding in Auctions using Dynamic Programming. In: Proceedings AAMAS 2002. https://dl.acm.org/doi/pdf/10.1145/544862.544885.

C. Van Oort, E. Ratliff-Crain, B. Tivnan, & S. Wshah (2023), Adaptive Agents and Data Quality in Agent-Based Financial Markets. Arxiv: https://arxiv.org/pdf/2311.15974.

A. Wray, M. Meades, & D. Cliff (2020), Automated Creation of a High-Performing Algorithmic Trader via Deep

Learning on Level-2 Limit Order Book Data. In Proceedings of the 2020 IEEE Symposium Series on Computational Intelligence (SSCI). Arxiv: https://arxiv.org/pdf/2012.00821.