DEV Community: Maxim Molchanov

5 things I wish I knew before writing a financial exchange

Maxim Molchanov — Thu, 13 Feb 2020 10:09:11 +0000

“Tell me, and I will forget. Show me, and I may remember. Involve me, and I will understand.”

When I and my cat set off to developing a financial exchange engine, this very quote of Confucius was ringing in my head. We were a dream team: motivated, solid, result-oriented. Our condition could be best described as interest and readiness to take on challenges on our way to MVP. All those challenges and discoveries, met during development, have adjusted the whole process and were well worth the time spent. Today I’d like to share some of them with you — and tell about the results of this experiment as well.

For the impatient, here is the link to the self-hosted demo. The rest, please, welcome to read further.

The main challenge of this project was the limited resources. If this limit hadn’t been that critical, the following list would, probably, look a bit different. My insights might seem banal, but each question can be treated differently. There is a huge divide between just ‘hearing about a problem’, ‘becoming aware of the problem’ and ‘understanding the problem’.

So, here is the list:

It’s way harder to bring a project to MVP than just to start it

When you are working on a project single-handedly and, what’s more, in your free time only, it’s very easy to shift the deadlines. I personally had to stop for half a year because of the main workload and family issues.

The project implementation was divided into two parts: March-April 2019 and November-December 2019. In November I wasn’t sure that I would come to MVP. However, all the internal interfaces were ready, as well as the storage system and order processing. All I had to do was create user interfaces. So, I decided to move on.

As a result, I realized that it’s better not to put projects on hold as the initial motivation is lost and the focus can be shifted. To keep going, I had to put a real effort in finding time for the project again.

Marketing can be different

This insight appeared after I’d been researching and choosing the frontend stack. Now there is a wide variety of libraries and frameworks whose APIs are changing so rapidly that it might make you stunned.

The hype around any of them is not an indication of quality. The size of the community around a project often doesn’t correlate to the quality of the solution. If a project/solution/technology position themselves as the best of the best and are described as ‘magical’ and ‘amazing’, it’s better to take it with a grain of salt or even avoid. It is likely to save you some time in future.

You never know which problem of failure in third-party software you might encounter

Even proven technologies can let you down. It happens so that an instrument you’ve been using for a long time starts acting not the way you want. To my surprise, it happened to me while I was working on this project too. There was Timescale and its time_bucket which didn’t support big intervals; Tarantool and replication issues and manual control of transactions; Rustler which started copying more data while calling functions...this list can be continued. What I realized here was that in the open source world you can always manage to fix the problem or find a way to avoid it by digging deeper into the source code of the app.

When resources are limited, you can’t but plan the amount of work carefully. If a problem turns up, you have do deal with it on your own, be it a small one or big one. You just have noone to delegate it to.

So, every technical difficulty — for instance, a mistake in a third-party library, or a limitation in a technology you are using, or sometimes an issue of architecture — can seriously shift the deadline.

Your eyes might glaze over and affect decision making

Usually, in case of commercial development, we communicate with other people. Any project involves people who are making it or using it. During development, we constantly get updates from other members of the process which add up to our perspective. Making any technically challenging decision is a complex process. When you are absorbed in a problem and spend hours or even days trying to find the ways of addressing it, you sometimes can’t keep your focus.

I’ve realized how important and valuable working in a team is. An opportunity to discuss a question with a colleague who isn’t working on the same task but is still in the know can be really useful. They will be able to assess your approach or solution critically, and it will save your time and reduce the likelihood of mistakes.

Teaching programming to a cat is a tricky business

If you want to repeat my experiment, here is something to bear in mind. Despite the fact that my four-pawed buddy demonstrated genuine interest to the project, it didn’t stop him from getting lazy or distracted all the time. After a couple of weeks I realized that there is no way he’d become a programmer. However, his teamwork skills can’t be underestimated. He was in charge of maintaining the team spirit and, needless to say, he did his best.

Project outcomes

Before I started this experiment, I’d set 2 main goals:

A deeper understanding of the subject and improvement of technical expertise;
Identifying strengths and weaknesses of functional languages and open source projects in trading systems development.

During the experiment I definitely managed to deepen and systematize my knowledge and expertise and even tried to share the outcomes with the community — by the way, you will find the links to the previous boringly theoretical articles in my profile. So, this goal has been achieved successfully.

