Trade Regulations

JPMS Fined $800,000 for Failure to Supervise and Pre-Trade Controls

A Case for At-Trade Risk Management

JPM accepted a fine for $800,000 because they “failed to establish, document, and maintain a system of risk management controls and supervisory procedures, including written supervisory procedures and an adequate system of follow-up and review, reasonably designed to manage the financial, regulatory, and other risks of its market access business.”[i]

The regulatory fine points out a number of problems. These include:

  • Inadequate pre-trade controls.
  • Complex order routing through multiple trading systems
  • Ability for the traders to override pre-trade risk controls through the use of “Soft-blocks” instead of hard controls
  • Pre-trade controls that were set to benefit the trader and not to protect the firm or the markets.
  • Pre-trade controls that were “generally set too-high to be effective.”[ii]
  • Order message controls “employed soft-block alerts for order or message activity, rather than any hard-blocks, that could be overridden, and the levels set for the alerts were too high to identify potentially unintended messaging activity.”[iii]

Edge Financial Technologies has recognized the pattern of issues related to this fine. We have seen it multiple times. Consider the following:

Traders:

  • Want speedy execution to avoid market slippage.
  • Want multiple trading systems (backup, additional functionality, algos, etc.)
  • Have market experience that must operate in real time
  • Produce the revenue that drives the firm

Risk & Compliance:

  • Are a cost center
  • Review activity after the fact and have the luxury of hindsight
  • Are required to have oversight

IT & ISVs

  • Take direction primarily from the profit centers

When the developers who are putting in the pre-trade risk systems gather requirements they are often encouraged, to “meet the minimum” risk requirements and compliance because execution slippage is expensive. Over time all trading systems change. The changes may be settings, or may be new features, or additional functionality. Regardless of the change, pressure on the “minimum” requirements builds and sooner or later a fault appears.

Our belief is that this is what occurred at JPMS. We doubt anyone initially designed the order routing technology to have these faults. The pressure of new integrations, parameter changes, new markets all build to introduce a fault line in the order processing systems.

A systematic risk management program should address the pressures on the system by implementing a new level of oversight using At-Trade risk management technology

What is At-Trade Risk Management?

At-Trade risk management oversees the trading activity in near real time across all exchanges, accounts, traders, and technology with the capability to alert and take manual or automated action that is appropriate to the situation.

The action should be appropriate and not increase the risk to the trading accounts or the trading firm.

 

At-Trade became possible when software vendors, like Trading Technologies[iv], CQG[v], and others began introducing streaming drop copies of all order transactions along with application programming interfaces to interact with account and trader pre-trade setups. The CME[vi] and ICE[vii] have provided streaming drop copies and exchange level pre-trade controls. Other exchanges are following their lead.

The Benefits of At-Trade Risk Management

The implementation of a documented system with appropriate processes of At-Trade Risk Management proves that there are valid supervisory procedures.

 

While changes to the order processing systems occur, there will be a secondary system that will not be affected by the pressures associated with change. No matter how many changes occur, the order traffic remains. The drop copies of all traffic still flow into the At-Trade Risk Management System.

 

Escalating actions can be setup to allow a system of alerts, warnings, and actions that appropriately deal with order flow and messaging issues.

Learn more about the Edge Financial Technologies At-Trade Risk Management solutions at

www.KillSwitchPlus.com

 

 

 

 

Citations & Links

[i] BATS BZX EXCHANGE, INC. Letter of Acceptance, Waiver and Consent No. 20120348296-04 Re. J.P. Morgan Securities LLC Respondant http://cdn.batstrading.com/resources/regulation/disciplinary/2012/BEST-EDGX-20120348296-05-AWC.pdf
[ii] ditto
[iii] ditto

[iv] https://www.tradingtechnologies.com/platforms/fix/

[v] http://partners.cqg.com/api-resources

[vi] https://www.cmegroup.com/confluence/display/EPICSANDBOX/Drop+Copy+4.0 and https://www.cmegroup.com/confluence/plugins/servlet/mobile?contentId=78447186#content/view/78446746

[vii] https://www.theice.com/technology/isv

 

Edge Financial Technologies

The Algorithm Behind Algorithmic Trading: Why It Makes Sense

The Algorithm Behind Algorithmic Trading: Why It Makes Sense

excerpt from The Market Mogel July 6, 2017

Man vs. Machine

The most prominent development facilitating the change in behaviour is derived from powerful computing, high connectivity speeds and real-time intraday information. The following ingredients gave rise to high-frequency trading.

Its dominance is being manifested by increasing presence in a variety of asset-classes. As a result, a new competitor has entered the gladiator spectacle; the machine.

Due to the short time horizon of investment decision making in HFT, day traders are more likely to experience a change in the competitive landscape. Reacting to certain news or price movements is unlikely to yield trading profits as before. Algorithms react faster, by entering and unwinding positions in milliseconds.

Consequently, such rapid executions of buy/sell orders are likely to distort price signals, making it difficult to enter a particular trade by hand. A primary example of this is the recent flash crash, causing unjustified price swings.

Temporary or not, flash crashes like the one that took place in August 2015 shake the confidence of individual investors who rely on the public markets to dictate the fundamental value of a company.”

Ted Kaufman

Read the full article on The Market Mogel

Edge Financial Technologies

RenTech is pushing back on CFTC

Renaissance Technologies, the $65 billion hedge fund, is pushing back against federal regulators’ interest in highly-technical trading software out of concern that their source code wouldn’t be secure in the government’s hands, The Post has learned.

The Commodity Futures Trading Commission is interested in digging into the software at so-called “quant” funds, which use highly-secretive algorithms to execute trades.

See the full article on NY-Post

Japan FSA Rules and Regulations

Japan Tightens Regulations on High Frequency Trading

Japan’s FSA (Financial Services Agency) is looking to implement tighter regulations on Japan HFT (High Frequency Trading) 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.