Stock Trading Signals Platform

Project challenges

1. Selecting the best Market Data Provider

We needed to select a data vendor that would fit the solution, with respect to both the technical (e.g., WebSocket, real-time data, latency) and business (any stock trades) requirements. There are multiple data providers on the market and they can be divided into two groups:

• The first group is made up of official vendors (~70) of real-time stock market data. These vendors must comply with exchange regulations; as such, supporting their products and using their services requires you to sign an additional agreement with CTA (Consolidated Tape Association) or UTP (Unlisted Trading Privileges) companies. Consequently, these tend to be very expensive, costing up to $10,000 per month.
• The second group comprises third-party providers that can offer almost the same services as the official providers for a lower price, with the tradeoff of some additional limitations in data format and connectivity.

Our team conducted research and made comparisons between the available market data providers, examining factors including data quality, fees, latency, and connectivity options. The results from our analysis and our recommendation were shared with the client for final decision making. 

As a result, Finage was chosen as the data provider that best matched the client’s needs, due to the following factors:

• delivery of real-time market data via a WebSocket protocol
• availability of historical data
• acceptable latency
• reasonable fees
  

2. Real-time data quality

In order to correctly determine all technical/economic indicators and trading signals, it is key to be able to accurately calculate OHLC prices for 24 secs/1 min/4 mins/5 mins time period bars.

If one were to implement OHLC calculations on raw data using only mathematical formulas, and then cross-check their values with Yahoo Finance, they would see a significant difference.

The problem is, some data providers (including Finage) will sometimes supply raw data that must be pre-processed in a specific way before OHLC calculations can be performed. Raw data must be adjusted to account for factors such as sales conditions and volume. For this project, pre-processing was performed in full accordance with Consolidated Tape Association (CTA) and Unlisted Trading Privileges (UTP) specifications to ensure the accuracy of calculations.

3. Latency

One of the client’s main requirements was that the solution should have very low latency so that traders could see changes in indicators reflected within milliseconds following the occurrence of a related market event.

To achieve this, our team developed a multi-layered architecture with advanced caching and multi-threaded calculations, in order to fully utilize multi-core and multi-processor server instances.

We split indicators and signal calculations between the backend and frontend components. Performing some of the calculations on the client side allowed us to significantly reduce the server load and increase performance.

Technical solution highlights

The client part of the solution was implemented as a resizable Windows desktop application using the Blazor solution. The resizing feature was very important, as traders usually have many programs open on their desktops and space availability is a critical issue. Blazor was chosen because it is one of the best technologies for web developers on the .NET stack, allowing client/server-side web and desktop & mobile applications to be developed entirely in C#.

Using the same technology to develop the web and desktop parts also allowed us to reduce the cost of the product.

Multiple instances of the client application can be run on the same PC. This allows users to run as many instances as needed to track information about the most traded stocks during the current market session.

The architecture of the system is defined by very high performance requirements. Trading opportunities can appear and disappear in a fraction of a second. Therefore, the system must process massive volumes of data simultaneously to respond to market events in real time.

Here you can see the diagram of the backend architecture:

1. Technology stack and components

Microsoft .NET, C#, Microsoft Azure, and SQL Server were selected as a mature, well-supported, enterprise-grade technology stack.

React.js, SignalR, and Blazor were chosen to implement the system’s rich, real-time interfaces.

2. Horizontal scalability

The system can be easily scaled by adding additional server instances.

3. Low latency data processing

To ensure quasi-real-time performance, the system uses parallel calculations in multiple threads with asynchronous queues, for event processing to fully utilize multi-core, multiprocessor server instances.