MiFID II Algo Controls - Citihub Consulting · MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update 5 Financial institutions have long lived under

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


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


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.


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.


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.


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.


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).


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.


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.


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.


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


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


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

Documents

MiFID II Algo Controls - Citihub Consulting · MiFID II Algo Controls: Regulatory Drivers for Systems Integrity | February 2016 Update 5 Financial institutions have long lived under