The latest edition of Market Watch published by the Financial Conduct Authority (FCA) focuses on some of the most common failures of firms’ trade surveillance strategies. It also details the findings from the regulators’ recent peer review of firms’ testing of front-running surveillance models.
Regulator highlights common trade surveillance failures
The Market Abuse Regulation (UK MAR) clearly outlines how firms must identify and report instances of potential market abuse. A firm must have effective arrangements, systems and procedures in place to detect and report suspicious activity. These should be appropriate and proportionate to the scale, size and nature of their business activities.
With many firms using third-party systems to achieve regulatory compliance, the regulations also provide detailed information on the steps that firms need to take to govern, implement, test, review and rectify issues with the functioning of these systems.
Market Watch 79 explains that in recent years, the FCA has regularly seen examples of trade surveillance systems that are not functioning as intended and, in some cases, have resulted in non-compliant processes that the firm is not even aware of. While the specific nature of these technological issues will vary from firm to firm, the regulator has summarised some of the most common faults based on their investigation of firms’ trade surveillance operations:
- A section of a firm’s activity, such as a segment of business sent to a particular exchange, might not be monitored for market abuse in any way.
- An alert scenario that has been configured incorrectly within a system could be generating alerts, but not for all instances of market abuse resulting in a firm only having a partially effective monitoring solution in place.
- An alert scenario for a specific type of market abuse hasn’t been set up or tested correctly, resulting in a complete lack of alert generation and significant gaps in a firm’s trade surveillance.
The FCA also highlights the wide range of timescales taken by firms to take remediatory action in the event of process or system flaws being identified.
“Sometimes, firms identify and remediate these issues in a few weeks, or less. On other occasions, the discovery takes several months. In some extreme cases, we have seen firms unaware of faults for two years or more”.
Real-life examples of system failures
Firm A - A failure to identify insider dealing
Firm A was active across a range of asset classes, including cash equities. They implemented a new third-party automated surveillance system that was designed to identify any potentially suspicious trading, by monitoring:
- significant price moves
- the release of news
However, Firm A did not undertake the required testing as part of the system implementation which resulted in the news feed not being activated. Without this functionality in place, no insider dealing alerts were generated for over three years before the failure was identified.
In fact, Firm A was only made aware of the operational issue when they were contacted by the FCA in relation to some potentially suspicious trading where it had not submitted a suspicious transaction and order report (STOR).
How eflow would have avoided this
Every eflow client benefits from a thorough onboarding process, supported by a dedicated project team. As part of this initiation, before going live, the system undergoes meticulous testing by both eflow specialists and your team within a User Acceptance Testing (UAT) environment. This is followed by a five-day auto-testing period, during which the system operates independently to confirm functionality and identify any issues without external intervention. Upon successful completion of these tests, the system is seamlessly transitioned into live operations.
Firm B - Design faults within an ‘in-house’ trade surveillance system
Firm B designed and implemented their own in-house surveillance model to identify potential insider dealing in corporate bonds, covering trading by clients and its own traders.
As part of the alert logic within their system, news did not need to be released for an alert to trigger as this would be considered during an alert review. Instead, it required a price movement at or above a defined threshold (X%) within a defined period after a trade to trigger an alert.
A mistake made during the system coding meant that for an alert to trigger, the firm had to trade in the instrument on the day that the price moved. This requirement meant that the monitoring of liquid, frequently traded instruments was largely unimpeded. However, the alert would not trigger for less liquid instruments which increased the risk of insider trading going undetected.
As the system was generating alerts with an expected frequency and quality, the fault went undetected for several years. This led the firm to mistakenly believe that the model was working as intended and only discovered otherwise when it received a front office escalation.
How eflow would have avoided this
The pros and cons of a third-party trade surveillance system versus an in-house build have been debated for some time. However, the resources and expertise required to engineer, test and constantly enhance complex technology of this type is significant. eflow’s specialist team of engineers constantly refine our products to ensure that they meet the regulatory and operational requirements of global regulators.
One critical advantage of eflow is our meticulous attention to detailed functionality, for each of our tests. Uniquely, eflow considers additional contextual information, such as market conditions. An example specific to this case would be to allow for the adjustment of look-back periods based on an instrument’s liquidity. This specific capability is just one among many customisable features we provide to meet our clients’ diverse needs.
Firm C - Incorrect system configuration
Firm C offered clients direct market access (DMA) to certain trading venues, with some clients directly connecting to one of these venues (sponsored DMA – or SDMA), rather than connecting through Firm C. This was captured using a trading private order feed (POF) for inclusion in the firm’s surveillance.
As part of the implementation of the firm’s third-party automated surveillance system, it believed that all POF trade and order data would be sent daily for ingestion and processing. However, this was not the case and resulted in its POF trading activity going unmonitored for cases of market abuse for several years.
The firm’s non-POF trades and orders were subject to surveillance and were generating the associated alerts. As a result, this gave the firm false comfort that all relevant data was being ingested into the system as anticipated.
The FCA has seen similar issues relating to POF, SDMA, and broader data ingestion gaps repeated at other firms as well.
How eflow would have avoided this
Once live, eflow provides the capability for autonomous ad-hoc reconciliation, enabling firms to verify historic data and ensure accuracy in the data generated. It’s essential for firms to have a third-party surveillance system like eflow that offers straightforward ad-hoc reconciliation of historical data. This functionality is crucial for ensuring that the correct data is consistently monitored and for identifying any discrepancies that may have occurred during the testing process.
eflow will of course proactively ensure that clients are notified if any data expected during the scoping process is not received. However, for added peace of mind, our clients also have the ability to independently verify data reception themselves, providing an extra layer of assurance and control.
If your firm is looking to implement a trade surveillance solution capable of monitoring for front-running and other forms of market abuse, book a consultation with eflow today.