As to the functional programming...well, I’m looking from Erlang/OTP perspective now. Erlang as a language and OTP as a framework are suited to industrial programming and financial systems implementation. First, the ecosystem is quite mature. Second, minimum syntactic basis of the language, immutability, and approaches embodied in OTP enable for quick implementation of scalable, distributed and reliable systems.
Unfortunately, I didn’t keep a time log, but the whole process took me about 4 months while working after having done my day job. Meanwhile, there are more than 200 integration tests in the project.

Sounds good and all, you will say. However, there still is a small fly in the ointment. Erlang is pretty similar to Python in terms of performance. Unlike Python, it lets us write highly concurrent systems with an adjustable level of parallelism. Also, such systems are easy to scale, and the components can be distributed within a cluster. The systems turn out to be of high capacity, but not superfast.
Basing on the last conclusion, I realized that the most effective and productive approach would be not distributing market handlers and client accounts to different machines within a cluster, but processing all markets and accounts within a single machine with data replication for the sake of reliability.

Due to the limited performance of Erlang, market processing should be done with the help of lower-level languages without GC and fair schedulers. In current implementation I have already moved some part of the functional to NIF on Rust.
This way, thanks to the optimized work with network and binary structures, Erlang perfectly solves the issues of organizing a reliable and fast platform. An issue of working with orders and accounts, though, is better to be solved with the help of Rust/C/C++ (to your taste).

Last but not least is the choice of the language for frontend. Old habits die hard — I opted for Vue + Js. However, if I were choosing the stack now, I would prefer Vue + Typescript. Stricter typing would make it possible to accelerate the development.
All in all, thanks to everyone who was following the experiment. I hope it wasn’t too boring, or was it? Stay tuned — it’s not goodbye! :-)

Vonmo Trade Experiment. Part 4: Stock charts

Maxim Molchanov — Tue, 21 Jan 2020 14:23:33 +0000

In the previous articles we dealt with order creating and processing. Today’s one will focus on processing and storage of the information which is essential for graphic instruments of market analysis – or just stock charts.

To assess the market condition properly, we can’t manage with just an order book and trade history. We need an instrument which will help to see the market price trend clearly and fast. Charts can be divided into two types:

Line charts
Interval graphs

Line charts

These are the easiest and the do not require any preparation to be understood. Line charts show the dependence of a financial instrument price on time.

Chart resolution

If we start building a chart based on all the price changes, i.e. every closed deal gets to the chart, it will be really difficult to take. Also, the capacities used for this chart processing and delivery will be wasted.
That’s why data should be decimated: the timeline is split into intervals, and the prices within these intervals are aggregated. Resolution is the size of a basic interval of timeline splitting: second, minute, hour, day etc.

Bar chart

They belong to interval graphs. To increase informativeness, we need to show the price information at the beginning and at the end of the interval for every single interval. We also need to show the maximum and the minimum price. The graphic representation of this set is called a bar. Let’s look at a bar scheme:

A sequence of bars makes a bar chart:

Candlestick chart

Like bar charts, they belong to interval graphs. They are the most popular type of graph in technical analysis. A ‘candlestick’ consists of black or white body and shadows – higher one and lower one. Sometimes a shadow is called a wick. The highest and the lowest borders of a candlestick illustrate the highest and the lowest price during the time interval represented. The body borders show the opening price and the closing price. Let’s draw a candlestick:

A sequence of candlesticks make a candlestick chart:

OHLCV notation

In the previous article we dealt with the scheme of data storage for a graph in postgresql and built a table for data source which will store aggregated data:

CREATE TABLE df
(
    t timestamp without time zone NOT NULL,
    r df_resolution NOT NULL DEFAULT '1m'::df_resolution,
    o numeric(64,32),
    h numeric(64,32),
    l numeric(64,32),
    c numeric(64,32),
    v numeric(64,32),
    CONSTRAINT df_pk PRIMARY KEY (t, r)
)

These fields don’t need to be explained except, probably, the r field which is the row resolution. In postgresql there are enumerations which are great to use when we know the value set for a field in advance. Let’s define a new type for permissible chart resolutions via listings. Let it be a row from 1 minute to 1 month:

CREATE TYPE df_resolution AS ENUM
    ('1m', '3m', '5m', '15m', '30m', '45m', '1h', '2h', '4h', '6h', '8h', '12h', '1d', '3d', '1w', '1M');

It’s important to find a balance between IO performance, CPU performance, and final cost of ownership. At the moment, there are 16 resolutions defined in the system. Two obvious solutions present themselves:

