Technologies Screening -II-


In my last post I introduced how I identified possible technologies and learned the basics about different languages, operating systems and IDE’s. I also mentioned that my choice was to build on top of .Net’s C# and Visual Studio, as my base for developing. In this post I want to dig a little deeper into the overall tool chain for my trading system development.

When I was starting to work with different IDE’s it was surprising about the different concepts each IDE have to do the same thing. In general they are designed to do almost the same, but each of them is streamlined to a special group of audience. But at least its a question about personal taste and what the developer is used to.

More important seems to be having a good concept about how to achieve the goals. In my case I had to define these goals first. At the beginning it was quite diffuse and more a guess like:

  • I want to stream market data into charts for visual assessment. Also I want to stream market data into trading strategies and let the trading logic execute trades automatically.
  • Also I want to steam market data into a backtest environment.
  • This leads to think about streaming market data into a database to store them.
  • All the nice trading strategies need to be designed and scripted.

Using this guesses to start development, it would be hard to keep the overview. All this guesses need to be ordered and separated by defined entities. This makes it easier to select a technology for each defined entity, which works for me. So here we have a raw list of entity for more detailed discussion:

  • Market Data Adapter
  • Database
  • Trading Strategies Implementation
  • Charts
  • Order Management System
  • Risk Management System
  • User Interface

+ Market Data Adapter: There are different ways how to stream market data into the code. This strongly depends on the data provider which could be just a market data provider, a broker or a exchange. From what I learned there are 2 global species available:

1. Binary API, which may be a executable or library to call from your application. The executable opens a socket to connect with your code. This don’t allows to connect to data vendors servers directly. You will need to go always through their client only.

2. Source Sode API, also contains two sub categories. Some data vendors use proprietary API and others provide connections through the industry standard FIX protocol for their transactions.

The proprietary API could be available in a specific programming language like Java or sometimes other languages too the messaging/serialization is mostly JSON or XML based, sometimes you find binary protocols like  Google’s Protobuf. Using FIX (Financial Information Exchange) is compliant to a standard for the financial industry more about FIX specs. In a later Blog  when it comes to datafeed implementation, we dive deeper into source code API’s.

For me it becomes clear that source code API’s are the only way to go. If I take the effort to develop my own trading platform, I don’t wat to add any black box. So I was looking for some data vendor, broker or exchange with adequate source code API.

As a starting point I was creating a simple local simulated datafeed which delivers random numbers in a defined range. This is a great way to simply test your code against. Later I added a C# API from a exchange to test my code under real conditions, on a demo account with all the hassles. In a later blog I will discuss it more in detail including my experience but source code samples too.

+ Data Base: When I was starting I wasn’t aware that I need a database. But during my journey through all the techs and looking how others doing all the stuff, I learned the advantages about using a database. Another way would be just to store everything in flat files, but this will grow more and more. Let say the starting point is just saving some OHLC data to get them later for backtest and charting. But maybe one day you come to the point where you need tick by tick data, account states, order history and maybe market depth information too. If you think this end to end with flat files than you will end up do all the things manually which is already automated by using a database. So I was starting to have look was fits for my needs.

Soon I realized that databases is a field on its own and after getting a common understanding about what differs the types (relational/non relational, SQL/NoSQL, InMemory, ….), I went two steps back and ask my self “What would be the best to start as a noob?”. The answer was quite simple cause I want to stick with .Net and Visual Studio. So to start with “the SQL and LINQ convenience” was answering my question. Later if I see the need, it would be possible to change the database with minor modifications in existing code.

 If don’t want to stick with SQL for any reason I would advise you to have a look to some other open source techs who are quite interesting. For instance Redis is worth a deeper look. It could solve the database problem and some others like messaging architecture in one move. Other DB’s are worth a look are this:


+ Trading Strategies: To answer the question “What would be the best to implement trading strategies?” was not a easy task for me and its still a quest. There are different needs like performance, flexibility and development speed to consider. Unfortunately sits not possible to cover all of them in one usercode concept. For instance its hard to combine nice and easy debug features of a interpreter based script language like Python or Matlab with the performance of C++. Managed languages like Java and C# are in between. Due to I’m with C# for the overall development I decided to have a C# usercode library first. As a editor I can use Visual Studio so I have the full power and convenience of the .Net world. Also there is a huge community related to financial engineering. Later I could imagine to extend it with Python for prototyping and convert the Python code into a managed .Net library. And due to the nice fact there is native Python support in Visual Studio I’m able to keep everything in Visual Studio! Another aspect is to work with dll’s in trading strategies. Many languages or IDS’s have inbuilt conversion capability to translate the code into managed or native libraries. This dll’s can be called from trading strategies.


+ Charts: There are some great commercial chart libraries out there. But in my case I don’t want to use them. It makes no sens to me to use commercial libraries containing Blackboxes. So I would use the native features which comes with .Net or use open source libraries. So there are some I would give a try:


+ Order Management System (OMS): It was clear that I keep this in C# from start. Later if I would see any need, I could port it to C++ or what ever…

+ Risk Management System: Same here – I keep it in C# until I see any reason to change it.

+ User Interface: This is the only entity were I was forced to use closed source but free library, due to I don’t wan’t to code all the docking and controls by my self. When I would look back, it was a good move to use “Extended WPF Toolkit” cause its still maintained and quite active developed. From my point of view I don’t miss anything.


This was the 2nd part of my short tech-screening. If you have suggestions about other libraries or something else I missed, I would be happy if you let me know! In my next post I wan’t to do some brainstorming how to get all the entities together. This step was taking much more time I had expected and was finally set just some month ago. The Architecture Approach of the trading platform… 





Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s