XTRD OEMS for Crypto

Article by Serg Gulko, Co-Founder & CEO at XTRD

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?

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

Multitenant design

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.

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

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.

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.