We can calculate and store all resolutions in the base. This option is convenient because, while selecting, we don’t spend capacity on interval aggregating and all data are ready for output straightaway. There will be slightly more than 72k records for one instrument per month. Looks easy and convenient, doesn’t it? However, such table will change too often because for each price update we need to create or update 16 records in the table and rebuild the index. There might be an issue in postgresql with garbage collecting too.
Another option is to store a single basic resolution. While selecting from basic resolution, it’s necessary to build the resolutions required. For example, if we store a minute resolution as the basic one, 43k records will be created for each instrument per month. This way, compared to the previous option, we are reducing the record volume and overhead costs by 40%. However, CPU load is increasing at the same time.

As mentioned before, it’s really vital to strike a balance. That’s why a middle ground would be to store not just one basic resolutions, but several: 1 minute, 1 hour, 1 day. Under this scheme, there are 44,6k records created for each instrument per month. Optimization of record volume will be 36% and CPU load will be acceptable as well. For instance, to build week intervals we’ll need to read from the disc and aggregate the data of 7 day resolutions instead of reading and aggregating 10080 records with minute basic resolution.

OHLCV storage

OHLCV is a time series in its nature. As is known, relational database is not suitable for such data storage and processing. Our project deals with this problem with the help of Timescale.
Timescale improves the performance of insert and update operations, and enables to configure partitioning, and provides the analytical functions which are specially optimized for working with time series.

To create and update the bars, we’ll need standard functions only:

date_trunc(‘minute’ | ’hour’ | ’day’, transaction_ts) – to find the beginning of the interval of a minute, hour, and day resolution respectively.
greatest и least – to define the maximum and minimum price.

Thanks to upsert api, only one update request is performed per each transaction.

What I got in the end is the following SQL for fixing market changes in basic resolutions:

FOR i IN 1 .. array_upper(storage_resolutions, 1)
LOOP
    resolution = storage_resolutions[i];
    IF resolution = '1m' THEN
        SELECT DATE_TRUNC('minute', ts) INTO bar_start;
    ELSIF resolution = '1h' THEN
        SELECT DATE_TRUNC('hour', ts) INTO bar_start;
    ELSIF resolution = '1d' THEN
        SELECT DATE_TRUNC('day', ts) INTO bar_start;
    END IF;

 EXECUTE format(
    'INSERT INTO %I (t,r,o,h,l,c,v)
    VALUES (%L,%L,%L::numeric,%L::numeric,%L::numeric,%L::numeric,%L::numeric)
    ON CONFLICT (t,r) DO UPDATE
    SET h = GREATEST(%I.h, %L::numeric), l = LEAST(%I.l, %L::numeric), c = %L::numeric, v = %I.v + %L::numeric;',
    df_table, bar_start, resolution, price, price, price, price, volume,
    df_table, price, df_table, price, price, df_table, volume
 );
END LOOP;

While selecting, the following functions will serve us for aggregating the intervals:

time_bucket – to split into intervals
first – to find the opening price – O
max – the maximum price per interval – H
min – the minimum price per interval – L
last – to find the closing price – C
sum – to find the trade volume – V

The only problem with Timescale is the limitation of time_bucket function. It enables to manipulate the intervals less than a month only. To build a month resolution, we should use the standard function date_trunc.

API

To display the graphs on the client, we’ll use lightweight-charts from Tradingview. This library enables to configure the appearance of the charts and is quite convenient to exploit. I’ve got the following charts:

As the main part of the browser-platform interaction is carried out via websocket, there are no problems with interactivity.

Data source

The data source for charts (or data feed) must return the required part of the time series in needed resolution. To save the traffic and processing time on the client, the server must pack the points.
API for data feed should be designed so that you can request multiple graphs in a single request and subscribe to their updates. This will reduce the number of commands and responses in a channel. Let’s consider a request of the last 50 minutes for USDGBP with automatic subscription to the graph updates:

{
   "m":"market",
   "c":"get_chart",
   "v":{
      "charts":[
         {
            "ticker":"USDGBP",
            "resolution":"1h",
            "from":0,
            "cnt":50,
            "send_updates":true
         }
      ]
   }
}

For sure, we can request the date range (from, to), but as we know each bar interval, declarative API indicating the moment and the number of bars seems more convenient to me.
Data feed will respond to this request in the following way:

