Over the last decade we have seen an electronification of trading, a shift from traditional sales-traders to e-trading. And this not just the case for high-frequency traders but investment banks in general and it is clear what the future holds. What does it mean for Compliance professionals though? Do we need to learn coding to understand the algorithms that execute the trades? We paint a picture of the status quo and tell you how you should prepare for the future.
A growing amount of client trading is handled by algorithms. There are a number of reasons why, but mainly it’s about the ability to execute with far greater efficiency whilst also reducing the market impact of your trading activity.
Manual traders could never consider the breadth of data and information captured and considered by an algorithm, or alternatively execute with the same speed and frequency. Historically, clients call their trader with an order or request for quote, and traders go into the market to get the best possible price for their client.
When trading via an algo, traders submit their client’s order into their computer which then proceeds to execute the trade – or alternatively, clients enter their own orders directly into an execution platform. What this means is that the computer decides either when, where and what (or a combination of these) to actually buy or sell, as well as doing so faster than any human being ever could. Additionally, it makes no mistakes.
But algorithms have a downside too. We’ve experienced enough full-blown and mini flash crashes over the last decade or so, all traced back to rogue algorithms, to understand just how disruptive a misbehaving algorithm can be – this in turn also explains the anxiety experienced by regulators trying to get to grips with what is becoming the new age of trading.
The other week I had a post-work catch-up with two of our e-traders, whilst watching the beginning of Croatia’s unraveling of Argentina in the World Cup. Coincidentally we ran into one of their clients and briefly spoke.
It was quickly revealed that the client company was treating all of its staff (and family) to a week in Bermuda the following Monday. As their broker, we asked, but who will be manning the deck and sending through orders for execution? The response we got was simply ‘the machines can take care of themselves’.
I could at this point enter into a lengthy discussion about how appropriate leaving machines to take care of themselves may be, but suffice to say we were impressed.
Instead, the purpose of this article is to introduce the topic of what it means to cover an electronic trading business from a compliance perspective and how this differs from covering a more traditional high touch (or voice) desk.
Instead of trying to manage the human traits and characteristics that may tempt an individual trader to conduct mis-selling practices or market abuse at the expense of either a client or the market, the new breed of compliance professionals will need to understand how an algorithm is intended to behave and get comfortable levels of quality assurance testing and monitoring (real-time and post) required on a system by system basis, as well as which controls must be in place so as to prevent unintended executions.
The majority of the more traditional market abuse behaviours with which a compliance function is familiar remain in title, but the manner in which they will manifest themselves is entirely different.
Of upmost concern to an e-trading compliance officer is prevention of activity which can lead to disorderly markets. One might assume that having less manual processes leads to less operational risk, and whilst that may be true in practice, there is also argument for the fact that when dealing with algorithms there is a huge increase in the scale of the risk when problems do appear. One rogue piece of code can take down an entire market.
To illustrate the challenge from a compliance perspective, how does the compliance officer ensure that neither a house trader, nor a client make use of an algorithm for the purposes of committing market abuse?
As it stands, compliance officers do not tend to be able to read/write any coding languages and the ability for them to review actual code is therefore very limited.
It may be that a future generation of risk controllers will need such skills (the creation of independent risk functions across major investment banks, which sit somewhere between the business and compliance, is a step in this direction) in order to properly execute their function.
By example, does an algorithm have the ability to place orders for the purpose of detecting liquidity (pinging) and thereby possibly to detect the existence of a large buyer or seller to front run, rather than for the purpose of bona fide execution? I can ask the quant (who devised the trading strategy based on quantitative analysis), and can get a ‘yes’ or ‘no’, but is that enough? (If you want to know more about quant trading, have a look here).
The regulators expect risk functions to dig deeper than that. Strategies which enter orders of any type and on any venue and which are designed to detect the existence of a large buyer or seller to front run, rather than trade with, may be deemed to be manipulation.
A ‘pinging’ order is a marketable order (typically of small size) that can be used to search for, and to access all types of non-displayed liquidity.
The type of answer that may be more satisfactory is one that might say ‘ Execution is never driven by logic which seeks to opportunistically hit a price that doesn’t exists to see if it might and then make decisions based off that. Trades are only executed following client orders.
In other words, clients can (only) place an order, but it is the system which decides where execution occurs, and therefore pinging not an option that client can choose. The algorithm itself has minimum quantities that it must adhere to, and pinging tends to be done using smaller sizes (in the event that it executes).
The only time the algorithm will allow for smaller amounts to trade is if it is looking to fill residual amounts. Accordingly, only clients can place orders, and they don’t have choice over how to execute, and the algo is subject to its own minimum quantity executions, both of which in turn satisfies my concerns of the ability to perform ‘pinging’.
In its recent paper on Algorithmic Trading Compliance in Wholesale Markets the FCA warns, “In the absence of appropriate systems and controls, the increased speed and complexity of financial markets can turn otherwise manageable errors into extreme events with potentially wide-spread implications.”
Because of this, it adds, “We will continue to assess whether firms have taken sufficient steps to reduce risks arising from algorithmic trading.”
But how do you prevent a quant from releasing a piece of code into production without going through the proper channels of testing and approval? It’s even possible that the release will be made in good faith. Imagine, if you will, that you are performing regression testing against a new system prior to go-live, and successful testing is a condition of release.
The quant is confident he/she knows why the testing fails, and is of the view that this is down to an anomaly in one single line of code. The quant knows how much effort and resource can be required to re-work existing code, so they quickly correct the characters that they believe are inadvertently causing the testing to fail. The system now passes the test.
The quant was right in narrowing down what was causing the testing failures, but could be blissfully unaware of what this code was trying to prevent. By removing the suspected problem, the quant might now have removed the control that was otherwise built into the code of said system.
Being able to trace new releases of code and systems is crucial in being able to meet regulatory expectations, and to demonstrate to regulators that only staff of appropriate seniority should have the ability to approve the release of new code.
The difficulties presented here are manifold. Some system releases are considered ‘day-2-day’ management of a system, and is a requirement for the successful running of that algorithm.
Alternatively, some releases warrants the appropriate levels of testing, monitoring and scrutiny by control functions, as per regulatory requirements. This then means that we need to define what requires approval (material changes) versus what the desk should be able to release changes as part of the normal running of the algo.
However, even if a definition is agreed, how do we ensure that all material releases are routed via the desk head for review prior to release? If every ‘change’ is flagged to the desk head, they will not be spending their time on anything other than reviewing releases.
If we don’t flag every instance of change, then some reliance is placed on the relevant staff to flag their release, as the system itself won’t be able to make the determination.
There is a constant competing interest for keeping the time period between development and deployment as narrow as possible (to stay commercially competitive), against giving control functions enough time to properly assess system changes and provide the required challenge.
Far from seeking to deter any compliance officers reading this piece, I would urge them to gain as much exposure to this area as possible and get ahead of the game. The direction of travel by investment banks is towards increased e-trading and the traditional notion of a sales-trader is becoming less and less relevant. Also, currently there is no expectation that a compliance officer knows how to read code. Actual testing of models is performed by the independent risk functions and testing teams that sit alongside the traditional second line of defence. The underlying risks of market abuse and to the maintenance of market integrity remains the same, it is the manner in which these are controlled which has changed.
Jonathan Jordan is a compliance professional in investment banking with a keen interest in technology and innovation and their potential to change the financial industry as we know it. You can follow Jonathan on Twitter at @j_e_jordan