Note: this article was written in collaboration with Arnaud Amsellem, aka the R Trader.
With the increase of market “electronification”, algorithmic trading is becoming more and more popular. As a result, the regulator has paid particular attention to this activity in the MIFID II regulation, designing a brand new set of rules. Market participants are now operating within a more rigorous and stringent framework than ever before. This profoundly changes the way this business is run in investment banks.
What exactly is a trading algorithm?
Even after reading the regulatory text, RTS 6 (Regulatory Technical Standard) of MiFID II for the interested reader, the definition is still very much a function of interpretation and how the trading business has been set up. In other words, from one bank to another this might vary quite significantly but some common features can be isolated. There are actually two components to that definition:
- Any computer formula that determines which instrument to buy or sell
- Any computer formula that sends indicative or executable prices out to a trading platform and/or generates, executes and manages orders on a trading platform.
This is a rather large definition and it means that even a simple spreadsheet gathering prices from various providers and publishing, let’s say, an average of them on a trading venue is an algorithm. There are many such tools floating around in investment banks and the very first task is to make a proper inventory of them. In addition to spreadsheets, there are more advanced systems that have been built internally over time and off the shelf solutions. Very often a mix of in-house and external solutions is “glued” together in production.
Within the world of algorithmic trading, the regulator gave a special treatment to High Frequency Trading (HFT). This is defined as a subset of algorithmic trading characterised by an infrastructure to minimise network latency, a system determination of trade lifecycle events without human intervention, and a throttling rate (number of messages streamed to a trading venue per unit of time usually seconds) of only two per instrument and trading venue or four per trading venue.
Trading algorithms taxonomy
Trading algorithms come in different shapes, colours and forms. Actually individual algorithms are designed to serve some very specific purposes. Some are designed to optimally slice orders according to some criteria, some are designed to widen the bid/ask spread (for quote) in some market conditions, some are designed to make sure prices provided to the clients are still in line with the market i.e. “last look” etc. But what makes a true trading algorithms is a combination of all the above that faces the market i.e. interacts directly with the market. A first distinction can be made between Execution and Quoting algorithms.
- Execution algorithms are designed to execute clients order based on a certain set of constraints/instructions. For example a client might wish to execute an order immediately or on the contrary trade with the market flow.
- Quoting algorithms are designed to provide to market participants executable bid and ask quotes.
A second distinction must be made between meta-algorithm and sub-algorithm. One regulatory requirement (see below for details) is to register algorithms with the trading venues and the algorithms that must be reported are the ones that face the market. However as any investment banks must also be able to explain/prove how price construction works within its framework, a process that traces price construction must be in place. This is why it’s important to divide algorithms within another axis:
- Meta-algorithms: These are the algorithms that face the market. A meta-algorithm is made of many building blocks.
- Sub-algorithms: These are the individual building blocks of a meta-algorithm. The sub-algorithms are designed to address a very specific problem like order slicing, spread widening , last look etc.….
In addition, the “pipes” that link the bank algorithmic trading infrastructure to the market (i.e. a gateway) might also contain some other sub-algorithms. Those are, most of the time, the ones that check trading limits: individual trader limits, desks limits, limits by product, limits by clients etc…
Here’s an example. Let’s assume a bank is a market maker and quote a liquid product. As a market maker the bank has the obligation to provide continuous Bid and Ask prices during the trading session. In this example we could call the meta-algorithm “Quoting” and there are many sub-algorithms handling all parts of the quoting process. Below is a non-exhaustive list of sub-algorithms that could be applied:
- Price construction: This usually uses feeds from external providers and some internal calculation to define the mid-price.
- Bid/Ask spread: using the mid-price as a reference, some other calculations are performed to provide to the market a reasonable Bid/Ask spread
- Spread widening/tightening: This is performed in order to provide more competitive or conservative price. It depends on a lot of factors ranging from bank overall exposure to statistical analysis of price behaviour.
- Last look: Once a quote is provided and a client wishes to execute on that quote a final check is performed to ensure the quote provided is still in line with the market. This is common practice and very sensitive to latency hence the need for a proper infrastructure.
What are the new regulatory requirements?
Algorithmic trading activities are now under more scrutiny due to repeated scandals. The regulator in Europe decided to provide a stronger framework; those new requirements are designed to create a more secured environment. Below are the main features of the new regulation:
- All algorithms should be properly documented. This includes certification and registration with trading venues
- All algorithms must have owners and IDs and those IDs must be communicated to trading venues
- All algorithms must be deployed in a controlled and documented manner and all changes should be recorded.
- Staff must acquire the necessary knowledge and must be trained to run algorithmic trading systems
- Firms must perform annual self-assessment. This means reviewing and evaluating their algorithmic trading systems and trading
- Resilience of the algorithmic framework: This includes real-time monitoring, pre-trade controls, Kill switch etc.….
- Enhanced testing requirements: this includes dedicated testing environment, pre-defined methodology for developing, testing, deploying and stress testing algorithms
What is changing now?
The increased scrutiny from the regulator put a lot of pressure on banks to be more transparent on their algorithmic trading business. The new requirements impose that everything gets properly documented, recorded and tested. This creates extra work and cost for banks. In particular highly skilled staff has to be recruited to insure that the proper IT infrastructure is up and running at any time. Compliance departments also have to hire dedicated staff to address the new regulatory burden. Despite all those new costs and constraints banks have no other choice than embracing algorithmic trading as this is how financial market will operate going forward. In a nutshell algorithmic trading is here to stay!