Alpha Novae

A Blog Post

Case Study: Trading Arcade setting-up its infrastructure

The case

A known trading schools plans to open a trading arcade based in Dubai.

Alongside this project, the school would like to offer to its most promising students, physically based all over the word, the ability to prove themselves in a professional and risk controlled environment, with real money.

The successful candidates will be able to join the school trading arcade and will be offered to manage increasing amount of capitals.

In order to provide capitalized accounts to its student and traders, the Arcade will set up a Proprietary Trading Group account structure (Separate Trading Limit Account type) at Interactive Brokers.


The main characteristics of this set up, managed broker side, are:

  • Master, sub accounts and users are part of the same legal entity.
  • Funds are deposited in the master account (Trading Arcade account) and transferred between the master and sub accounts to control individual trader limits.
  • Initial margining is determined for each individual account, while maintenance margining is determined at a consolidated account level.
  • Master users can set trading limits on individual sub accounts based on order size and value.

Interactive Brokers would be able to enforce some basic restrictions on margin, order size and value. But it is not sufficient to elaborate an advanced risk controlled and managed environment, at the core of the Trading Arcade. The target solution will have to control at least for each trader the maximum loss per day allowed, the maximum risk per trade, the maximum number of trades per day, etc.

Through these accounts, the traders will be active mainly on US equities, but it would be better if the solution allows trading on other asset classes too.

Below is a summary of the main requirements:

  1. The trading platform needs to connect to Interactive Brokers group accounts set-up. In particular the Proprietary Trading Group accounts structure.
  2. The trading platform must be at least compatible with US equities.
  3. The trading platform must enforce different risk limits criteria, individually set up to each trader sub account.
  4. It should not be (reasonably) possible to bypass these risk limits.
  5. Each trader will only be able to access and trade his own account. Only the administrator user will have ability to view and trade on all accounts.
  6. The solution must allow the traders to be physically based all over the world (not only on the Trading Arcade trading floor).


The solution


The solution is based on Alpha Novae‘s AlphaTrader environment, composed of one AlphaTrader Server instance and several AlphaTrader Clients. Indeed AlphaTrader is more than just a platform, it has the ambition to be a full enterprise grade environment.

More information here on AlphaTrader.

Some interesting case studies here.

alphatrader small 2.5

Req1 – The trading platform needs to connect to Interactive Brokers group accounts set-up. In particular the Proprietary Trading Group accounts structure.

AlphaTrader is already officially FIX and API certified for individual Interactive Brokers account.

IB Financial Advisor accounts (which Proprietary Trading group accounts are  just a variation) are currently being integrated. They will be officially available in Q4 2015.

It will be possible to send trades individually to the master account and to its sub accounts, and to get their balance, positions, etc.

If required by the Trading Arcade, in the future, it will also be possible to use the classical IB FA Advisor set up, facilitating portfolio management. On these accounts it is indeed possible to allocate trades from the master account into the different client sub-accounts. As the allocation is done after the global execution on Interactive Brokers Back Office, it guarantees the same execution price for all the clients and no need of “copying” trades.

AlphaTrader Server will connect to Interactive Broker servers via an institutional FIX + API connectivity for optimal stability, resilience and performance. It is advised to geographically collocate the AlphaTrader server to the Interactive Broker gateway to reduce the trading latency and communication loss. But physical location of the AlphaTrader server and network connectivity to Interactive Brokers can be discussed later. Alpha Novae can advise on this matter and take care of the set-up and support (cf Offer section).

For information, full up-to-date AlphaTrader connectivity options are available here.

 Req2 – The trading platform must be at least compatible with US equities.

AlphaTrader is a multi-asset platform allowing trading on Spot Forex, CFD, Futures, Stocks, ETF, etc. Options are not yet available but will be added in the future.

So US equities can be traded with AlphaTrader.



Req3 – The trading platform must enforce different risk limits criteria, individually set up to each trader sub account.

AlphaTrader already has  a first version of a Risk Manager module.


The Risk Manager allows to control and enforce:

  • The maximum order size.
  • The maximum position size.
  • The maximum order frequency.
  • The maximum loss or profit per day, with possibility to activate a trailing.
  • The list of instruments that can be traded.

This risk manager can be improved to add the required risk criteria (to be defined in details with the client) and to be able to run on each sub account individually. Indeed, each risk limit will have to be set individually for each trader.

Req4 – It should not be (reasonably) possible to bypass these risk limits.

This requirement is probably the most important one. Indeed there is no interest to set up a full set of risk management checks and control, if the trader can trick the system when it feels emotionally backed up against a wall. Any trader can derive into such a mental state and then can look for a back door to do what he “must” do, outside any control framework.

So the only solution is to make impossible, by design, to trick the system. Except of course by some obvious and complex malicious activity such as hacking (no system can be 100% safe).