{
   "m":"market",
   "c":"chart",
   "v":{
      "bar_fields":[
         "t","uts","o","h","l","c","v"
      ],
      "items":[
         {
            "ticker":"USDGBP",
            "resolution":"1h",
            "bars":[
               [
                  "2019-12-13 13:00:00",1576242000,"0.75236800",
                  "0.76926400","0.75236800","0.76926400","138.10000000"
               ],
               ....
            ]
         }
      ]
   }
}

bar_fields field contains the information about the position of the elements. Further optimization involves putting this field into the client configuration which it gets from the server during the client initialization. This way, the client gets a necessary part of historical data and builds the initial state of the graph. If the state changes, the clients gets an update on the last bar only.

{
   "m":"market",
   "c":"chart_tick",
   "v":{
      "ticker":"USDGBP",
      "resolution":"1h",
      "items":{
         "v":"140.600",
         "ut":1576242000,
         "t":"2019-12-13T13:00:00",
         "o":"0.752368",
         "l":"0.752368",
         "h":"0.770531",
         "c":"0.770531"
      }
   }
}

Interim conclusion

Over the whole series of articles we went through the theory and practice of building an exchange. Now it’s time to put the system together.
The following article will tell about the development of user graphic interfaces: service UI to operate the platform and UI for end users. Also, you’ll be able to take a look at the demo version of Vonmo Trade.

Thanks to Nadezda Popova for proofreading.

Vonmo Trade Experiment. Part 3: Order book. Processing and storing trade info

Maxim Molchanov — Fri, 17 Jan 2020 12:59:31 +0000

In the previous article of the series we got familiar with order types. Today we’ll take a closer look at an order book, processing orders, and dealing with issues of trade information storage.

Supply and demand

I’m pretty sure you remember the law of supply and demand from economics. It shows the market mechanics in pricing:

The same mechanics works at exchanges.

An order book is a list where all limit orders of buyers and sellers go. This way, the current interest to a particular financial instrument is demonstrated.

If we transform the previous graph with regard to an order book, we’ll have something like that:

We can see that the market price appears when the maximum bid price equals the minimum offer price. The difference between these prices is called spread. Spread is an important indicator as it is connected with an instrument liquidity. The less the spread is, the more liquidity the instrument has. To provide liquidity within exchange trading process, a limit on maximum spread is often imposed. If this limit is exceeded, bidding is stopped.

Creating an order

Let’s have a look at an order life cycle, from getting to the exchange to being executed or cancelled. For ease, we’ll focus on a foreign exchange market. A special process is responsible for order processing logic. Let’s call it a market controller.

So, a trader creates an order and it gets to the exchange. The controller must make sure that the trader has enough liquidity to create the requested type of order. As a source of information, an internal accounting server or any external APIs can be used.

To fulfil this order immediately, the market must have a counterbid, or a so-called matching order. If the counterbid exists, then a smaller order from the pair is executed fully, and the bigger one partially — of course, as long as partial order fulfillment is allowed by the order trade instructions. If the counterbid doesn’t exist, a new order gets into the order book and takes its place in the list of the orders of its type.
Since only pending orders can get into the order book, we need to create special lists for other order types.

In all order lists the buy side should be sorted in descending order while the sell one — in ascending order. The first item of the limit orders list shapes the best ask and bid prices respectively.

One more important point is the order of execution. The controller must implement FIFO. That is why, if the prices of two orders are identical, the first one to fulfil is the one which has been created first.

In user interface the order book looks like a table with a set of price levels. It shows both buy limit orders and sell limit orders.

Buy orders and sell orders are in different colours to be distinguished easier.

Price levels aggregation

The order book depth is a number of price levels. For active markets with lots of pending orders, which differ as little as they can, this depth can be too big to be shown in the trader’s terminal. We need a tool for grouping the levels to assess the whole book.
By cutting off one decimal place at a time and grouping the levels, we can reduce the number of levels with each step.

Fulfilling and cancelling orders

After an order in the order book has been executed or cancelled, the controller must update the book and delete the order. It also notifies all interested parties of the changes in the book.

Handlers architecture and scaling

Taking into account required performance and reliability of the system, we need to define the approaches to scale applications and data storage layers.

Normally, vertical scalability is used for exchanges. The code of order processing and user accounts processing is run on one machine as a monolith process. Such approach demonstrate good performance but has certain limitations — in any case, vertical scalability has its limits in terms of CPU and storage capacity.

