We are happy to announce that WhiteBIT is now available through our FIX API. XTRD 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. XTRD 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.
In this article, I would like to address the most common questions we received about XTRD 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?
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 XTRD 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 XTRD 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
XTRD 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.
XTRD 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 XTRD stack – accounts are segregated and do not interact with each other.
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.
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.
XTRD 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.
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.
XTRD 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 XTRD 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 XTRD FIX API.
The bot itself contains several main components:
Market data 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 XTRD 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 XTRD supports.
There are three major messages defined by FIX standard and implemented inside XTRD 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 XTRD 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, XTRD 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. XTRD 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. XTRD 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 XTRD 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 XTRD be your ‘pipes and plumbing’ provider!
We are happy to announce that from now Bybit is available through our FIX API. XTRD 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.
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 XTRD 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 XTRD can do any better? One of our main focuses was – and still are – 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. XTRD 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 XTRD, join the club!