mifid ii algo controls - citihub consulting · mifid ii algo controls: regulatory drivers for...
TRANSCRIPT
Integrity.Excellence.Results.
MiFID II Algo ControlsRegulatory Drivers for Systems Integrity
February 2016 Update
www.citihub.com
Contents
3 Executive Summary4 Highlights5 Introduction6 Summary of MiFID II Requirements Relating to Algo Controls • Scope of Article 17 • The ‘Proportionality Principle’8 Summa8 Summary of MiFID II Regulatory Technical Standards Relating to Algo Controls • Governance • Testing • Annual Self-Assessment • Kill Functionality • Market Abuse Surveillance • Business Continuity • Pre- and Post-Trade Risk Controls • Real- Time Monitoring • Security14 Conclusion15 Contact Us
Disclaimer: Citihub Consulting does not warrant that the information in this whitepaper is either complete or that it should be relied on, in
part or in whole, to ensure regulatory compliance or to protect the integrity of business systems.
10
Executive Summary
Financial institutions of all kinds (sell-side, buy-side and
market infrastructure operators) are facing stricter rules on
how they manage their technology. From the United States to
Australia, regulations across the globe are becoming ever
more prescriptive in mandating technology best practices.
Financial institutions are facing stricter rules on how they
manage their technology. The common theme is that
regulators are looking to set minimum standards and reduce
risks related to technology operations.
Some, like the Monetary Authority of Singapore’s (MAS)
Technology Risk Management (TRM) notice, have set a strict
bar when it comes to the availability of critical systems—
specifying no more than four hours of unscheduled downtime
in any 12-month period. Others, like the US Regulation Systems Compliance and Integrity (Reg SCI) and the
European Markets Infrastructure Regulation (EMIR) have
specified Recovery Time Objectives (RTOs) of two hours,
requiring firms in scope to have swift and effective incident
and problem management processes in place.
Although every jurisdiction varies in its approach, the common
theme is that regulators are looking to set minimum standards
to reduce risk in trading technology operations and prevent
the possibility of disorderly markets. For the purpose of this
research, Citihub has chosen to focus on Article 17 of the
revised Markets in Financial Instruments Directive (MiFID II).
This is set to impact trading and investment firms operating in
EuEurope by January 2018, a one year delay from the original
date of January 2017.
Although Article 17 is entitled ‘Algorithmic Trading,’ it has
implications that are far broader, given that much of its
requirements relate to what the European Securities Market
Authority (ESMA) has defined as ‘trading systems.’ This paper
focuses on requirements relating to the governance, testing,
on-going review, monitoring and surveillance, pre-trade and
post-trade risk management, as well as the security of those
trading systems.
Addressing these regulatory obligations will no doubt be
burdensome for many participants. However, the end result
should be to improve the quality of systems architecture and
IT governance for financial institutions.
The end result should be to improve the quality of
systems architecture and levels of IT governance for
financial institutions.
Citihub recommends that firms start by carrying out a
thorough and detailed evaluation of their front office trading
systems, and the underlying infrastructure supporting those
systems in order to understand any gaps in capabilities or
controls that need to be filled before MiFID II comes into effect
at the beginning of 2018.
Given that trading technology evolves in response to new
business requirements and technological innovation, it will
also be vital that firms establish strong governance and
process controls to ensure continued compliance with
Regulatory Technical Standards 6 (RTS 6), which is entitled
“Regulation on the regulatory technical standards specifying
the organisational requirements of investment firms engaged
in algorithmic trading, providing direct access and actings as
general clearing members.” RTS 6 details how MiFID II algo
controls are to be implemented.
MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update
3
MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update
Highlights
ESMA submitted its final draft technical standards for MiFID II to the European Commission on the 28th of September, 2015. The Commission normally has three months to ratify the standards, with the European Parliament and Council also offered an objection period. As the proposed delay to 2018 has shown, normality has been flexing for MiFID II.
However, for algo controls the current proposals should carry through. These proposals suggest that:
• The scope of MiFID II Article 17 is broad. Although the article is titled ‘algorithmic trading,’ it sets out minimum standards for a range of IT systems, processes, governance and controls.
• Compliance with some requirements will be based on a ‘proportionality principle,’ which means firms will need to assess the ‘nature, scale and complexity’ of their business and IT operations.
•• In compiling that assessment, firms ought to evaluate all of the systems and controls underpinning their various trading operations in order to identify potential IT risks and capability gaps.
• Being able to monitor real-time flowso on a cross-asset, cross-market basis is likely to prove extremely challenging for firms that maintain complex, heterogeneous trading architectures.
•• Requirements around kill functionality may also be challenging, given the complexity of identifying all orders belonging to each algorithm, trader, trading desk or client.
• Pre-trade risk engines will need to be carefully architected given that checks will need to be done quickly and effectively, with appropriate BC and DR plans in place.
•• Once firms have met regulatory obligations outlined in Article 17, they will need to continue carrying out annual reviews of their trading systems architecture, governance and controls to ensure that they can identify and remediate risks.
4
Introduction
MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update
5
Financial institutions have long lived under the supervision of both national and
supranational regulatory bodies. Yet the past few years have seen the intensity of
that supervision increase. In view of the political impetus (following the financial
crisis) to impose tighter risk management practices, and further fueled by some
high profile IT failures, regulators have been recognising the growing importance of
technology in supporting financial markets. Moreover, they have shifted their
stance from entrusting firms to self-regulate their IT operations via internal audit
functions to taking a much more active and prescriptive approach, identifying
applications that are critical to the functioning of financial services and setting
minimum standards for how those applications should be managed.
As part of that trend, firms are being asked to carry out ongoing reviews of the
systems, processes, governance and controls underpinning their trading
operations. Those reviews vary significantly in scope. For example, the SEC’s
Regulation Systems Compliance and Integrity (Reg SCI) applies to SCI entities
(exchanges, alternative trading systems, clearing service providers and plan
processors). In contrast, ESMA proposes, as part of MiFID II, that all trading firms,
including buy-side users of direct access trading services, carry out yearly reviews
of their trading systems.
For the purpose of this whitepaper, Citihub has chosen to focus specifically on
Article 17 of MiFID II, which is contained in the directive’s Level 1 Text. This text
sets out the legislative framework for controls that investment firms will need to
place on their algo trading operations. Its corresponding technical standards are
contained in RTS 6, which is in final draft form. Once RTS 6 has been ratified by
the European Commission, Parliament and Council; Member States and their
national competent authorities (such as the Financial Conduct Authority in the UK)
will have until the middle of 2016 to transpose those provisions into local
legislation. From that point, firms in scope of the regulation will only have another
six months to ensure compliance.
Although there is still potential for final changes to RTS 6, we do not expect any
significant alterations, given that much of the draft technical standards map to the
corresponding Level 1 text. This paper summarizes some of the key requirements
contained in Article 17 (along with RTS 6), explains the implications of those
requirements, and outlines challenges that firms may face in complying. As
some aspects of compliance can require significant planning efforts, we would
recommend firms do not leave remediation efforts until the last minute, particularly
given the criticality of systems in scope.
Summary of MiFID II RequirementsRelating to Algo ControlsArticle 17, paragraph 1 of the MiFID II Level I text states that:
“An investment firm that engages in algorithmic trading shall
have in place effective systems and risk controls suitable to
the business it operates to ensure that its trading systems are
resilient and have sufficient capacity, are subject to
appropriate trading thresholds and limits and prevent the
sending of erroneous orders or the systems otherwise
functioning in a way that may create or contribute to a
disorderly market. Such a firm shall also have in place effective
systems and risk controls to ensure the trading systems
cannot be used for any purpose that is contrary to (the Market
Abuse Regulation of 2014) or to the rules of a trading venue to
which it is connected. The investment firm shall have in place
effective business continuity arrangements to deal with any
failure of its trading systems and shall ensure its systems are
fully tested and properly monitored to ensure that they meet
the requirements laid down in this paragraph.”
Although this paragraph is just over 150 words in length, it has
significant implications for both sell-side and buy-side trading
firms operating in Europe.
Scope of Article 17
Article 17 is entitled ‘Algorithmic Trading’ but its scope
extends further than one might expect. In fact, most of its
requirements relate to what the regulator refers to more
broadly as ‘trading systems.’ Because there are separate sets
of requirements for investment firms and market operators, it
is important to note that for the purpose of this research we
are focusing on implications for investment firms. From that
perspective, ESMA clarifies its definition of trading systems as
the “hardware, software and associated communication lines
which investment firms use to perform their trading activities,”
including “any type of execution systems or order
management systems operated by… investment firms.”
Not only do MiFID II algo control provisions extend to a broad
range of systems and markets, they also apply across a full
range of market participants. That means even hedge funds
can be in scope. However, it is also important to note that the
requirements are also subject to what ESMA defines as the
‘proportionality principle.’
Citihub Viewpoint:
Most modern trading systems contain some basic forms of algorithmic processing. Relatively simple algorithmic
techniques like smart order routing are prevalent across all asset classes. In its December 2014 technical advice
to the Commission, ESMA clarified that algorithms only seeking to decide on the best venue for execution -
classed as ‘Automated Order Routing’ - should not fall within the scope of the regulation. However, if other
parameters are taken into account then the trading system will be in scope. That means even fairly rudimentary
algorithmic order types that control the timing of execution or other trigger-contingent factors (such as trailing
stops and icebergs) fall in scope. More recently, ESMA also clarified that pure investment decision algorithms that
“generate orders… to be executed by non-automated means and with human intervention” do not fall within
scope of algo testing obligations.
MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update
6
proportionality principle makes intuitive sense (subjecting
riskier activities to stricter controls), it may also be prone to
subjective interpretation (or potentially misinterpretation).
ESMA has therefore laid out a number of attributes that it
suggests investment firms consider in determining the nature,
scale and complexity of their business.
For the nature of the business, these factors include the firm’s
role/s in the market (e.g. market making, agency and/ or prop
flows), levels of automation and types of strategies deployed
(along with the latency sensitivity of those strategies), types of
instruments traded (and their regulatory status) and the type of
venues they are traded on (lit, dark, OTC), connectivity
solutions to those venues or provided to clients (eg. DMA,
DEA, Sponsored Access), whether algorithms and trading
systems are proprietary or vendor-provided, the firm’s
ownership structure and maturity, along with the structure of
audit, risk and compliance functions.
For the scale of the business, firms are recommended to factor
in both business metrics—such as the value of intraday and
overnight positions, annual earnings and profits, number of
trading desks, traders, locations, markets traded, clearing
memberships, and clients—as well as a range of technical
factors. Those include the typical messaging traffic generated
(orders, cancels and amends), number of algo’s running in
parallel, number of co-location or proximity hosting sites and
the throughput of network connectivity deployed.
Finally, ESMA recommends evaluating complexity based on
a number of predominantly technical factors, including the
complexity of algorithms’ code bases, data inputs and
interdependencies, along with the diversity of trading systems,
physical infrastructure, connectivity, technology and clearing
solutions, speed of change, and level of outsourcing
employed.
The ‘Proportionality Principle’
The ‘proportionality principle’ suggests investment firms will
be able to assess the nature, scale and complexity of their
business, and decide to what extent they need to comply with
certain requirements based on that assessment. Although the Citihub Viewpoint:
Not every firm will have accurate records of
the information ESMA sees as relevant to
defining the ‘nature, scale and complexity’
of a given business. Firms should therefore
invest time and effort up front in accurately
documenting their trading systems, the
underlying infrastructure supporting those
systems and interdependencies between business flows, application processes
and/or infrastructure components. That
means being able to trace flows through
relevant application processes and the
infrastructure underpinning those
applications. Going forward, having the
right processes in place to ensure technical
architectures remain well-documented and
well-managed will also be crucial for
managing ongoing IT risks.
MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update
7
Governance (Organisational Requirements)
The algo control provisions in MiFID II recognise that people
(skills) and processes are both critical in controlling IT-related
risks. From a governance perspective, RTS 6 notes that firms
need to have “clear lines of accountability,” which means
development, deployment and code changes will require sign
off through a chain of command. Equally, firms must ensure
strict segregation of duties between trading and risk control/
compliance functions so that “unauthorised trading activity
cannot be concealed.”
From a process perspective, RTS 6 also specifies that firms
have “effective procedures and processes for the
communication of information within the investment firm” so
that “relevant issues can be escalated and instructions can be
implemented in an efficient and timely manner.”
Firms must also ensure their compliance officers have a
“general understanding” of the way trading algorithms and
systems operate, and be in “continuous contact with persons
with detailed technical knowledge” of those systems.
Furthermore, the compliance function must “at all times” have
access to kill switch functionality (see page 10 for more info)
or “direct contact with the persons who have access to it,
and… those who are responsible for each trading system and
algorithm.” Although a firm can outsource its compliance
function to external consultants, it must make sure those consultants are granted adequate access to its operations,
maintain data privacy and can be audited by both internal and
external auditors.
With regards to staffing, RTS 6 required that firms maintain
enough employees with the relevant skills and knowledge, not
only to support, monitor and test its trading systems and
algorithms, but also the trading strategies that the firm
employs and its legal and compliance obligations. More
specifically, compliance staff also need the necessary skills to
challenge trading staff when automated alerts are triggered by
activities that suggest disorderly trading or market abuse may
have occurred.
Citihub Viewpoint:
Maintaining adequately skilled and trained staff should be a routine part of any trading operation. However, the
challenge lies in ensuring the right processes are in place to bridge: i) business knowledge required to assess
trading strategies; ii) technical knowledge required to support, monitor and test trading systems and algorithms;
and iii) compliance knowledge required to assess a firm’s regulatory obligations. Should those communications
falter, the risk is that automated alerts are either missed, allowing rogue algorithms to continue trading, or acted
upon without proper validation, resulting in legitimate trading strategies being curtailed unnecessarily.
MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update
8
Testing
ESMA has simplified testing requirements in its final draft
regulatory technical standards relative to previous iterations.
RTS 6 breaks out testing processes into the following
categories:
General Methodology, Article 5: Firms must have clear development and testing methodologies to govern design and performance of systems, algorithms and strategies. These methodologies also need to cover division of responsibilities, allocation of resources, escalation procedures, along with recordkeeping and approval (senior management should designate a “responsible party” to sign off on “initial deployment” and “substantial updates”). The end goal should
be to ensure algorithms, systems and strategies: a) behave as
expected; b) are operated in a way that complies with
regulatory obligations; c) conform with venue rules and d) do
not contribute to disorderly trading and work effectively in
stressed market conditions. ESMA also notes methodologies
should be tailored to relevant trading venues, and any
substantial changes to the venue’s systems should trigger
further testing by the investment firm. Finally, firms should
keep records of material changes, including the nature of the
change, when it was made, who made it and who approved it.
ConformanceConformance Testing, Article 6: ESMA specifies separate conditions under which firms need to carry out conformance
tests with trading venues and direct market access providers.
when: i) members access the venue, or ii) connect via
sponsored access for the first time, iii) there is a material
change in the venue’s systems, or iv) before deploying new, or
material changes to existing algorithms, systems or
strategies. Conformance tests with DMA providers need to
take place when: i) accessing a venue via that DMA provider
for the first time, ii) when there is a material change in the
provider’s DMA functionality, or iii) before deploying a new, or
making a material change to an existing algorithm, system or
strategy. Two key goals of these tests are to ensure: i)
algorithms interact as expected with venues’ matching
logic and ii) can adequately process data from venues.
Test Environments, Article 7: Testing and production environments should be segregated, without necessarily
requiring duplicative systems and infrastructure, which could
have proved too expensive. Furthermore, firms can use their
own test environments, or those from trading venues, DEA
providers or vendors for purposes other than conformance
testing.
Controlled Deployment, Article 8: ESMA proposes restrictions to ensure new algorithms or code bases are
introduced cautiously into the market. That means firms will
need to impose initial limits on the number of financial
instruments traded, the price, value and number of orders,
along with the strategy positions and number of markets to
which orders are routed.
Citihub Viewpoint:
ESMA’s initial proposals regarding testing obligations could have caused some complications, particularly with
regards to testing for ‘disorderly conditions’, which would have been dependent on venues having appropriate
test facilities in place. The final draft also seems to have acknowledged market feedback regarding the physical
separation of test and production environments, which could have been an undue cost. In their current iteration, we would view most of the testing requirements to represent sound IT operating best practices that are well established across the industry. However, a couple of aspects that may still prove troublesome are the requirement to go through conformance tests prior to any material changes to an algorithm, trading system or strategy and the need for controlled roll-out, which may prove difficult in light of other requirements, such as market making obligations.
MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update
9
Annual Self-Assessment and Systems Validation
ESMAESMA proposes that firms bake in ongoing reviews of their
trading systems and algorithms into their business as usual
operations. These reviews should also cover firms’
governance, accountability and sign-off frameworks, business
continuity arrangements and overall compliance with algo
control obligations set out in Article 17 of the Level 1 text. As
Stress Testing, Article 10: Once a new strategy has been introduced, ESMA recommends that firms continue stress-
testing their systems, procedures and controls - at least
annually - to ensure they can withstand extraordinary market
pressures, including peak messaging (at least twice the
peak level processed over previous six months) and trading
volumes (at least twice the highest volume traded over
previous six months).
Management of material changes, Article 11: Finally, ESMA has specified requirements governing change management,
including that firms maintain review and sign-off procedures
that are appropriate to the nature of the change and establish
procedures for communicating new systems changes and
functionality. As specified in the general methodology
requirements, firms will also need to keep records of changes,
when they were made, who made them and who approved
them.
part of the review process, the risk management control
function within each firm will be responsible for creating a
validation report, the findings of which should be
communicated to compliance officers, audited by a
firm’sinternal audit team and approved by its senior
management. Ultimately, the purpose of the reviews should
be to identify and remedy deficiencies or potential risk factors.
Citihub Viewpoint:
Having the right blend of business,
technical and compliance knowledge to
accurately carry out annual reviews and
identify risk factors will not be easy. In
particular, given the cutting edge nature of
some algorithmic trading technologies, risk
management personnel and internal
auditors may struggle to accurately assess
risk factors.
Kill Functionality
Some of the most challenging technical requirements within
MiFID II’s algo control requirements fall under the title of
‘Means to Ensure Resilience’. Article 12 of the final draft RTS
66 relates to ‘kill functionality’ - essentially a firm’s ability to
cancel outstanding orders for a particular algorithm, trader,
trading desk or, where applicable, client. Equally, as an
emergency measure, firms should also be able to cancel all of
their outstanding orders at all trading venues that they are
connected to.
Citihub Viewpoint:
ESMA’s kill functionality requirements may
seem simple in theory, but in practice they
may prove very challenging. Part of the
problem is simply identifying all orders
attributed to each algorithm, trader, trading
desk or client, particularly for clients that
trade across multiple asset classes.
Navigating each venue’s rules and
protocols for order cancelation is another
challenge, in particular when it comes to the last ditch emergency feature of
cancelling all orders at all venues, given
that each venue may differ in its approach
(for example, some may support cancel on
disconnect, others may have functionality
to cancel all resting orders, while others
may require specific cancellation messages
for each order).
MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update
10
Prevention and Identification of Market Abuse
The market abuse monitoring requirements laid out by RTS 6
are fairly detailed and even specify the use of automated
surveillance systems capable of “generating alerts and reports
and, where appropriate, employing visualisation tools.” Those
surveillance systems should be able to monitor all of a firm’s
trading activities (across asset classes) and be adaptable to
changing circumstances (such as new regulatory obligations,
or alert parameters defined by changing market conditions or
strategies). Surveillance systems also ought to be reviewed at
least annually to make sure they are properly calibrated and
minimise the incidence of false positive and false negative
alerts. Systems must also have access to sufficiently granular
order and transaction data to replay and analyse market
events on an ex-post basis. Staff responsible for this
surveillance function will need to report any suspicious activity
to the firm’s compliance function to take appropriate action,
which may include reporting the behaviour to the trading
venue or filing a suspicious transaction report. Finally, firms
will need to ensure that their trade data is accurate by
reconciling their own internal records with those of trading
venues, brokers, clearing members, CCPs, data providers or
other relevant business partners as appropriate.
Citihub Viewpoint:
The evolution of algorithmic and high
frequency trading practices over the years
has driven a corresponding evolution in
surveillance systems, with many firms
employing complex event processing
engines to identify and alert on suspicious
activity that requires further investigation.
Even so, being able to properly calibrate
systems and replay market events with
correct time sequencing can be a technical
challenge given the variety of systems
employed by many firms.
Business Continuity Arrangements
RTS 6 specifies a range of business continuity arrangements
that firms should have in place with respect to their algorithmic
trading systems. Those arrangements should cover
governance; scenario planning to deal with unavailability of
systems, staff, work space, external suppliers, critical data or
documents; procedures for relocating to a back-up site; staff
training on individuals’ roles in such a scenario; arrangements
bespoke for each venue; usage policies regarding kill
functionality; arrangements for shutting down trading systems
or algorithms; and alternative arrangements for managing
outstanding orders. Furthermore, firms will need to ensure
they can enact their business continuity arrangements without
contributing to disorderly trading conditions, and will need to
review those arrangements annually and carry out any
remediation identified as necessary by the review.
Citihub Viewpoint:
Business continuity planning is a business
as usual function for IT operations. Even so,
it is not always done well. Making sure that
firms have adequate plans in place to deal
not only with internal system outages, but
also their external suppliers, will be a key
challenge.
MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update
11
Pre-Trade and Post-Trade Controls
Pre-trade risk controls are typically in place to prevent overly
risky or erroneous orders from reaching the market. Article 15
of RTS 6 specifies that those controls should include:
Price collars to block or cancel orders outside set
price parameters (determined by each financial
instrument and on an order-by-order basis)
Maximum order values to prevent uncommonly large
orders being entered
Maximum order volumes for the same goal
MessageMessage limits to stop excess throughput of
order, cancel and amend messages
1.
2.
3.
4.
In addition, firms need to have automated execution stops in
place to prevent strategies from generating repeated
executions, requiring strategies to be re-enabled manually.
The technical standards also specify that all orders sent
should immediately be factored into pre-trade risk limits, and
that firms need to enforce limits that are appropriately
calibrated based on a number of risk factors. Facilities
should be in place to block orders from traders who are not authorised to trade a particular instrument. Equally, firms
should be able to monitor and curtail overall risk exposures to
individual clients, financial instruments, traders, trading desks
or the overall exposure incurred by the investment firm as a
whole. Finally, firms should have procedures in place to
manually authorise trades that would otherwise have been
blocked by its pre-trade risk controls, although those manual
over-rides can only be granted on a temporary and
exceptional basis, and with the full knowledge of risk staff.
From a post-trade controls perspective, ESMA specifies that
firms need to continuously assess market and credit risk
exposures and be able to shut down relevant algorithms when
certain risk thresholds or controls are breached. This will
involve maintaining accurate transatction logs, involving the
reconciliation of internal records with external service
providers, including trading venues, brokers, DEA providers,
clearing members or CCPs, data providers or other business
partners. Where those service providers provide real-time
records, that reconciliation process should also be in
real-time. Specifically for derivatives trading, firms will also
need to control maximum long, short and overall strategy
positions and trading limits.
Citihub Viewpoint:
PPre-trade risk checks are already prevalent in the market today. However, once those checks become a
mandated regulatory requirement, firms will need to carefully consider the architecture of their pre-trade risk
engines. Trading systems and their components can often be fragmented, both from a physical and logical
perspective, so simply understanding flows and dependencies between different systems components can be a
challenge. The last thing a firm would want is for an outage of its pre-trade risk process to trigger a broader
trading halt, so ensuring failover capabilities are well architected and regularly tested will also be crucial.
Furthermore, given that pre-trade risk checks will need to be carried out for all types of flow (including the most
latency sensitive strategies), being able to perform those checks in the fastest way possible will also be key. It is
not uncommon for firms to deploy hardware acceleration techniques (such as field programmable gate arrays) to
support the required checks. Latency considerations should also be factored into business continuity plans. For
example, failing over to a risk engine that is located in a different region could add a significant amount of latency
and be disruptive to the performance of certain strategies.
From a post-trade perspective, the requirement to reconcile data and calculate aggregate risk exposures in
real-time (where feasible) will also be a challenge that may, in some cases, require a review of current system
architectures and an evaluation of solutions that can bridge any capability gaps.
MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update
12
Real-Time Monitoring
RTS 6 includes requirements for firms to monitor all of the
orders being sent to trading venues in real-time in order to
detect signs of disorderly trading, not only within a specific
market or instrument, but also from a “cross-market, cross-
asset or cross-product” perspective. This function should be
undertaken both by the trader in charge of each algorithm and
an independent risk control function, which cannot be
“hierarchically dependent on the trader.” Those staff in charge
of monitoring should be able to respond to operational and
regulatory issues and take remedial action where necessary.
ESMA also specifies that firms should be armed with real-time
alerts (generated within five seconds of the relevant event) to
identify unusual trading activity, and have in place incident and
problem management processes to take corrective action if
necessary. Equally, firms should have processes in place to
ensure third parties - including regulators, trading venues, DEA providers, clearing members or CCPs - have access to
real-time monitoring staff, with properly tested emergency
communication channels in place that also cover
out-of-trading hours.
Citihub Viewpoint:
Being able to monitor aggregated order
flows in real-time within a single asset
class is not always easy, given that some
firms support a range of proprietary and
vendor-sourced trading systems and
messaging protocols for each asset class.
Being able to monitor flows across all asset
classes and trading systems, and drill down
to see orders relevant to each algorithm,
trader, desk or client, will therefore be a
significant challenge. Standardising
messaging protocols and maintaining
consistent reference data will certainly be
a starting point. However, for firms whose
trading architectures have evolved
organically, simply having those capabilities
in place is likely to pose a significant hurdle.
Security
To ensure trading systems are secure, ESMA has set some
high level requirements, specifying that firms should
implement an IT strategy in line with their business,
operational and risk strategy, and with defined objectives
commensurate with a reliable IT organisation (“including
service, production and deployment”) and effective IT security
management. Other, more specific requirements include the
need to carry out penetration tests and vulnerability scans at
least annually, as well as the need to minimise the number of
users with privileged access rights, and to monitor those
users’ access to systems at all times to ensure traceability.
From a procedural point of view, firms will also need to inform
competent authorities of any breaches in their physical or
electronic security, including a report detailing the nature of
the incident, measures adopted to deal with the incident and
avoid a recurrence.
Citihub Viewpoint:
Most of the provisions laid out by ESMA
from a security perspective are not overly
prescriptive and constitute sound
operating practices that should already be
in place. However, for firms that do not
already do so, being able to tightly manage
and monitor users with privileged access
rights may require new technical
capabilities.
MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update
13
Conclusion
With the final draft technical standards now submitted to the
European Commission, firms must start to plan towards
implementation of MiFID II from the beginning of 2017.
Although many of the algo control requirements laid out by
ESMA constitute standard IT architecture and governance
best practices, there will invariably be gaps in skills, processes
and tooling that firms will first need to identify, and then fill over
the course of the next 15 months. The fact that MiFID II’s algo
controls make no distinction between buy- and sell- side firms
also means a wide variety of firms will be in scope, many of
whom will not be used to complying with regulatory
requirements over how they manage their IT.
The algo control requirements specified by ESMA should
also be seen in a wider context across asset classes, and in
conjunction with other aspects of MiFID II that threaten to
bring about broader changes in market structure, operating
practices, as well as systems and controls. Although
regulation is typically seen as a burden to the business, IT
operations should hopefully recognise that MiFID II offers an
opportunity for real positive change at the enterprise level if
firms start working on it early and have enough time to plan for
strategic solutions, rather than tactical fixes.
Why Citihub Consulting?
Over the years, Citihub has been asked to evaluate
hundreds of mission critical front, middle and back
office applications to help our clients understand the
impacts of new business, technology and regulatory
requirements across the architectural landscape –
including business flows, applications and
infrastructure, as well as the processes, governance
and operating models used to support business
platforms.
About Citihub Consulting
CitihubCitihub Consulting is a global, independent IT
advisory firm with deep domain expertise across
every layer of the technology stack – from business
applications and data platforms down to core
infrastructure. From IT strategy, architecture and
solution development, through to cost optimisation,
risk assessment and implementation – our trusted
experts deliver the right results for your business.
For us consultancy is personal. We have a relentless
commitment to great execution, integrity and client
success. We aim to redefine perceptions of our
industry and our commitment to delivering the right
results for our clients has never changed, even as the
business has grown consistently over the last
decades.
2014/15 clients include 7 of the top 10 investment
banks and 2 of the top 5 hedge funds.
For moFor more information, please visit www.citihub.com
MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update
14
Contact Us
Author
EMEA
Ian O’[email protected]
1 Canada SquareLondon E14 5AB+44 207 536 5801
Bellerivestrasse 201Bellerivestrasse 2018008 Zurich
+41 44 562 7101
MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update
Bob Mudhar, Partner
ContributorsChris Winson, Partner
Dave Levy, Associate PartnerClaudio Moreno, Associate PartnerDr. Craig J. Parkin, Associate PartnerStuart English, Senior ConsultantStuart English, Senior Consultant
North America
Keith [email protected]
757 3rd Avenue, 20th FloorNew York NY 10017+1 212 878 8840
The Dineen BuildingThe Dineen Building140 Yonge Street, Suite 200Toronto, Ontario, M5C 1X6
+1 437 886 8390
Asia Pacific
Steve [email protected]
137 Market StreetLevel 5, Office 505Singapore 048943+65 3152 2777+65 3152 2777
20th Floor, 1 IFCHong Kong
+852 8108 2777
15