Andrew Kumiega

Ethics, Finance, and Automation: A Preliminary Survey of Problems in High Frequency Trading

All of finance is now automated, most notably high frequency trading. This paper examines the ethical implications of this fact. As automation is an interdisciplinary endeavor, we argue that the interfaces between the respective disciplines can lead to conflicting ethical perspectives; we also argue that existing disciplinary standards do not pay enough attention to the ethical problems automation generates. Conflicting perspectives undermine the protection those who rely on trading should have. Ethics in finance can be expanded to include organizational and industry-wide responsibilities to external market participants and society. As a starting point, quality management techniques can provide a foundation for a new cross-disciplinary ethical standard in the age of automation.

Trading Machines: Using SPC to Assess Performance of Financial Trading Systems

Traditional quantitative methods used in finance, developed to control market risks accumulated by human traders, do not incorporate quality control. Finance is moving from manual to computer numerical control (CNC). The authors view trading systems that employ CNC as machines with variable outputs—outputs that can be inspected using statistical process control (SPC). Using a sample trading system, they find that quality metrics generate an investment signal contrary to that generated by the traditional metrics of finance. To manage trading machines, SPC can be used in conjunction with classical financial metrics to control risk in systematic trading and investment.

Trading Model Uncertainty and Statistical Process Control

This article examines the use of statistical process control (SPC) as a methodology for monitoring trading model uncertainty. Traditional quantitative risk management methods do not incorporate the inherent process control problems financial modeling. The reference adaptations apply to the a priori model design process and a posteriori model control. To build and monitor trading models, SPC can be used in conjunction with classical financial metrics to better control market risk.

Kaizen: Continuous Improvement

This chapter focuses on the concept of kaizen used in the development of trading systems. Kaizen in Japanese means continuous improvement. As a business strategy, it aims to eliminate waste in business processes. In the context of developing trading systems, kaizen is the process of continually searching for and implementing new quantitative methods, new data cleaning techniques, new optimization routines, new technologies, and new risk management methods that lengthens the maturity stage of a trading/investment system. Several methodologies exist for continuous improvement. The most widely known is the four-step quality model known as plan-do-check-act (PDCA) cycle. Other widely used methods, such as Six Sigma, Lean, and Total Quality Management, extend the PDCA model to emphasize management involvement and teamwork, measuring processes, and reducing waste and lowering cycle times. Six Sigma models for process improvement include DMAIC and DMADV. DMAIC stands for Define-Measure-Analyze-Improve-Control, which is applicable to an existing system. DMADV stands for Define-Measure-Analyze-Design-Verify, which is applicable to new systems. When applied to a trading environment, a continuous improvement strategy involves management, kaizen teams, and reformulated product teams, working together to make small improvements continuously. It is thus top managements responsibility to cultivate a professional environment that engenders kaizen as a culture of sustained continuous improvement focuses efforts on optimizing trading/investment systems.

Beyond the Flash Crash: Systemic Risk, Reliability, and High Frequency Financial Markets

Extreme events in financial markets can arise from fundamental information, but they can also arise from latent hazards embedded in the market design. This concept is known as systemic risk, and someone must bear it. Extreme events add to risk, and their probability and severity must be accounted for by market participants. This article shows how this risk fits into the finance literature and that, from an engineering perspective, this risk in markets has never been lower. The industry is evolving to mitigate this risk. This article presents an overview of the complexity of the automated market network and describes how market participants interact through the exchange mechanism. It defines new terms and a new framework for understanding the risk of extreme market moves from a reliability and safety perspective.

A Practical Real Options Approach to Valuing High Frequency Trading System R&D Projects

In the age of automation, trading and market making is about estimating the fair price of automated trading system research and development projects. This requires a new methodology to arrive at such a fair price. A real options framework is a natural choice. In this paper we review a methodology for automated trading system R&D as well as a practical real option model for valuing such projects so as to enable rapid strategy cycling.

Independent Component Analysis for Realized Volatility: Analysis of the Stock Market Crash of 2008

This paper investigates the factors that drove the U.S. equity market returns from 2007 to early 2010. The period was highlighted by volatile energy and commodity prices, the collapse of insurance and banking firms, extreme implied volatility and a subsequent rally in the overall market. To extract the driving factors, we decompose the returns of the S&P500 sector ETFs into statistically independent signals using independent component analysis. We find that the generated factors have interesting financial interpretations and are consistent with the major economic themes of the period. We find that there are two sets of general market betas during the period along with a dominant factor for energy and materials sector. In addition, we find that the EGARCH model which accommodates asymmetric responses between returns and volatility can plausibly fit the high levels of variance during the crash. Finally, estimated correlations dropped when commodity prices moved higher, but then spiked when the S&P500 crashed in late 2008.

13 – STAGE 2: Overview

This chapter presents an overview of the backtesting process, which is essentially the make or break stage of the trading/system design and development project. Performance of the system at the end of this stage will be the performance of the working system. Either the system generates acceptable performance or it does not. If the system does not, then the project is stopped or sent back to Stage 1. This spiral also contains the highest risk as testing migrates from a very small sample data set used to prove components in Stage 1 to a real set of data and all of the issues that go along with real data. Data can make or break a trading/investment system and selecting, cleaning, and filtering out bad data is the key stage in the development cycle, which will be important for risk management in Stage 4 as well. The initial test data could be an anomaly versus real data that does not prove the concept. Product teams often try to force the system to work with the real data, attempting to find anomalous data where it proves successful. After this loop, the building of the system is a straightforward process since only the interfaces and algorithm control (SPC and risk management) system are left to be completed.

Perform In-Sample/Out-of-Sample Tests

This chapter focuses on performing proper in-sample and out-of-sample tests, which is perhaps the most critical step in the trading/investment system development process. If the system is profitable both in sample and out of sample, it is likely to receive capital to begin implementation and trading as soon as possible. If a system is profitable only in sample, it may be allocated additional resources for continued research and/or sent back to Stage 1. If, however, the system proves to be unprofitable both in sample as well as out of sample, management will likely scrap the project altogether mainly due to the nonscalability of the trading idea. In-sample testing is very time intensive, as the team manually checks the calculations and results. During the in-sample test, algorithms may calculate the averages and standard deviations for trades. This is the step where the team converts all the prototype examples into prototype production-level code. In-sample testing also exposes irregularities in the data, so that the development team can make necessary modifications. Out-of-sample testing is done to ensure everything is working properly, with no adjustments and with almost real-world data and samples. During the out-of-sample testing, no more modifications can be made. Trading algorithms and quantitative models are examined against both in-sample and out-of-sample data before progressing to the implementation stage, so it is of utmost importance to save some of the historical data for out-of-sample testing.

Optimal Trading of ETFs: Spreadsheet Prototypes and Applications to Client-Server Applications

This paper presents an application of an Excel spreadsheet-development methodology used by quantitative analysts and traders in financial markets. The spreadsheet used regression and Excels Solver to determine the optimal investment of a firms risk capital. The proprietary methodology used to develop real-time trading tools and its repetitive design structure allowed the firm to become a market-maker exchange traded fund (ETF) rapidly. By adhering to the methodology, the firms documentation of user requirements, data inputs, calculations, and user interfaces, and a full prototype using Excel, made incremental growth possible and provided a solid foundation for conversion into coded software. Rapid development gave the firm the opportunity to derive revenue from market-making activities in new investment products; these would become a major source of revenue. This methodology, which the authors presented in 2001 at the International Conference on Software Quality in Pittsburgh, Pennsylvania, and its implementation led to the development of a complete trading-system development methodology.