As part of the experiment, I decided that market processing should be scaled horizontally. Each individual instrument is handled by its own process. The processes are automatically distributed between cluster nodes. In case of failure, a market is moved to another node without loss of state.

The system formula is quite simple: M handlers are distributed on K cluster nodes and use L data storages.
This model lets us scale a system up to approximately 150k nodes, and each market controller can process about 30k RPS.

As the flow of orders is different at different markets and depends on users participation, we can divide all markets into several groups: big, medium, and small ones. Each node has the settings enabling us to specify the limits of the markets which it can process. The master is evenly and automatically distributing the markets of the same type between the cluster nodes. If the cluster composition has been changed, the markets are redistributed. This way we can achieve more or less equal distribution of the system load.

Nodes in management UI look something like this:

Data storage

The order book is constantly changing and must be stored in memory. For MVP I’ve opted for Tarantool with WAL as an in-memory storage. All historical data will be stored in PostgreSQL.

The storage scheme for current and historical data must comply with the chosen scheme of code scalability of the handlers. Each market can use its own postgres and tarantool. To make it possible, let’s combine postgresql and tarantool into a single entity — market data storage. While setting the market, an administrator is able to manage the storages. To retain flexibility, we’ll be indicating the unique id of the connection pool instead of credentials to certain postgresql and tarantool instances. The pool interface is supported by the platform. So, the storage looks like this in admin UI:

While setting the market, the administrator must indicate at least one storage for each market. If several are indicated, we’ll have a market with logical replication of data. This function enables us to configure the reliability and performance of the data storage scheme.

Order book data

Tarantool uses spaces for stored data organisation. The declaration of spaces necessary for the order book looks like this:

book = {
    state = {
        name = 'book_state',
        id = 1,
    },
    orders = {
        limit = {
            buy_orders = {
                name = 'limit_buy_orders',
                id = 10,
            },
            sell_orders = {
                name = 'limit_sell_orders',
                id = 20,
            },
        },
        market = {
            buy_orders = {
                name = 'market_buy_orders',
                id = 30,
            },
            sell_orders = {
                name = 'market_sell_orders',
                id = 40,
            },
        },
      ...
    },
    orders_mapping = {
        name = 'orders_mapping',
        id = 50,
    },
}

As several markets can store their data on one tarantool instance, let’s add market id to all instances. Current book implementation is based on the so-called precalculated principle. When the book is being updated, the groups are automatically recalculated. For example, we add an order to the market with 6 digit precision for prices. We can have 6 possible groups of prices + one slice with the order raw data which need to be updated.
There is a number of orders_mapping orders for getting the client’s active orders.

Thanks to tarantool’s indexes and iterators, lua-code for the order book storage consists of 600 lines only (together with initialization).

Historical data

Market data are stored in tables, separately for each market. Let’s take a look at the set of basic tables.

Orders execution history

To save the results of order processing, we have history table. All the orders that are completely fulfilled and the orders which are cancelled but partially fulfilled go there.

CREATE TABLE public.history
(
    id uuid NOT NULL,
    ts timestamp without time zone NOT NULL DEFAULT now(),
    owner character varying(75) COLLATE pg_catalog."default" NOT NULL,
    order_type integer NOT NULL,
    order_side integer NOT NULL,
    price numeric(64,32) NOT NULL,
    qty numeric(64,32) NOT NULL,
    commission numeric(64,32) NOT NULL,
    opts jsonb NOT NULL,
    CONSTRAINT history_pkey PRIMARY KEY (id, ts)
)

Reports for customers are computed based on their trade history which is stored in this table.

Historical data feed

For analytical purposes and historical data feed building, the market controller must save the information about the event after every transaction. The ticks table is used to commit all market changes:

CREATE TABLE public.ticks
(
    ts timestamp without time zone NOT NULL,
    bid numeric(64,32) NOT NULL,
    ask numeric(64,32) NOT NULL,
    last numeric(64,32) NOT NULL,
    bid_vol numeric(64,32),
    ask_vol numeric(64,32),
    last_vol numeric(64,32),
    opts jsonb DEFAULT '{}'::jsonb,
    CONSTRAINT ticks_pk PRIMARY KEY (ts)
)

It contains prices and market volume after a transaction has been made. The opts field contains service-based data, for example, the description of the orders involved in the transaction.

Data feed for charts

The ticks table is enough to be able to build stock charts. It contains the so-called raw data stream, but postgresql has powerful analytical functions and enables us to aggregate data on request.
Troubles start when there is too much of data and lack of available computing resources. To solve it, let’s create a table with pre-calculated data:

