10 Things that Affect the Speed of a Trading System

10 Things that Affect the Speed of a Trading System - aaeaaqaaaaaaaapaaaaajgfkyzdlztfilwzkywqtndnjzc05ntjmlwy0nmrjmdzjodrjnw

What factors affect the speed of a trading system? Here is a list of the 10 things that affect the speed of a real-time automated trading system, in no particular order.

Table of Contents

1. Programming language and efficiency of the code:

The programming language and compiler used to implement an automated trading system will affect the speed of the trading system. Some languages built on some compilers will run faster than others. Applications developed in MS Excel will suffer from serious problems, not the least of which will be the slowness of Dynamic Data Exchange (DDE) technology.

Serious automated trading systems should be developed in a more robust environment or created from scratch in code using, for example, C++, Visual Basic.NET, or C#. Traditionally, C++ has been viewed as the premier language for trading system development, although the advent of Microsoft’s .NET Framework makes Visual Basic.NET and C#.NET viable implementation languages. The efficiency of the code and the use and management of multiple threads will also affect speed. Well-written code runs fast, whereas poorly written code runs slow. Furthermore, well-written, object-oriented code will be far easier to debug and maintain.

2. Hardware specifications:

Bigger, more powerful, newer servers and client computers run faster than smaller, less powerful, older ones. Also, multiprocessor machines will be an advantage.

3. Multitasking:

I know a trader who used to run an Excel-based automated trading system on his desktop computer. On the same computer at the same time, he had several windows of his front-end trading platform open, was watching Bloomberg Television, was analyzing technical indicators in a charting package, surfing the Internet, and sending emails. Obviously, multitasking will slow down a trading system.

4. Connectivity:

Cross connection or/and T3 lines are more expensive but much faster. Also, sharing lines with other applications or other firms in the building will damage performance. One firm I talked to had only recently realized that their T1 line was for the entire floor of their building, not just their office.

5. Third-party front-end software and API:

Not all front ends are created equal; some are faster than others. Also, third-party APIs may connect directly to an exchange, whereas some may connect via the front-end trading platform; another step in the process will slow things down.

6. Clearing firm’s technology:

Do your trades go to the clearing firm’s servers first for approval? Not all clearing firms are created equal. Of course, less expensive commissions may trade off against slower speed.

7. Operating system:

Different Microsoft operating systems will show different performance. While UNIX is generally understood to be faster, it is more expensive to implement, maintain, and develop on.

8. Exchange technology:

Some exchanges are just plain faster than others. Also, exchange price servers may show different performance than fill servers.

9. Distance from the exchange:

Distance not only in terms of miles but also in the number of technological “steps” will certainly impact speed. A trader I know spent a lot of money on fast computers but failed to realize that his internet service provider was sending all his trades from Chicago to servers in Atlanta and back to the exchange in Chicago. The optimal solution is to have your trading system on a server in the office next to the exchange access point. Sending orders across the ocean slow things down. 

10. Time of day:

Finally, it’s important to understand how different times of the day can also have an impact. For example, trading at the open will be slower than at 1:00 in the afternoon. Fast markets will slow things down.

There you have it. We hope you found this article informative and useful. Feel free to browse the rest of our site to explore more articles!

Ariel Silahian

http://www.sisSoftwareFactory.com/

I help financial institutions architect high-frequency trading systems that are fast, stable, and profitable.

I have operated on both the Buy Side and Sell Side, spanning traditional asset classes and the fragmented, 24/7 world of Digital Assets.
I lead technical teams to optimize low-latency infrastructure and execution quality. I understand the friction between quantitative research and software engineering, and I know how to resolve it.

Core Competencies:
â–¬ Strategic Architecture: Aligning trading platforms with P&L objectives.
â–¬ Microstructure Analytics: Founder of VisualHFT; expert in L1/L2/LOB data visualization.
â–¬ System Governance: Establishing "Zero-Failover" protocols and compliant frameworks for regulated environments.

I am the author of the industry reference "C++ High Performance for Financial Systems".
Today, I advise leadership teams on how to turn their trading technology into a competitive advantage.

Key Expertise:
â–¬ Electronic Trading Architecture (Equities, FX, Derivatives, Crypto)
â–¬ Low Latency Strategy & C++ Optimization | .NET & C# ultra low latency environments.
â–¬ Execution Quality & Microstructure Analytics

If my profile fits what your team is working on, you can connect through the proper channel.

Leave a Reply

Your email address will not be published. Required fields are marked *