Architecture -I-


In my previous post, I talked about my starting point and how to develop guesses to segregated entities.  This was a very important step but by doing this at same time I got another point on my agenda – and unfortunately it was a question not a answer… The question was about in which way I should put all the entities together? In this post I want to start covering this topic. To get a preview about upcoming topics, please have look here: Content++.

During my tech-screening I learned a lot about how the institutional tools are working. Compared to most of the retail tools it was noticeable that institutional trading platforms have segregated server client architecture. Asking my self why this is the fact I realized the advantages to do it in this way are huge. By separating the Front-End and Back-End increases the reliability of your trading strategies cause you can run them anywhere e.g. in a data center with redundancy. Also if your chart engine crashes the client app during some evaluations or backtest, you automated strategies are not affected and continue tracking everything.

But there must be a reason why most retail tools have all entities aggregated into one solution. One issue is about hassling around with two separate tools. The average Joe don’t want to care about setting up and running a server environment and another lokal client tool. Also to maintaining two code repositories is a point. Someone who is developing a trading platform as a hobby project should think about this and decide what he really needs.

There is a great resource out there, I wan’t to suggest:  Link to “Turing Finance” part one. Unfortunately I came across this to late for almost 2 years, because this would answer many of my questions without painful trail and error and rethinking over and over.

Independent from architectural concept we need to plug all the entities together so that it working properly. So lets start to list all entities again before puzzling them together:


  • Market Data Adapter
  • Order API
  • Database
  • Order Management System (OMS)
  • Risk Management System
  • User Interface
  • Charts
  • Trading Strategies (User Generated Code)

Now lets try to bring it together in a order which makes sense. So lets start with the process flow for client-only approach:


The Architecture_1.pngfirst component here is the connection to the exchange or broker. There we have the need to send requests for subscribing datafeeds or instruments from a datafeed and receiving the data stream. At the same time we want to send orders to and get some feedback whether the order was executed or not.

architecture_2.pngNow after the market datafeed and order sending is established to the outside, we need to care about internal routing of market data and order with their state. Here comes the order management system (OMS) into game to which is responsible for keeping us on track with all open positions and pending orders for all allowed order types. I decided to store all necessary order information in the data base as well as all the market data. This allows to have a flexible risk management and backtesting with tick based market data history.

architecture_3.pngThe Risk Management Engine, in my case is close coupled to the order management system for having the last look over each order is send. Also already placed pending orders and positions can be tracked by this concept with ease. This allows (re)sizing orders and positions before and after sending them. This is done by various criteria depending on asset class, portfolio structure, balance, etc.

I implement a script able risk manager to have the most flexible way to handle it. In later posts, I will dive into this very interesting topic more in detail.

architecture_4.pngUser generated code covers all indicators and trading systems or strategies scripted, to become executed during run-time of the trading platform. The input data are coming from all data adapters directly or from database.

The user code engine contains a C# code library to provide a basic set of classes and methods to grab all the needed information. This could be market data or account states to evaluate and to be used in calculations.

Orders can be send which are routed by OMS and analyzed “pre-trade” and monitored “post-trade” by risk management engine.



Last we need to integrate Charts and User Interface entity into our process. After a closer look its getting clear that Charts can be handled as a part of User Interface.

A chart can subscribe an instrument via market data adapter or get historical data from database too. The main goal for UI lets the user manually interact with the markets. The UI displays data from OMS let the user monitoring current state of pending orders and positions.

All the received order and position states can be calculated and displayed in the way the user needs it.


That was my concept for a client-only trading platform I had realized as a concept after breaking all the tasks down and connect the entities in way it makes sense for me. I started to realize it step by step in a similar way as I described here bottom-up beginning with market data adapter and exchange API.

During doing this I was become fascinated by the possibilities of an segregated server – client approach. The main problem client only approach have is the reliability when it comes to autonomous trading. You will always keep the whole client running stable with all the UI stuff. A bug in the UI framework could crash the trading platform in a time where you need it up and running and monitoring your positions. After each crash during market time you are face to face with the risk of data loss and the problem of re-initialization of you strategies.

This becomes more an issue in combination of autonomous trading with collocation. In this scenario you would avoid anything which adds latency and the risk of failure. But running you trading platform in a data center on redundant hardware is a nice feature lets you sleep at night. If you need some manual interaction or monitoring you just connect you client to your server app. When you close the client, your server keeps running. When your client crash during data evaluation, your server keeps running. This is a serious point and more and more I was thinking about how to realize a server-client based trading platform. If you want some great read until my next blog, I highly recommend the 2nd part of the blog I already mentioned:  Link to “Turin Finance” part two.

In this post I talked about how to connect all the entities to achieve an client only architecture. This is how many retail trading platforms are working. In my upcoming post I want to cover the server-client based concept. This will be the base for my further talk and we are getting closer to discuss some source code examples. If you have some comments don’t hesitate to contact me. To get a preview about upcoming topics, please have look here: Content++.



One thought on “Architecture -I-

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 )

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