We are happy to announce that WhiteBIT is now available through our FIX API. Axon Trade OEMS for digital assets trading allows receiving normalized market data and actively trading on WhiteBit’s markets using unified FIX 4.4 end-point.
Launched in Dec 2018, WhiteBIT is a European centralized exchange that offers crypto-to-crypto and crypto-to-fiat transactions with 0.1% trading fees.
With European Exchange and Custody licenses, WhiteBIT meets KYC and AML requirements. It claims to have 150,000+ users from the EU, South America, and Asia registered on the platform.
WhiteBIT offers instant transactions with P2P codes, possibility of staking, private and public API & a number of trading tools: limit, market, stop limit and stop market orders. Quick deposits and withdrawals are carried out with InstantSend by Dash.
We are happy to announce that from now CoinFLEX is available through our FIX API. Axon Trade OEMS for digital assets trading allows receiving normalized market data and actively trading on CoinFLEX’s markets using unified FIX 4.4 end-point.
CoinFLEX (Coin Futures and Lending Exchange) is a physically delivered cryptocurrency futures exchange, developed for investors to hedge cryptocurrency exposure with low index or price settlement risk.
The platform offers innovative solutions such as flexUSD — the world’s first interest-bearing stablecoin — and AMM+, the most capital–efficient automated market maker for today’s investors. CoinFLEX is backed by crypto heavyweights including Roger Ver, Mike Komaransky, Polychain Capital, and Digital Currency Group, amongst others. The exchange is dedicated to providing an easily accessible venue for users to earn and trade crypto with minimal friction.
Article by Serg Gulko, Co-Founder & CEO at Axon Trade
In this article, I would like to address the most common questions we received about Axon Trade OEMS for digital assets trading.
What is the OEMS for crypto trading?
OEMS, sometimes O/EMS, stands for Order and Execution Management System. Initially, it was two separate software types – OMS and EMS which were merged into a single system over time. We live in a time of consolidation and modern OEMS systems are capable (sometimes) of doing much more than before, including positions management orchestrating the settlement process.
OEMS is in charge of many things – orders entry and execution through different liquidity providers, analytics, market data streaming and charts, transactions cost analysis, and so on. The system can be accessed by humans as well as programmatically through APIs such as FIX.
Unlike its peers from established markets like FX, a big part of crypto OEMSs is dedicated to connectivity management. Almost every liquidity provider in the FX space understands FIX; specifications have not changed for years and a TCP/IP connection established on Monday can be disconnected in about one week. This does not happen in crypto which adds some “spice” to the process and extra complexity.
How is OEMS different from libraries?
There are many different open source and proprietary libraries that can act as a normalization layer between your system and exchange(s). This is really a wrapper from general purposes languages like Java, Python, PHP, or JavaScript into widely used in crypto REST/WebSocket calls. Libraries can help you send orders but leave you alone with more complex problems like different symbols’ names, monitoring session states, and performing systems synchronization. Even accessing trading history can be tricky – some exchanges do not store more than 90 days of orders (and in the most extreme cases – only the last 1000 orders).
Of course, you can link the database layer, implement your own mechanisms to deal with dead WebSockets, tune connectors code (in many cases, the quality is far from ideal and many things can and should be improved), add accounts support, and so on. Good job! You just built your own OEMS system.
I see libraries as bricks, while OEMS is an unfinished house. Add hardwood floors, furniture, doors, lights, and a fence – and you’ll get a trading platform, market-making algo, or something different but something that can be used by people. Bricks are important but you can’t live surrounded by just them.
Disclaimer: in Axon Trade OEMS we do not use any third-party normalization libraries to communicate with crypto exchanges. Everything is built in-house to ensure the best performance.
When should I use OEMS for crypto?
In most cases, it’s beneficial to integrate ready-to-use OEMS unless you would like to build your own and become a vendor.
Of course, there are many factors to consider, such as flexibility, functionality, latency, geographical location, support, prices, and even team behind the scene but I can assure you that it’s always possible to find a compromise. There are many solutions on the market, some good, some bad but they can save the most valuable resource – time.
What functions are available from the shelf?
Different systems offer different sets of functions. Below is what Axon Trade OEMS offers to accelerate crypto trading.
Normalized FIX API for trading and market data
We use FIX 4.4 for both market data and trading sessions. It means that, for example, quotes from Binance will look the same as quotes from Coinbase Pro. The trading process also will look identical although exchanges are completely different.
Simultaneous access to multiple crypto exchanges
Axon Trade OEMS is interconnected with major crypto exchanges in the US, Europe, and Asia. All trading operations on different venues can be done through a single TCP/IP connection (or can be spread).
Active orders management
Information about clients’ orders is replicated and constantly updated on our servers. Each trade confirmation or/and cancellation dynamically changes the representation of orders which we store in memory.
Access to trading history
We store every order sent through our system and every execution report received. There is no ‘data retention period,’ everything that gets in, remains there. Information about trading activities includes exchange-assigned IDs, timestamps, trade prices and sizes, and also fees paid.
Multitenant design
Axon Trade OEMS for crypto is designed in a way that allows a single organization to have multiple independent resources, for example, trading desk accounts with their own connections to exchanges, balances, and separated FIX sessions for trading.
Such separation also helps build trading platforms on top of the Axon Trade stack – accounts are segregated and do not interact with each other.
Normalized Symbology
There is no common standard for naming convention. Each exchange lives to create something new and unique (and they have a wild imagination), so we built and maintain our own directory that covers spot and derivatives markets.
Connectivity Management
We carefully monitor outgoing connectivity statuses, and if something goes wrong (and this happens relatively often, unfortunately, due to current infrastructure development) we notify clients, disable trading on a particular destination, and start checking once it returns to normal. Once we connect again, we handle complicated synchronization procedures that include checking all open orders, trading history, and position changes.
Demo Environment
Axon Trade OEMS has a dedicated demo environment that can be used to test integration without putting real money at risk. The Demo Environment fully replicates our production services, including market data streams and management API.
Management API
In addition, to FIX API for trading and market data, we offer REST-based API to manage assets of your organizations – accounts, connectivity to exchanges, FIX sessions, and access rights. This API also can be used to fetch trading history, positions, and even open orders.
Binance is one of the largest cryptocurrency exchanges in the world, responsible for $7.7 trillion crypto exchange volume in 2021. It was founded in 2017 by Changpeng Zhao, who previously worked for Blockchain.info and as CTO of OKCoin.
Axon Trade Overview
Axon Trade is an institutional-grade OEMS for digital assets trading. We provide access to major crypto exchanges through the unified FIX API.
In this article, we would like to demonstrate how to build a small yet powerful scalping application that trades on the leading cryptocurrency exchange – Binance.
The bot will be connected to Binance through Axon Trade FIX API to receive real-time normalized market data and to place/cancel orders.
You can reuse this source code in your projects free of charge.
Disclaimer: the bot is not a ready-to-use solution because it lacks risk controls and proper positions management. Although our R&D shows promising performance, do not expect to achieve the same results.
Before we dive into the technical part, it’s worth explaining the logic behind the given trading bot.
Scalping is a momentum-based trading style where positions hold for minutes or even seconds and then sell for profit (or small loss… a sacrifice to Mr. Market). When performed manually, it requires self-discipline, the ability to handle stress, make quick decisions, and act accordingly.
Renko chart is one of the technical analysis tools that help reduce market noise and identify market trends more precisely. One of the authors of this article was introduced to Renko about 15 years ago and fell in love with it.
To construct a single brick on a chart we should perform several simple steps:
Define a brick size e.g. 10 points
Define the price type to track. It can be bids, asks, trades, an average between the bid and ask, etc.
Start tracking prices in real-time
If the price changed more than 10 points, then form a new Renko brick in the corresponding direction. It is possible that the single price change can form more than one Renko brick.
Here is our trading logic:
Wait for a new Renko brick to be formed
If it is an UP brick, then place a limit order to SELL with a price at the level of UP + 1 brick
If it is a DOWN brick, then place a limit order to BUY with a price at the level of DOWN – 1 brick
Continue monitoring the market for changing course or for execution
If a newly formed brick changed its direction (this means that the price changed at least 2x of a brick size in the reverse direction), we should cancel our existing limit order and place another one with a new price and reversed direction.
If the market moved in the direction we predicted, then our order gets executed and we should start over.
Simply put, it is the good old “buy low, sell high” principle computerized and applied to crypto markets through Axon Trade FIX API.
The bot itself contains several main components:
Market data connector
Trading connector
Market data processor/Renko generator
Simple OMS/EMS system
To make this technical-enough material more fun, we decided to build a small user interface to plot Renkos bricks and executions.
Since all high-level details of implementation were discussed, let’s get started with the implementation part.
To build Renko charts we need to establish a connection to a service called Axon Trade MD Feeder. It is responsible for disseminating real-time normalized market data from Binance (and other crypto exchanges) using FIX protocol. In comparison with WebSockets, FIX is faster and more reliable because it runs on top of a pure TCP/IP stack and has no additional intermediary layers.
Using FIX protocol, you can easily subscribe to receive updates for one or many trading instruments available on Binance such as BTC/USDT, ETH/USDT, and so on. It is possible to specify what sort of information you’ll need – bids, asks, and/or trades. Another big advantage is that market data itself comes in incremental updates. This means that you receive only actual changes of the entire orders book (like 3-4 levels) but not a full book every time. This is not a big issue with Binance which already streams data as a delta (difference between the previous and current state) but can be extremely helpful with other crypto exchanges Axon Trade supports.
There are three major messages defined by FIX standard and implemented inside Axon Trade that help manage your crypto market data streams – MarketDataRequest, MarketDataSnapshotFullRefresh, and MarketDataIncrementalRefresh. As it is easy to understand from their names, MarketDataRequest is used to manage your subscription (start or stop data streams), MarketDataSnapshotFullRefresh is used by the server to transmit the entire book, and MarketDataIncrementalRefresh is sent by the server when data (price or side) in the particular orders book changed.
The market data management workflow is simple – once the application established a connection to Axon Trade OEMs over the FIX, it sends MarketDataRequest to subscribe to all updates on BTC/USDT (or another selected symbol) on Binance.
If the request was successfully processed, Axon Trade OEMS for digital assets trading responds with a MarketDataSnapshotFullRefresh message that contains all levels for BTC/USDT orders book. The application uses this data to initiate the book and starts waiting for incoming MarketDataIncrementalRefreshes that carry small (and sometimes not very small) delta changes. These changes have to be applied to the book (delete levels, update sizes on a particular level, add new prices). Once a book is updated, the component responsible for Renko’s generation will check if the conditions to create a new brick are met or if the price is still within the interval.
Now, when we have a working market data connection and Renkos charts, it’s time to start trading on Binance using FIX API.
FIX specification contains plenty of different messages (commands and responses) that cover pretty much everything in a typical trade lifecycle starting from initiation to ending with trade confirmation and settlement. Axon Trade OEMS system allows managing orders (get all, place, cancel, replace) and viewing positions through the unified FIX API.
When it comes to trading, there are three major messages – NewOrderSingle, OrderCancelRequest, and ExecutionReport.
NewOrderSingle is used to initiate an order. The message allows specifying different order characteristics, such as side (e.g. BUY), size, type (e.g. LIMIT), symbol, time in force (e.g. Good Till Cancel), among others.
Below is a textual representation of the raw FIX request to buy 0.001 BTC for USDT at Market on the Binance.
In many cases, the server interacts with clients over ExecutionReports. This message is used to indicate changes of your orders over time – was it accepted or rejected, canceled, or executed, and if executed, what are the price and size?
Each message has clear status, a clear ID, and a timestamp associated with it.
Many exchanges have their own workflows. Axon Trade OEMS for digital assets trading helps normalize these statuses and make them identical across all supported platforms:
Our demo application utilizes only two simple commands – NewOrderSingle (to place a new order) and OrderCancelRequest (to cancel an order we don’t need anymore).
Another useful command is OrderCancelRequest. It is used to initiate the cancellation of a pending order or the outstanding amount of a partially filled order.
Below is a sample of FIX-based OrderCancelRequest to cancel a pending order on Binance:
Our demo application will send requests to open an order (using NewOrderSingle) and to cancel it (using OrderCancelRequest) over the FIX to Binance. The server will notify us (using ExecutionReports) in real-time about any status changes of our order(s).
In real life, it’s always a good idea to separate business logic that makes decisions about entering or exiting the market from orders management. This component is usually complex and covers a vast array of scenarios of what can happen with orders starting from regular behavior when everything goes as expected and ending with different doomsday scenarios.
For the sake of simplicity, in this sample, we decided to use oversimplified orders management which also handles incoming market data-related events (OMS.java).
Below is the video of the working system (replayed with 50х speed):
Building a successful trading system is a challenging task where you must overcome many obstacles. Our goal is to make sure that the connectivity between your application and target exchange (or exchanges) will not become one of these blocking factors. By using Axon Trade OEMS for digital assets trading, you can easily build a reliable system that can operate around the clock. Connect to our FIX API to trade on Binance or many other exchanges and/or to receive real-time normalized market data. Focus on your business and let Axon Trade be your ‘pipes and plumbing’ provider!
Conclusion: FIX is a truly cross-platform/language way to build trading systems. You can use C++, Java, Python, JavaScript, and many other languages to integrate with Axon Trade OEMS for digital assets trading. Trade with ease on Binance, OKEx, FTX, ByBit simultaneously through our FIX API.
We are happy to announce that from now Bybit is available through our FIX API. Axon Trade OEMS for digital assets trading allows receiving normalized market data and actively trading on Bybit’s Spot, Futures, Perpetual Futures, and USDT-based Futures markets using unified FIX 4.4 end-point.
In order to cover dynamically growing crypto derivatives markets, we made a decision to change the naming convention for perpetual swaps, futures, and options.
Starting from October 01st, 2021, the new schema will be in effect in both NY4 and LD4 locations.
The new schema will follow next rules:
security_type:base-asset:quote-asset
Security Type
Base Asset
Quote Asset
Example
PERP
Perpetual Swap
BTC-PERP
BTC
USDT
PERP:BTC-PERP:BTC
PERP:ETH-PERP:USDT
FUT
BTC-25MAR22
BTC
FUT:BTC-25MAR22:BTC
OPT
BTC-29JUL21P40000
USDT
OPT:BTC-29JUL21P40000:USDT
Base Asset is actually the contract bought or sold.
Quote Asset indicates what asset will be used as a collateral. It could be anything starting from BTC, ETH, followed by stablecoins such as USDT, or even fiat like USD.
Among many technical questions we receive, the latency-related group definitely stands out. Having deep HFT roots, I fully share concerns about this topic. Back in the day, building strategies for FX markets, we were choosing one CPU family over the other, preferring to use switches and routers of certain non-mass-market brands, install and tune very specific network cards, and so on. By the way, we replicated all this in the Axon Trade eco-system, that is why our NY4 location is equipped with Aristas and Exablaze servers!
But, of course, all these optimizations should be made only after your code is tuned to perfection. There is no economical sense of burning thousands of dollars on expensive hardware toys while you might have a bigger problem and it’s closer than you think.
We’ve been consulting several so-called “crypto-first” prop trading shops who bought absolutely top-of-the-line/high-cost servers and rented private internet lines from Avelacom (by the way, we also use Avelacom for certain destinations) to shave 4-7 ms of network-added latency. But! And here comes the best part – they had plans to use the CCXT library to trade. Don’t get me wrong, CCXT is a great library and I personally do respect the Open Source community but CCXT is not about HFT! So the fund guys win 7 ms by using high-end hardware and private networks but lose sometimes up to 200 ms by using the wrong software.
Why do I think Axon Trade can do any better? One of our main focuses was – and still is – lowering latency in all possible ways. We analyze exchanges’ APIs, measure execution times, and build our connectors in order to notify clients as soon as possible when something happens.
Let me give you an example. Bittrex has a REST API to submit orders and an event-driven notification channel built on top of the terrible Microsoft SignalR stack. SignalR, in its turn, provides information in “orders” and “executions” channels. Data from the “executions” channel is more informative and useful (at least from our standpoint) but sometimes it comes with 300 (!) ms delay after similar, but less granular, updates in “orders”. What is really funny is that initial responses over the REST API come (sometimes, not always, which makes it even more interesting) faster than confirmations through SignalR. We know all these nuances and our connectors are capable of dealing with such situations. Of course, it creates certain complexity and non-linear logic but this is what we do for living.
Another example – when you cancel an order on Binance, you can rely on WebSocket notifications (which is a very convenient way) but in many cases, the REST API gets you a faster response. How fast? 10 ms! So you’ll know that your order has been canceled 10 ms faster and act on it accordingly. In the HFT world 10 ms is almost an eternity.
Each exchange has such “Easter eggs” and we know many of them. Axon Trade combines powerful hardware with a software layer, optimized to “shave” 10 ms here and 45 ms there. If you are committed to win, everything matters – your algo, the way it is coded, servers to run it, the right network to communicate, and a reliable partner to execute. Cut these latencies with Axon Trade, join the club!
We are happy to announce that Axon Trade’s OEMS for digital asset trading is now available in the Equinix LD4 location – London, UK!
The main reason we did this is to provide access through our low-latency FIX API to major derivative and spot trading exchanges, located in the EU and nearby.
In LD4 we offer the same set of connectivity options as in NY4 – cross-connection, co-location, and VPS connectivity through our partners.
