If you missed the first part of this article, then first head to read “Did Your FX algorithms Learn the Lessons from the CHF Storm?” where we have already discussed the particularities of forex in relation to flash crashes and runaway algorithms.

Spike Filtering

Many trading systems have incorrectly interpreted the CHF event, especially the important price gaps perceived either during the crash, or later, once trading activity resumed after a more or less long period of closed markets.

For example, when the data feeds were reactivated, the first quotations were significantly different from the last ones known by the systems. The event looked like a perfect price “spike”, i.e. a technical glitch with a non tradable price, which trading systems are taught to ignore.

Indeed, most trading systems incorporate some sort of “anti-spike” filter whose job is to protect the integrity of the data feed which is at the source of the trading decisions. A spike not filtered would quite often trigger orders at a non tradable price.

As you can guess, the trouble added by these anti-spike filters on top of the general panic, did not help.

An anti-spike system is much more difficult to design than how it seems… Let’s say you just filter based on a maximum percentage of variation of the rate, which we will call Y. If Y is too low, you will lose all volatile and fast movements, such as the flash crashes, the news such as NFP, etc. This can be dramatic. And if your Y is too high, you will potentially not filter the spikes… The very goal of such a filter.

You will probably end up moving up and down Y as the market evolves, and you will always experience issues. So the one price variation solution is not good enough.

To improve it, you may want to look at different and non-correlated data feeds. The good news is that with forex we have plenty of such feeds - interbank ones, different ECNs, futures quoted on exchanges, etc.

In addition to the price feed, it could also be useful to add  Liquidity   to the logic of your filter. Indeed, price gaps with high volatility associated to market liquidity drying up, will unlikely be a technical glitch to be filtered out.

But firstly, check if you (and your data provider) are using an anti-spike filter. And if you are using one, review how it works!

But in any case, make sure that you at least have a documented and understandable way of manually disabling it, in order to quickly manually restart the algorithms if need be.

Exception Handling

To generalize a bit from the spike filtering issue, the whole exception handling logic (spike, rejects, markets interruption, spread explosion, etc) from algos has been put heavily under pressure. Developers and traders will have to review this together. We have witnessed that traders often push this on to the developers as it is generally perceived as technical issues handling.

But on this particular day, we had proof that the market could really behave like a bugged one…

Liquidity Fragmentation

This is not about the handling of the event itself, but about one of its consequences. The liquidity environment and credit access have really changed since the SNB event. Some established prime brokers or liquidity providers have stopped or reduced their business while the risk appetite has dramatically been reduced.

It entailed an explosion of smaller market players acting as PoP or liquidity providers. So in case you are in the  Liquidity Aggregation  business, the cost of connectivity investment is increasing in order to connect to more players and to manage the growing complexity of the market. Time to review the “build vs buy” decision you have made about connectivity management.

Be Passive!

With appetite for risk being restrained across the liquidity providers, the liquidity has diminished and logically the spreads have increased on many pairs. This makes it more expensive to trade “aggressively”, i.e. by crossing the spread with market orders.

The consequence is that it has become increasingly interesting to trade “passively” in order to save (or earn depending on how you see things) on the spread cost factor, by getting executed, at least for a portion of the order, inside the bid/ask spread.

Whether you develop yourselves, your execution algorithms or use third-party or banks ones (see my previous article on this topic, “Why Buy-Side Should Take Control of FX Algorithms”), think about your execution tactics, and ask yourself if adding some passivity in your algorithms could help.

Stay Away from Pegs or Heavily Controlled Currencies

Finally, this is not really about algorithmic trading, but it is particularly important for algo traders as many have been naturally inclined to make this mistake.

Only if you really (I mean really) know what you are doing here, and the risks associated with it, stay away from pegged or heavily controlled currencies. “Easy” money always comes with greater and unpredictable risk. It's probably not worth it. And if the CHF crisis was not enough to make you change your mind, think again about what we witnessed lately on the Chinese yuan pairs!

