Blog article
See all stories »

Japan Tightens Regulations on High Frequency Trading: 3 FINTECH Needs

Japan’s FSA (Financial Services Agency) is looking to implement tighter regulations on High Frequency Trading (HFT) as soon as 2018. Reuters states that “The growing presence of HFT on the Tokyo Stock Exchange (TSE) has raised concerns high-speed trading could destabilise markets and leave retail investors at a disadvantage.“*

This is an interesting point that we should all consider. Does it really destabilize the market? I haven’t yet seen a definitive presentation or report on this. I have seen reports that run away algos have destabilized the markets but not one on properly functioning HFT systems. It is my opinion that the HFT systems, especially those that are providing liquidity, are not destabilizing the efficient markets. But I too do not have a definitive study to show one way or another.

My big concern is those HFT systems that have “self-regulating” technology. By self-regulating technology I mean that the algo watches itself. It controls:

  • Who can trade and who cannot
  • All decisions to buy and sell
  • All order processing transactions
  • All risk management

This is a fundamental design problem that exists in many algorithmic systems. In the quest for speed and competitive low latency the software designers and algo programmers do not have any incentive to put in place truly effective safety guards. They program for speed, not safety of the market. The hope, or possibly design, is in the algo’s logic which is often written and tested by one person.

Years ago a manager once told me that the difference between a programmer and an analyst is that a programmer writes code and trusts it and the analyst has lost some of his or her trust in the written code. Algo programmers are sometimes optimists trusting in their own code. The hope in self-regulating algos may be misplaced.

At an auto race there are race cars have minimum safety features. They are interested in speed. However the race track has external safety features built in. These include:

  • Fencing and netting to protect the spectators,
  • Track repair crews who protect the drivers by providing a safe environment,
  • Pace Cars that regulate the speed, especially after a crash on the track

In the same way HFT systems need external controls. Here are the three levels of controls I believe to be best practice.

Three Levels of Safety Checks For Algo & HFT Systems

As an industry we need to have external safety features. At a minimum I would suggest that algo systems have three levels of safety checks:

Pre-Trade Checks

The pre-trade checks should be “in application” or “in algo” code that makes sure that order sizes are appropriate and reasonable. They should also check to make sure that the algo is not overstepping approved credit limits.

A good example of these pre-trade checks include the Guardian application implemented by Trading Technologies.

At-Trade Checks

At-Trade checks occur in the moments after the order (or related) transaction has been submitted. This should be external to the algo or trading system. By external I mean that they are implemented by a separate program running on a separate computer. And before you ask, yes I mean an entirely separate physical computer not a virtual machine running on the same hardware.

At-Trade checks should include:

  • Intraday Profit and Loss Limits
  • Order Speed Limit Checks (per second, per minute, per day)
  • Order rejection limits
  • Max intraday position limits (long, short, net)
  • Maximum number of open orders in the market

These checks should be implemented in a way that would alarm, and if necessary stop or kill the algo.

A good example of an at-trade risk system is KillSwitchPlus or the newer generation RiskResponder being deployed by Edge Financial Technologies.

Post Trade Risk

Post Trade Risk is the last layer. This is typically the back office system or some other back office system that is checking for the overall position limits. These checks are looking at the position portfolio in its entirety.  Ideally this system should be more real time than the batch clearing system. Best examples of checks performed at this level include:

  • Firm-Wide risk analytics
  • Cross Product and Exchange Risk Analytics
  • Intraday SPAN margin calculations
  • Calculation and summary positions on “the greeks”
  • Intraday position analysis based on volatility and pricing scenarios
  • Hedging position analysis
  • Value at Risk analysis

A good example of a post trade risk system would include ProOpticus by Prime Analytics.

Action Steps

Each and every trading firm should take some action. Most have something that covers the pre-trade risk, otherwise they would be in violation of several regulations around the world. Many broker dealers have the post-trade systems. Yet many trading firms, especially the less well known trading firms, are lacking in post-trade systems. At-trade is the last. I see few firms that have implemented an effective at trade system. This is, in my opinion, the biggest functional gap in our trading industry.

 

 

Reuters: “Japan passes law to tighten regulations on high-frequency trading Fri May 19, 2017

 

12167

Comments: (1)

A Finextra member
A Finextra member 23 May, 2017, 14:08Be the first to give this comment the thumbs up 0 likes

Great point about the safety guards. Love the distinction between programmers and analysts.

Blog group founder

Member since

0

Location

0

More from member

This post is from a series of posts in the group:

Fintech

Fintech discussions and conversations around the development of fintech.


See all

Now hiring