CREATE TABLE public.df
(
    t timestamp without time zone NOT NULL,
    r df_resolution NOT NULL DEFAULT '1m'::df_resolution,
    o numeric(64,32),
    h numeric(64,32),
    l numeric(64,32),
    c numeric(64,32),
    v numeric(64,32),
    CONSTRAINT df_pk PRIMARY KEY (t, r)
)

In the next article we’ll talk about working with time series in Postgresql, preparing data for df table, and building charts.

Conclusion

This article has given us a better understanding of the main moments of order book organisation, as well as order processing mechanism. We have also had some practice of working with market data.
The chosen storage scheme enables us to start with just one storage for all markets and, as the project grows, spread the markets to different storages and place them as close as possible to market handlers.

Vonmo Trade Experiment. Part 2: Orders. Types and processing features

Maxim Molchanov — Thu, 09 Jan 2020 15:40:56 +0000

To figure out how exchanges work, we need to look into exchange orders and the way broker processes them.
This article deals with order types, the way they are executed at an exchange, and limitations imposed by trading system.

If you are curious to know what all those DAY, GTC, FOK, IOC, GTD, GAT, MOO, MOC, LOO, LOC, MIT, OCO, OSO, PEG mean, you are welcome.

Orders

All market players are interested in a good deal. To start bidding, we need to create a sell or a buy order for a required financial instrument. Consequently, a set of orders placed on the exchange creates current supply and demand. A market order is instructions from a client to their broker to buy or sell financial instruments at the exchange.
A typical order contains the following information:

Financial Instrument Identifier
Order type
Order side. Buy or sell.
Price
Quantity
Order duration type (optional)
Additional instructions (optional)

We can break all the orders into three big groups:

Market orders. This order must be executed immediately at the current market price. If there is no necessary amount, then the order is executed as soon as possible.
Pending orders. A request enables to control the limit prices for buying and selling. Sometimes such orders can not be executed straightaway or at all. The price is always better for limit orders.
Conditional orders. These are all requests except limit ones that require extra conditions to be activated and executed.

Time in force

You have, for sure, seen acronyms like DAY, GTC, FOK, IOC, GTD, GAT All of them indicate how long an order will remain active before it is executed or expires.

DAY. These orders expire at the end of the trading day.
GTC (Good till canceled). This order is valid until it is cancelled. To make sure they don’t stay at the market indefinitely, a special limitation is imposed, which is usually from 30 to 90 days.
FOK (Fill Or Kill). The order must be fully filled or immediately cancelled.
IOC (Immediate Or Cancel). The order is immediately executed or cancelled by the exchange. Unlike FOK, this type allows for partial fulfillment.
GTD (Good-til-Date/Time).
GAT (Good-after-Time/Date).

Conditions of order execution

By combining instructions on prices, time in force and extra limitations, we can get various types of order execution. To get a better idea, let’s get back to the order types structure which is presented at the beginning of this article.

Market-on-open/close orders

If we limit the duration of period when this market order is valid, we get the following:

MOO (Market-On-Open). A market order of such type can be executed only at the opening of the trading day. Its execution is guaranteed provided there is liquidity.
LOO (Limit-On-Open). Like MOO, LOO can be executed at the opening of the trading day only. However, limit orders of this type enable for setting instructions for the price. The execution is not guaranteed.
MOC (Market-On-Close). These orders are similar to MOO, but the market order can be executed at the closing of the trading day only. The execution is guaranteed provided there is liquidity.
LOC (Limit-On-Close). These orders are similar to LOO, but the market order can be executed at the closing of the trading day only. The execution is not guaranteed.

Conditional orders

When we want to tailor our orders for some trading strategy, we can do it with the help of conditional orders – the ones which are activated only after the condition has been satisfied. Thus, their main aim is to minimize the risk of significant financial losses.

Stop order

Stop order is a bid or an ask for a certain amount of a financial asset at a specified price or worse. As soon as the price equals or exceeds the specified stop price for a bid order, it automatically turns into a market order and is executed on general grounds. It works the same way with a stop order for selling. As soon as the price reaches the level set in the order and continues to fall, the order turns into a market one. This way, execution is guaranteed for active stop orders. Stop orders let us minimize potential losses, that’s why stop loss is the synonym for the stop order.

Stop-limit order