A solution based on a plugin put on top of existing platforms cannot work. For example, let’s imagine a risk manager plugin being put on top of widespread “platform A”. The trader connects to his account using platform A. He triggers risk limits and cannot trade anymore on platform A. He however feels he has to trade for the greater good… Then he can simply either log in on a different machine where the risk manager plug in is not installed. Or he could use another platform to connect to his account and trade. Eventually he can even log in to the web interface or the platform of the broker to pass orders. Such as solution is consequently not acceptable.

The only solution is to use an integrated environment (and not just a front end platform) that will enforce these risk limits. Only AlphaTrader infrastructure can offer this.

The trader will be given a personal login and password to log in AlphaTrader Client. These identifiers are not the Interactive Brokers identifiers. So the trader will not be able to access his account through a system (platform or web interface) not being AlphaTrader. The only way for him to trade his account will be to log in AlphaTrader Client. AlphaTrader Server will recognise the user and will connect him to his account.

The orders sent by the traders will be sent from AlphaTrader Client to AlphaTrader Server running on his own server in a secure datacentre. This is where the Risk Manager module will enforce all the risk criterias and limitations to be respected. Of course the trader will not have access to the server and to the risk manager back end where these criterias will be set up. Only the administrator or the support team will have these access.

Consequently we will really be in a position to enforce the Risk Management decided by the Trading Arcade over all its traders without back doors.

 Req5 – Each trader will only be able to access and trade his own account. Only the administrator user will have ability to view and trade on all accounts.

As explained previously, the traders will log in in AlphaTrader Client and will be able to view and trade their trading account through the AlphaTrader Server routing of orders. They will not have visibility of other trader accounts.

Inside the AlphaTrader Server, a mapping will be done to match his user to an IB account as defined by the Trader Supervisor (administrator).

Only the administrator (or the support team) will be able to view all accounts and will have trading rights on them.

 Req6 – The solution must allow the traders to be physically based all over the world (not only on the Trading Arcade trading floor).

As shown in the architecture diagram below, traders will log in AlphaTrader Client running on their own desktop or laptop, which will connect to AlphaTrader server over internet.

Physical location of the users is consequently without importance.

On the other hand, the AlphaTrader Server should ideally be geo-collocated (or even better, “cross-connected”) to the Interactive Brokers servers to minimise the connection latency and information loss.

Even if the trading performed does not involve high frequency strategies, it is important not to neglect this, as basic trading reactions (“tactics” as we call them) will run on the server and not on the client stations. A very basic tactic running on the server side would be a trailing stop for example. The trailing will continue even if the client platform is closed. It will of course also be possible to run automated strategies on server side.


The Architecture


The Project

Alpha Novae team follow the latest Agile (Scrum exactly) methods in term of software engineering and product development. It means that we are in regular and frequent contact with the client and that we continuously deliver new improved versions, once every two weeks generally (iterative process), instead of only delivering one version at the end. It means for the client that:
–  he can see regularly how the project evolves, in term of delays and functionally (so no bad surprise possible at the end!).
–  he can react quickly if needed and specifications can evolve over time.
–  he can start testing or using the system earlier with main functionalities (even if everything is not here yet).

All client projects are consequently true collaborations over time rather than just a one shot and forget.

Given our method of work, it is important to agree first on the specification of an initial Minimum Viable Product which will start to “do the job” as soon as possible, and which we will then continuously improve according to the potentially evolving requirements of the client.

In term of required functional modules, we have divided this project in 5 parts:

  • Connectivity to Interactive brokers Group accounts.
  • Data connectivity.
  • AlphaTrader Client trading functionalities and interfaces.
  • Set up of risk management.
  • User and role management.

In term of development, the project consists to deliver these 5 functional areas. As a whole, the project will also integrate an UAT testing phase and a progressive deployment and go live.

The Offer

As explained previously, at Alpha Novae, our business model is based on long term collaboration with our client, rather than on one shot projects.

We consequently usually do not charge for addition of functionalities, except the ones that would be very specific to a client and only used by him. And even for these functionalities we tend to privilege onboarding them into our package of service, rather than billing for them individually.

Because this way of working is quite resource consuming (continuous improvement and reinvestment in development) and require a long term collaboration to get a return on investment, we tend to carefully and strategically select our “clients”, or partners we prefer to say. Their success will also be ours.

We provide different level of services as summarised here from the minimum one (just providing the software) to the extended one (building and making evolve the software according to the client requirement, frequent and regular catch up with the project team, supporting, maintaining and monitoring the live operations, etc). This latter option is strongly advised and has been adopted by the vast majority of our professional users.

The service package and fees are tailored to adapt to the our clients evolving needs alongside their growth over time (number of users, trading activity, criticality of applications, functionalities, investment in technology, etc), a growth we are here to Amplify!


Share on LinkedInTweet about this on TwitterShare on Facebook