Creating a Renko-based Scalper for Binance

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 for free. 

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 
• Trading connector
• Market data processor/Renko generator
• Simple OMS/EMS syste
  


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. 

Also published here.