Unlike usual stop orders, where just the stop price is specified, stop-limit orders require also a limit price.
As soon as the asset price is equal or worse than the stop price, a limit order with the specified limit price is automatically created. The execution of such order is not guaranteed.

Trailing stop order

Unlike usual stop orders, where the stop price is shown in absolute units, trailing orders use percentage. After activation, it turns into a usual market order. This way, the stop price is linked to the market price and grows with it. For example, we’ve placed an order for 10 dollars and set the stop price at 10% from the current one, i.g. the absolute stop price equals 9 dollars. Then, the asset grew to 15 dollars alongside with the stop price which grew to 13.5 dollars.
This order type is used to minimize losses as well as maximize profit.

Trailing stop-limit order

Unlike trailing stop orders, this order turns into a limit one, not a market one, after activation.

PEG order

This is a kind of limit orders. It changes its price automatically after the change of bid or ask prices. In price instructions a shift for the worse from the current best bid/ask price is indicated.

OCO order (one cancels other)

This is a pair of orders. It usually consists of a stop order and a limit order. Both orders work with the same instrument. If one of them is executed, the second is automatically cancelled.
A simple example: let’s imagine that we’ve bought an asset for ＄10. We aim at getting at least ＄3 of profit and limiting the losses to ＄2 at most. Then our stop price will be ＄8 and our limit price ＄13.

OSO order (one sends other)

This order consists of the main order and a group of linked orders. Orders can work with different instruments. If the main order is executed,all linked orders are then sent.

Now when we’ve briefly reviewed orders theory, let’s get down to practice.

Practice

From the system point view, it’s crucial to define the basic structure for all orders in a flexible, but precise way. Erlang enables us to do that with the help of records:

