Latency arbitrage on crypto markets using Axon Trade OEMS

In addition to our order and execution management system for crypto trading, our company provides integration and custom software development services. In this article, I would like to showcase one such project – a latency arbitrage trading system.

The main concept besides latency arbitrage is straightforward. Due to some market fragmentation, different market conditions, jurisdictions, and even trading hours, the selling price for an asset (BID) on one exchange could be lower than the buy price on another (ASK). This means you can buy in one place and sell in another, pocketing the difference.

Latency arb is very similar to what market-makers do, except for the fact that they prefer to rest somewhere in the order book. In our case, the system performs as a pure taker, scooping liquidity from the top of books. As a measure of self-protection, we only used LIMIT orders with minimal resting time (so if an order was not filled, we had to cancel it).

“Simplicity on paper” comes with a price during implementation – everything should be fast. VERY FAST. Price discrepancies appear for just a moment, and you have a limited amount of time to do the following:

• Receive market data.
• Detect arb opportunity
• Shoot two orders (to BUY on one exchange and to SELL on another) at the same time

Do not forget about error handling because bad things always happen. For example, one leg gets filled, and the second – is either rejected, partially filled, or stuck in a book.

For obvious reasons, we choose Axon Trade OEMS for digital asset trading as a market data source and an entry point for all orders. This allows changing trading pairs and exchanges easily without adjusting any of the trading logic.

Here is a simplified application architecture.

Our end goal was to keep the number of elements as low as possible, so we came up with the following topology:

• Two independent FIX sessions – one for market data, one for trading
• Trading FIX session connected to BuySideOMS, a component to manage order stages
• BuySideOMS acts as a hub to receive trading commands and return execution confirmations to the business logic component
• Brain is more like a complex events processing (CEP) loop that decides what the next step would be based on current market conditions (received through market data FIX session) and order statuses.
• To control and monitor the Brain behavior, we added a REST-based API and a user interface on top of it; the main trick here is that REST API is set aside from the central communication circle – Brain/OMS/Market Data Session/Trading Session.

During development, our team faced several challenges:

• Market data processing procedures
• Error handling
• Asset settlement and rebalancing across exchanges

Axon Trade market data dissemination services don’t apply any throttling or batching to outgoing data. This means a recipient must process the data at an extremely high speed to avoid the situation called “slow consumer” when messages start to pile up in outgoing buffers causing memory overuse. Our servers react simply to it – slow sessions will be terminated after some time. An approach to solve this problem is complex and might include the following:

• Reduce network travel time by locating as much as possible close to our servers
• Increase operation system network buffers on your side – never, never run on a default operating system settings.
• Increase the buffer size on the FIX engine. Most FIX engines allow manually setting the size of a queue
• Avoid mixing market data processing and business logic in the same thread unless the logic is super simple

As long as there is no centralized clearing in crypto (yes, 2022…), you have to maintain a sizable inventory on both exchanges and settle as infrequently as you can. Your main enemy here is the exchange’s trading and withdrawal fees. Withdrawal fees might include direct fees, applied by exchange, and network fees, so watch out for this. From a distance, these numbers might look small, but the profit from arb is also not that big, so you have to perform multiple successful trades. If you do not have enough inventory, you have to rebalance it, and this is the point where withdrawal commissions can erode your trading profit. If you have big books on both sides, you can enjoy the ride!

Asset transfer itself is a challenge. Initially, our client was planning to do crypto vs. fiat arbitrage. To rebalance fiat, we planned to use a solution from a company that is exceptionally aggressive on the marketing side, promoting things they do not have. This is an untrustworthy company, so to speak. Only one step away from production, we realized it had a gap. The solution – switch to stablecoins.

For crypto rebalancing, we were in a position to buy vs. build. A top candidate here was Fireblocks. It certainly has a working product, but the price(access + API) was far beyond our allowed budget. The solution – we built a simple exchange to exchange rebalance.

Now pride time (technological, not coming out) – the system was able to hit the top of the book prices on Kraken and OKCoin in most cases, even when located in Equinix NY4 data center. It was a double pride – the trading app we built was fast, and Axon Trade OEMS was blazing fast. During the course of development, we navigated multiple technological, jurisdictional, and organizational challenges that our team successfully resolved.

As a footnote, does latency arb still exist in crypto? Yes, it does. Can you exploit it? Possibly. But aside from latency arbitrage, many other trading ideas can be implemented on top of Axon Trade OEMS.

If you have any questions (OEMS itself, custom software development services, etc) – feel free to reach out, and we will do our best to assist you.