IT risks in the process of buying shares

When you, sitting at home, at 3 am suddenly decide to buy some kind of security, an international incident begins. After all, if you think about it, in fact, you give the command to take a piece of one country and move it closer to you, to Russia. And this requires a lot of clearance at the international level.

Naturally, all this is well automated for a very long time, but problems do occur. Consider specifically the IT risks in the process .
')

Plot from you to the broker

Previously, this site looked very simple. You dialed a broker’s number and said to him: “Buy apples!”. He sent down the task of yelling at the trading floor and thus buying Apple shares for you (in fact, no, Apple was not on the stock exchange then). If an attacker called him instead of you, and the broker carried out his order, this is an unconditional cant, resulting from the lack of authorization of the user (you). Accordingly, the risk was borne by the broker (his company). Another broker could hear you wrong, misunderstand, or somehow nakosorezit. It was the risk of distortion of information during transmission and the risk of the interface. In this case, court cases were repeatedly raised on the topic “I said sell, not buy.” There was even a historical period when brokers really feared that the client would “go back down” in case of an unexpected jump in the market and would start to sue over the fact that he gave completely different trading orders.

Naturally, this process required authorization, identification, and logging. All this gradually evolved to modern systems. The first electronic trading began in 1971, and in the 90s almost all the exchanges switched to exclusively electronic methods. Of the major sites, the Tokyo Stock Exchange was holding the longest: last shouts sounded there in 1999.

Today, all this is done, as a rule, through the application that you install on your computer. The broker itself (the company that has the right and opportunity to engage in such transactions for you) does not consciously participate in the process: you say buy, robots buy, immediately processing all documents through the broker as through a proxy. It is important that the broker has the necessary permissions and assets for such transactions. That is, first the broker buys the same shares as a member of the exchange market, and then transfers them to you.

Problems may be in the exchange of the client program and the trading platform. Basic risk is terminal infection and transaction compromise or substitution. As a rule, it is quite rare.

The second risk is incorrect perception of the signal by the trading platform . This is when you decide to buy shares of Google, and as a result you bought shares of the Ural Carriage Works. And not two, but a controlling stake.

Naturally, such bugs are quite rare. The most popular trading system in Russia is licking like an airplane for about twenty years. And this decision is used as a platform by almost all market players. When a problem arises, almost everyone will know about it almost instantly, therefore, pah-pah, in recent years there have been no clear cases. For the platform itself, each bike is a reputational case, so probably few people approach the testing process as carefully as they do. We can say that these are people who do not know about the phrase EULA "We are not responsible for the loss of user data as a result of using the software." Carry, but not directly, and reputation.

The most popular system is called QUIK and is being developed in Novosibirsk. Basic functionality - provides prompt information and access to various markets and trading modes through a single terminal. There are deferred orders (“Transaction Pocket”) with batch placing into the trading system, there are conditional orders made when a certain condition occurs, import of transactions from other sources, plus programmatic input of applications by means of built-in programming languages and input of requests from the schedule is supported. On top of the basic things are hung various server modules and user applications in the field. It is user applications that create the various “zoo” of trading software that you see in different market players. An example is the same Tradematic Trader FIX trading system (designer of trading robots), which works directly with a QUIK server.

The second most common platform-level system is Transaq.

Naturally, there are risks at the level of debugging the work of robots (especially if they are “home-grown”) and at the points of integration of various software in this stack. It is also extremely rare to encounter problems with the implementation of the protocols, but in recent years I have not been able to remember such cases.

On the exchange itself

Exchange is also a fairly reliable system. Huge money is invested in job security, but falls do occur. Seldom. but they happen, and they are different on every exchange.

The system on our Moscow Exchange allowed to conduct up to 20 thousand transactions per second. The functions of trading and clearing (settlement of transactions) have historically been written right in the core since at least 2007. Sooner or later, the exchanges come to the removal of these functions into separate modules: for example, in London and New York at the moment these subsystems are already divided. This does not save from failures (they are on the NYSE, and on the NASDAQ), but allows you to reduce their scale to the size of the encapsulated module.

In the architecture with the code of trades and clearing in the core, clearing errors could lead to a halt in trades. As the few suspension of trading for two years showed, about half is related to the code, the rest is telecom and hardware (balancer failure on June 28, incorrect operation of telecom equipment on August 12, failure in M1 and “network storm” on September 8).

On September 21 of this year, after the completion of testing the new system and two-week combat exploitation, a rather unusual exchange crash happened - some players saw an “inverted glass”, that is, they swapped the purchase and sale prices. In order to fix the code, the trades were stopped for 2 hours.

In 2016, the exchange plans to launch another data center with a new architecture, which will allow cloning trading cores. In this case, in case of failures, there will be a degradation or shutdown of certain instruments (for example, only trading in precious metals), but not a general fall.

It should be noted that earlier, in 2013, the exchange code was significantly modified (on top of the kernels of 2007), because it added the functionality of switching to T + 2 settlement mode, creating a central depository, starting switching to settlements with centralized clearing in the repo segment, launching trades physical gold and DFI. At the same time there were quite a few failures, which speaks of a fairly well-established process. It’s probably quite fun to feel like a developer, whose mistake in the code can cost the country a couple of billions of dollars at a minimum.

Why about the extremely rare two-hour falls fall in the news and what it affects - in today's post on Giktayms.

Third type of risk

Another risk is when the transaction has already passed, and you do not receive your shares in the depositary. If the transaction has passed - the stock should fall to the broker and be visible to you. Accordingly, in case of bugs, it may happen that you are buying a fucking nothing (and then you need to track down transactions for correction) or that the transaction has passed, but you see the old state and cannot immediately reset futures, for example.

In order not to miss such moments, the classic broker shows the client regular reports (usually sends to the mail and duplicates in your personal account), or a special system is installed that compares the sum of all transactions with the actual result, that is, in fact, auditing accounts and checking balances on them.

How is it treated

Instant transactions are not treated in any way. That is why it is very important to have a “clean” code in production.

Deferred transactions (for example, our ETFs are considered to be T + 2, that is, within two days) can be easily counted after the failure has been fixed. Actually, this is what happens in the “slow” deals section. For example, in the event of an “inverted glass” falling, the exchange caught all transactions and canceled them before T + 2 expired. The T + 2 mode is possible with a trilateral transaction - not an instant exchange with someone, but when conducting an operation through a national clearing center, which “holds” everything up to confirmations and rechecks.

For cases of the third type of risk with an incorrect balance, it is important that the system for reconciling account balances and listening to transactions from you and you caught the mistake before the expiration of the cancellation period in T + 2 so that you can have time to deploy the transaction.

Summary

In the last post you asked why we need 5 data centers for trading ETFs in Russia, even when working in T + 2 mode, when checked by two independent organizations (London, Ireland) and through European clearing. I hope, now I have answered your question in detail. The ETF tool itself removed operational risks (tied to the human factor). We tried to minimize IT risks with our infrastructure and software. There are only market (rise or fall of the market).