EMS - Starter Guide
This section will provide general information about the Execution Management System API (
EMS API) software product and enumerate a number of features that it provides.
Execution Management System (EMS) is a software that managing orders, executions and exposure in an efficient, fast, cost-effective, and straightforward manner. An EMS allows you to route orders to multiple cryptocurrency exchanges simultaneously using a simple, robust, and unified Application Programming Interface (API).
Software can be used in 2 different ways:
Managed Cloud- Everything on our side. Hosted in the Cloud by CoinAPI. You manage the deployment using the REST API.
Self Hosted- Software on our side, on your everything else.
|Dimension Comparison||Managed Cloud||Self Hosted|
|Ease of use/installation||Very easy||Hard|
|Time to market||Fast||Slow|
|DevOps team required to maintain||No||Yes|
|Order-flow sent directly to the destination||No||Yes|
|Who manage the infrastructure (incl. monitoring)||CoinAPI||You|
|Who optimize the latency||CoinAPI||You (CoinAPI only in software)|
|How to install||Instruct our Cloud Mgmt API||Install on your infrastructure|
An self-hosted EMS cluster can be deployed on single server or multiple servers that will span multiple geographical locations, server sites or cloud providers. In the Managed Cloud version you did not care about that as we manage the server sites to be as close to the order destinations as possible.
EMS consist of several components listed and ordered by dependency relationship:
Exchange- Order destination, exchange or broker.
CoinAPI EMS Edge- Software that's responsible for communicating with the single specific order destination for which is deployed. This component is exposing the
EMS APIfor diagnostics purposes which functions visibility are limited to this single destination.
CoinAPI EMS API- Software that's responsible for exposing fully functional the
EMS API, maintainitng connection with all instances of
CoinAPI EMS Edge.
CoinAPI EMS WebUI- Web interface (GUI) to the
EMS APIinterface. (optional)
Customer Application- Customer software using the
EMS APIexposed by
CoinAPI EMS APIcomponent.
Specific projects usually involving High-Frequency Trading (HFT) or Market Making (MM) requiring low latency access to the order destination.
EMS API was designed to have native support for this kind of activity.
For every order destination in the cluster to which the submillisecond latency is required, this components should be deployed on a single server as close as possible to the order destination:
CoinAPI EMS Edge
CoinAPI EMS API
Closest proximity can be achieved using the:
cloud region and/or availability zone same as the destination
collocation near the destination
cross-connect or direct-connect to the destination network infrastructure
shortcutting the routers, SNAT/DNAT hosts, or proxies like CloudFlare
The cluster can naturally contain other order destinations at the same time in this setup, and this fact doesn't affect the latency to the locally provisioned destination(s).
Our EMS API provides an abstraction layer that consolidates all supported third-party APIs into a single set of simple and robust data models and protocols. The Exchanges and the Assets are standardized using the Market Data REST API to which this product is compatible. More information about the exchanges and assets standardization can be found in the Documentation of the Market Data Product.
Our API's can be accessed using multiple protocols widely adopted by the industry as a standard:
FIX 4.4, 5.0
Deploy your property applications and trading algorithms in your company collocated data centers or cloud providers if you need that, otherwise let us manage the infrasturcture and focus on using the API.
Don't need to worry about the issues at the audit. Order flow, exchange API keys, or execution reports are never leave your company infrastructure as the product is self-hosted.
Manage unlimited number exchange accounts in the cluster (for example, on behalf of your customers).
We have the SDK libraries and code samples available for more than 40+ languages. Full list is available here: https://github.com/coinapi/coinapi-sdk/tree/master (opens in a new tab)
Leverage support for all market types and order types.
Our integrations with third-party APIs are heavily tested and crafted with the stability and latency in mind. For several third parties, we usually use multiple protocols simultaneously or tricks to acquire valuable pieces of information faster.
EMS product is fully supported and maintained to stay ahead of the curve. This approach offloading the often disliked responsibilities of the Software and DevOps Engineers in the organization and enables them to focus on the core business.
The EMS software is designed to support high-availability deployments out of the box. For each order destination, we/you deploy multiple
CoinAPI EMS Edge and
CoinAPI EMS API components on different servers, availability zones, or cloud/infrastructure providers. Cluster using the service discovery backend, all components are automatically detected and interconnected.
Using the EMS, your organization can manage exposure and positions in real-time across all supported order destinations and build sophisticated risk management controls.
This section will describe lifecycle of the order in the
This table describes how to interpret a specific order status.
|Name||Can transit to||Status description|
|The order is processed by the |
|The order is (on the wire) between the |
|The order has been sent to the exchange and not yet active in the order book.|
|The order is active in the book in its original state.|
|The order cancelation message has been sent to the |
|The order is partially filled and active in the order book.|
|The order is filled and removed from the order book. This state is terminal.|
|The order is canceled and removed from the order book. This state is terminal.|
|The order is rejected. This state is terminal.|
This table describes how to interpret transitions between order statuses and their initial values.
|Source Status||Destination status||Description|
This section will describe parameters of the order in the
EMS supports only the
LIMIT order type. Market orders don't have price protection, and because of that, they are not supported. As an alternative, you can use the Immediate or Cancel
IOC order and provide the worst execution price to achieve the same result.
Time in force
Time in force is a special instruction used when placing a trade to indicate how long an order will remain active before it expires.
The table below describes how to interpret time in force parameter values.
|Time in force||Shortcode||Description|
|A Good Till Cancel (GTC) is a default type of time-in-force. The order that lasts until is completed or canceled.|
|The Good Till Time Exchange (GTTE) time in force lets you set an expiration date and time up until which an order will be active in the book. The exchange handles the execution of the cancel originated from parameter.|
|The Good Till Time OEML (GTTO) time in force lets you set an expiration date and time up until which an order will be active in the book. The |
|Fill or kill (FOK) is a type of time in force used to instruct an exchange to execute a transaction immediately and completely or not at all. This order will only remove liquidity from the order book. It must be filled in its entirety or canceled (killed).|
|An immediate or cancel order (IOC) is a type of time in force used to instruct an exchange to execute all or part immediately and cancels any unfilled portion of the order. This order will only remove liquidity from the order book. It will fill whatever part of the order it can immediately and cancel any remaining amount so that no part of the order is added to the order book.|
The table below displays a breakdown of the
EMS support of specific time in force values by the
|Order destination id|
X - supported.
Execution instruction puts restrictions on order handling at the matching engine. More than one instruction can apply to an order. The table below describes how to interpret execution instructions parameter values. Legend:
X - supported.
|An Auction Only (AO) instructs exchange that this order is for the auction only book for the next auction. The order may be cancelled up until the the auction locks, after which cancel requests will be rejected.|
|An indication of interest (IOI) instructs exchange that this order should be processed as request for liquidity from block trading market markets.|
|A Maker or cancel (MOC) instructs exchange that this order will only add liquidity to the order book. If any part of the order could be filled immediately, the whole order will instead be rejected before any execution occurs. This instruction is also known as |
|Cancel on System Failure (Cancel on disconnect)|
|Reinstate on System Failure (Do not cancel on disconnect)|
|(Reduce only) If part of a position is closed by any other means than the reduce-only order, the reduce-only order will be automatically adjusted downwards. If the trader decides to increase their position before the reduce-only order is executed, the quantity of the reduce-only order will not increase as well.|
The table below displays a breakdown of the
EMS support of specific execution instructions by the
|Order destination id|
X - supported.
For all input and output time values ISO 8601 standard is used.
|The year as a four-digit number.|
|The month, from 01 through 12.|
|The day of the month, from 01 through 31.|
|The hour, using a 24-hour clock from 00 to 23.|
|The minute, from 00 through 59.|
|The second, from 00 through 59.|
|The milliseconds in a date and time value.|
|The ten millionths of a second in a date and time value.|
Input time values are parsed using the following formats as far as possible:
Output time values are formatted using the following patterns: