In the recent past, we have seen UBS Asia being penalised for HKD $4.5 million considering the failure to put effective internal risk checks. The same goes with Morgan Stanley which was also fined for HKD $2.4 million for internal control breach. Many other entities had to face regulatory heatwaves for failing to have robust internal trade checks which made the watch dogs constantly monitor Securities Trading Organization’s (STO) and broker’s pre-trade checks very closely. Prime outcomes from these frauds are mainly due to the banks’ lack of internal risk checks defining the compliance & risk management systems and absence of risk rules sync across trading desks geographies.
To protect from pre-trade risk breaches, STOs/brokers need to have a well-defined and well-guarded trade checks which will be the front-line defence system, guarding from trading disasters. Entities fumble in many ways while implementing the internal risk rule checks. Especially, large STOs/brokerage firms face issues related to on-boarding and integrating multiple risk systems, order flows, geographies and desks. From the technical front, prime challenges encountered aretrading desk(speed of execution),compliance desk(safety of orders meeting regulatory/internal compliance rules) and业务部门(cost of execution).
Analysis of the systems and filling the gaps
So, when we start thinking about the above mentioned points, concerns such as, “Do we have our internal risk rule system aligned with current regulatory factors and internal team’s demand of being speed/safety/smart/cost effective?” will arise. These inquisitives lead us to understand the current state of trade checking controls and the gaps that needs to be filled up. To start with, the architecture check should be looked at the existing system and also be analysed if the system or technology design is such that the order flows like Normal/Algo/HFT (High Frequency Trading) pass through internal risk checks engine or framework, before hitting exchange orATS(Alternative Trading System). The other important step is to assess if the health of internal risk system has the below mentioned prime features listed
- 在奥德监控能力r level from point of orders placed
- 在复杂的Algo / HFT的贸易流量上以纳米秒运行贸易检查的能力
- Ability to monitor risk positions in real time, at different levels from Level 1 to Level 4
- Ability to edit/create/delete rules at user level with minimal development required
- Ability to view audit history in order
The next step would be to assess the internal risk system - Does thesystem have the prime internal risk ruleschecks before routing orders to exchange (like价格\ size \ volumes \取消）? This is required as many banks fail to evaluate and end up sending stale orders to exchange.
这保护发送高名义价值奥德ers enter the exchange order book, causing market fluctuations. Internal rule check calculates the notional value at order level (Quantity*Price*FX rate), sets up configurable limits and checks notional limits in order. Another notional check limit is to check at continuous levels, i.e., at the gross level, like setting up gross notional check for security limits.
- Price Check
This rule protects from sending orders higher than pre-set price limits to exchange and is set to validate order by order. For example, few exchange set-up price limits for stock cannot exceed >5% of trading limit.
It protects from sending large size of volume orders to exchange, causing market fluctuations. STOs/Brokerages should have alerts set when internal traded volume of stock reaches the ADV (Average Daily Volume) limit. For example, STOs set limit on stock and the average internal traded volume on XYZ should never be >40% ADV. This will limit controls, mainly the HFT/Algo trading flows from sending high volume trades.
- Cancel Check
The rule protects from sending more number of cancelled trades than the number of traded trades. It is calculated by the number of cancellations divided by the number of trades. These limits are set in order to control cancel trades sent by HFT’s and Algo’s orders.
The rules discussed above primarily safeguard entities from sending orders which can largely influence market behaviours and exchanging unnecessary attractions and fines like UBS/HSBC faced recently.
Regulatory changes in pre-trade risk controls
Regulatory and exchange bodies worldwide have come up with many regulations around pre-trade controls like MIFID-II rules, Dodd-Franck Rules on pre-trade transparency and NASDAQ. These regulatory bodies are mainly worried about the HFT/Algo trading flows, their volumes hitting the market, and the number of orders executed vs. the orders cancelled, i.e., trade to cancel ratio. Overall, the regulators/exchanges want anyone having access to the market to have internal risk controls placed and guarded well from placing stale orders.
More awareness required amongst STOs/Brokers community
Few of the STOs/Brokers firms are responding and adapting changes to their risk framework, but, on the whole, the industry is still evolving around internal risk checks. They need to be more vigilant and quick to familiarise new regulatory restrictions around them and also utilize technology to respond with the same phase.
Clearly, STOs/Brokers/Clearing Firms hold a great responsibility to create a clean and healthy trading environment.
The number of trading firms are too many and it can be challenging for the regulators to independently enforce specific regulations, unless they have complete access to all trading firms. In such a scenario, we recommend that trading firms are required to demonstrate the existence of reasonable measures in their processes and systems before being approved to trade. We recommend considering the establishment of a standard process by which firms submit and maintain documentation of their implementations of the capabilities. The firms should have minimum risk controls on the following aspects, develop stringent processes to verify the same and prove to the regulator about the controls they have. These areas should include and not be limited to the pre-trade quantity limits on individual orders, pre-trade price collars execution and message throttles.