If you missed the first part of this article, then first head to read “Did Your FX algorithms Learn the Lessons from the CHF Storm?” where we have already discussed the particularities of forex in relation to flash crashes and runaway algorithms.

Spike Filtering

Many trading systems have incorrectly interpreted the CHF event, especially the important price gaps perceived either during the crash, or later, once trading activity resumed after a more or less long period of closed markets.

For example, when the data feeds were reactivated, the first quotations were significantly different from the last ones known by the systems. The event looked like a perfect price “spike”, i.e. a technical glitch with a non tradable price, which trading systems are taught to ignore.

Indeed, most trading systems incorporate some sort of “anti-spike” filter whose job is to protect the integrity of the data feed which is at the source of the trading decisions. A spike not filtered would quite often trigger orders at a non tradable price.

As you can guess, the trouble added by these anti-spike filters on top of the general panic, did not help.

An anti-spike system is much more difficult to design than how it seems… Let’s say you just filter based on a maximum percentage of variation of the rate, which we will call Y. If Y is too low, you will lose all volatile and fast movements, such as the flash crashes, the news such as NFP, etc. This can be dramatic. And if your Y is too high, you will potentially not filter the spikes… The very goal of such a filter.

You will probably end up moving up and down Y as the market evolves, and you will always experience issues. So the one price variation solution is not good enough.

To improve it, you may want to look at different and non-correlated data feeds. The good news is that with forex we have plenty of such feeds - interbank ones, different ECNs, futures quoted on exchanges, etc.

In addition to the price feed, it could also be useful to add  Liquidity   to the logic of your filter. Indeed, price gaps with high volatility associated to market liquidity drying up, will unlikely be a technical glitch to be filtered out.

But firstly, check if you (and your data provider) are using an anti-spike filter. And if you are using one, review how it works!

But in any case, make sure that you at least have a documented and understandable way of manually disabling it, in order to quickly manually restart the algorithms if need be.

Exception Handling

To generalize a bit from the spike filtering issue, the whole exception handling logic (spike, rejects, markets interruption, spread explosion, etc) from algos has been put heavily under pressure. Developers and traders will have to review this together. We have witnessed that traders often push this on to the developers as it is generally perceived as technical issues handling.

But on this particular day, we had proof that the market could really behave like a bugged one…

Liquidity Fragmentation

This is not about the handling of the event itself, but about one of its consequences. The liquidity environment and credit access have really changed since the SNB event. Some established prime brokers or liquidity providers have stopped or reduced their business while the risk appetite has dramatically been reduced.

It entailed an explosion of smaller market players acting as PoP or liquidity providers. So in case you are in the  Liquidity Aggregation  business, the cost of connectivity investment is increasing in order to connect to more players and to manage the growing complexity of the market. Time to review the “build vs buy” decision you have made about connectivity management.

Be Passive!

With appetite for risk being restrained across the liquidity providers, the liquidity has diminished and logically the spreads have increased on many pairs. This makes it more expensive to trade “aggressively”, i.e. by crossing the spread with market orders.

The consequence is that it has become increasingly interesting to trade “passively” in order to save (or earn depending on how you see things) on the spread cost factor, by getting executed, at least for a portion of the order, inside the bid/ask spread.

Whether you develop yourselves, your execution algorithms or use third-party or banks ones (see my previous article on this topic, “Why Buy-Side Should Take Control of FX Algorithms”), think about your execution tactics, and ask yourself if adding some passivity in your algorithms could help.

Stay Away from Pegs or Heavily Controlled Currencies

Finally, this is not really about algorithmic trading, but it is particularly important for algo traders as many have been naturally inclined to make this mistake.

Only if you really (I mean really) know what you are doing here, and the risks associated with it, stay away from pegged or heavily controlled currencies. “Easy” money always comes with greater and unpredictable risk. It's probably not worth it. And if the CHF crisis was not enough to make you change your mind, think again about what we witnessed lately on the Chinese yuan pairs!