-record(exchange_order, {
  id :: binary(),
  orig_id :: binary(), 
  ticker :: binary(),
  owner :: binary(),
  trader :: binary(),
  type :: non_neg_integer(),
  side :: non_neg_integer(),
  time_in_force :: non_neg_integer(),
  price :: binary(),
  trigger_price :: binary(),
  qty :: binary(),
  orig_qty :: binary(),
  created_ts :: non_neg_integer(),
  updated_ts :: non_neg_integer(),
  deals_history :: [#exchange_deal{}],
  linked_orders :: [#exchange_order{}],
  opts :: map()
}).

Order identification

After an order has been placed on the exchange, it gets an internal identifier – id field.
To improve user’s experience, when we are coordinating the exchange with external systems, we should enable an external system to set its own id to the order being created. It will give us a possibility to request orders both by id and by orig_id. Also, it will enable us not to use extra order mapping in the external system.

Order ownership

Let’s provide a possibility to create an agent (external broker) in our system. Orders can come directly from traders or from a broker that provides services to clients who don’t have direct access to the exchange.
In case of a direct order owner and trader coincide.

Instruction encoding

Let’s look at the rest of the fields. There are two fields for encoding the instructions by price: price, which is the limit price for limit orders, and trigger_price, which is the trigger price for custom types. For instance, in case of stop orders this field will encode the stop price.

We use qty and qty_orig for encoding the volume. Qty_orig sets the initial order volume and qty – the order volume while being fulfilled.
deals_history array will help to have precise information about partial fulfillments. With its help we can, for example, calculate the average price of the order after it’s been fully filled.
linked_orders field is necessary for encoding the information about linked orders for OCO and OSO.

To enlarge the system without changing exchange_order record, let’s add opts field which is a dynamic dictionary.

Interim conclusion

To be honest, I thought that the second part of the series would be more compact. However, I had to be more detailed to elaborate on the topic.
The theoretical part of the following article will shed the light on order book and the rules of order processing. The technical part will deal with the scheme of market data processing and issues of historical data storage.

Thanks to Nadezda Popova for proofreading.

Vonmo Trade Experiment. Part 1: Exchanges and modern technologies

Maxim Molchanov — Sun, 05 Jan 2020 17:37:52 +0000

This series of articles describes an attempt to create a reactive system performed by one person, with a minimum budget and in the shortest time possible.

The experiment aims at:

A deeper understanding of the subject and improvement of technical expertise;
Identifying strengths and weaknesses of functional languages and open source projects in trading systems development.

This article presents the motivational part and task decomposition.

I was planning to start this experiment in spring 2019, but then – life happened – and I had to reschedule. That is why here are my apologies to all those few followers of mine who have been waiting for the articles on this topic.

What brought me here?

When I realized that I’d got tired of day-to-day project routine, I wanted to create something unusual. I was thinking of various topics and directions which looked challenging enough for me. This way, the main requirements to the project-to-be appeared:

Field of studies that I find interesting;
Distributed and high-availability nature of the app;
High information capacity and big volume of stored data, typical for data-intensive apps;
Maximum use of open source projects.

As I’ve already had some experience in developing object storages, I came up with an idea. Why don’t I write a new implementation of s3-compatible storage using erasure coding and fast hash functions? But then I wanted something even more exciting. From a developer’s point of view, financial system are interesting due to their near real-time work, huge number of updates and volume of stored data. So, I set my mind on creating my own implementation of an exchange system.

About exchanges

A stock exchange is also known as bourse (from Latin “bursa” – “purse”). In a broad sense, this is a market where sellers and buyers conduct transactions. A traded asset defines the exchange type:

commodities exchange, including labour exchange
stock exchange / market
currency exchange
futures exchange

Historically, exchanges were literally a place which, at the appointed time, brought together sellers, buyers and brokers, or middlemen, who assisted with transactions.

The main functions of any exchange are the following:

Organizing the exchange trade:
- Defining trade rules under current legislation
- Setting product standards
- Staffing and material provision
Information activity. Providing information about stock instrument prices, markets and companies;
Drawing up standard contracts;
Settlement of disputes (arbitration);
Providing certain guarantees of order execution.

Modern exchanges are well-organized trading platforms which work by certain rules and create supply and demand. Exchange economy is crystal clear: the more transactions there are on the exchange, the more fees and commissions it gets for its service.

Now when we have a general idea, let's limit tasks to do for MVP realization.

MVP

Limited resources lead to limited functionality of the prototype.However, vital and fundamental things should be fully implemented.

Task decomposition and architecture choice

Technically speaking, an exchange is a public service system where its participants generate a flow of requests – or orders. The system, in its turn, operates and executes them by the rules defined in advance. Order service must be performed with minimum waste of time. The exchange must be fault-tolerant and highly available.

Let’s divide the project into a system part and a public part. The system part enables us to manage platform components and exchange trading process. The public part includes client interfaces: Web API, Trading API, notifications subsystem. Both parts will be based on distributed apps platform which is responsible for system scalability and reliability. As we are limited in budget, we’ll opt for tested open-source solutions for data storage organization. Tarantool is used for the system hot data, PostgreSQL for the cold data.

Let’s draw the system structure:

It might seem that both the architecture and the project itself are no different from any usual system. Where is the challenge, you may ask. To answer, let’s take a look at the process of creating orders and filling orders for a currency exchange.

Creating an order

Checking authorisation
Making sure that a user can now afford to place an order
Creating an order
Informing the user on success of the operation or failure

Filling an order

Finding a match
Checking fund sufficiency for both parties of the deal
Making the deal: money transfer between accounts + exchange fee transfer to the exchange commission account
Saving the history of order execution
Updating the information data: raw data and aggregated data for graphs
Notifying all parties concerned about the deal.

The trouble starts when we move from a monolith, working on a single machine, to a distributed fault-tolerant system deployed on a cluster. I think, the minimum performance level should make about 5-7k RPS completed transactions per market. This puts extra limitations on architecture and work with data.

Following the KISS principle, each app must perform only the functions which are necessary for processing the entity implemented in it: market, account, authorization etc.

VonmoTrade is based on horizontal scalability principle. Each application could have many instances to provide fault-tolerance and required performance level.

Technology stack

To avoid generating entropy, let’s limit the languages and approaches used.
For server, this set will include:

Erlang. To my mind, a perfect language to deal with infrastructure things.
Rust. Excellent for system-related things and optimization issues.
PostgreSQL. Serves as the main base for long-term data storage.
Tarantool. Serves as hot data storage (for MVP only)
Clickhouse. For logs analysis and deep analytics.
Linux. The system must support modern distributions.

The client software is implemented with the help of Vue framework and Vuex.

As the project presupposes a big number of components, we will write a lot of property-based tests and integrative tests to ensure an adequate level of quality of the final solution.

Plans

In foreseeable future I’m planning to review the basics of the theory and delve into practice in the following directions:

Orders. Types, processing features, aspects of trade information storing.
Order book. Visual representation of the market.
Bidding history. Prints, graphs, personal history.

As they say... Like, Share, Subscribe :))

Thanks to Nadezda Popova for proofreading.