By Sam Tyfield, Vedder Price
On technology failures generally
Mary Jo White of the SEC has announced publicly that :
“[the SEC’s] objective has to be zero tolerance… We all know technology is never going to be perfect so we also have to focus on what you do when you do have an incident.”
Should there be a “but” in there somewhere? Zero tolerance to systems errors does not sit well with an acknowledgement that IT and automated systems are never going to be “perfect”.
So, one may wonder how the regime will be implemented: zero tolerance of any errors whatever their market impact and how they’re dealt with; or zero tolerance of errors not being dealt with acceptably. If it is the latter, that means the industry is going to need to understand what is an acceptable way of dealing with technology-related issues. The industry is going to need to understand also on whom this liability will fall. Dividing the participants into four general types, you have:
- Trading firms
- Clearing firms and DMA providers
- ISVs and other ‘mission critical’ third party providers, such as market data providers, infrastructure providers etc.
How the liabilities and responsibilities fall between them is not quite an open question among market participants – relatively standard documentation exists containing indemnities/warranties, ISO standards are complied with, parties conduct due diligence on one another – pretty much, most participants know where they stand as regards liability to and from others.
However, regulators on both sides of the Atlantic may be mandated to seek to change this paradigm.
One related ‘for instance’: I attended a meeting at which Matthew Nunan, head of wholesale enforcement at the UK FCA, stated that DMA providers were “gatekeepers for” and “enablers of” market abuse. Part of a DMA provider’s responsibility therefore was to consider imposing OTR limits and minimum resting periods on its clients (or some of its clients’ strategies) separate, please note, to any imposed elsewhere pursuant to regulations governing venues maintaining a ‘fair and orderly market’.
Obviously, this is a topic for discussion in and of itself. However, for present purposes, I use it to illustrate a point about technology and systems.
Market Abuse Regulations – technology and infrastructure impact?
If pre-trade risk checks are automated and fail, then after whom would the relevant competent regulatory authority come – the trading firm and the DMA provider most likely, the venue possibly, but what about the employee or vendor which provided/built the system or the infrastructure on which it ran?
At what point does having or building a system (a) become abusive of the market or assist in or facilitate the abuse of the market because the technology/infrastructure in it has failed or (b) be inherently insufficiently robust to satisfy ones responsibilities under MAR/MiFID 2 if it can fail?
ESMA released a discussion paper on the new draft market abuse regulations on 14 November 2013. The discussion paper will be followed by a consultation. It does seek to deal with the fudging of the differences between ‘market abuse’ and ‘technology failures’ – see Annex IV in particular. However, at what point will the owner, operator or designer of or contractor to an automated trading system which has been used for market abuse (due to a technology failure) or which could be used for market abuse (because the technology could fail) be guilty also of market abuse?
Market Abuse Regulations – operational considerations
The ESMA discussion paper refers directly to the ESMA Guidelines on Systems and Controls in an Automated Trading Environment which have been in force since May 2012. Whilst those Guidelines are now understood (and groups like the FIA PTG and the FOA have provided granular best practice guidance to market participants), the issue remains that MiFID 2’s relationship with the draft MAR is uncomfortable.
Article 17 of MiFID 2 provides (among other things) that participants must only design and build trading systems which cannot be used in breach of MAR. So what is the industry to do? Should it take comfort that if it complies with the Guidelines, if a system is used contrary to the Market Abuse Regulations, then it has a valid defence, at least so far as its systems and controls are concerned (as long as they worked as per their design? I’m not sure we can be confident of that.
Technology understands processes, parameters and well-defined series of instructions.
It is settled that monitoring for market abuse has to be undertaken on a near-realtime or realtime basis (rightly or wrongly is not a question for now). However, as is plain from the draft regulations, the regulators have in mind indicia of the types of activities that could constitute market abuse. That implies a uniquely human thought process – not one easy to automate.
Whilst (very good) products are available commercially (and are used by regulators, brokers and trading firms) to identify and combat market abuse, it does beg a question for the future. A firm will know (or be able to recognise) abusive activities within the parameters understood (and therefore set) by it, its brokers and venues and will be able to program its systems accordingly. But what if a regulator regards some activity (or omission) as abusive which is not recognised by the system? The system is in breach of MiFID but has not failed.
The system builders and designers have arguably assisted in or facilitated market abuse or manipulation.
Just as the regulators have called for compliance and board members to be more technology-savvy, so must technologists and infrastructure teams become more compliance-, legal- and regulatory-savvy.
Firms’ technologists and infrastructure specialists and firms’ ISVs and other vendors should all know how important this will be for them and their clients. No one should rely on what someone else tells them is or is not abusive or manipulative because if a regulator comes knocking at the door, he will expect everybody involved in the trading system to have applied their own understanding of the rules and used their initiative to do their jobs with monitoring for and prevention of abuse and manipulation at the forefront of their minds.
Training for all and all for training! Also, please consider responding to ESMA’s discussion paper – it’s important that technologists’ voices are heard.