Author: Elina Pedersen - Chief Revenue Officer, Your Bourse
Almost any execution technology or “bridge” provider on the market will always have a story of how amazing, great and unique their offer or technology is. Unfortunately, very often smaller to medium size brokers do not have the resources and the knowledge to really “vet” the tech and the technology provider inside out.
In this article, I will share the main questions that you need to ask your execution technology provider when you are making a choice - be it MT4 Bridge, MT5 Gateway or Trade Execution Engine (aggregator or a matching engine).
What is the architecture of the Trade Execution system?
Let’s start with the basics. No matter the technological solution the system will be written in, a specific programming language and the language – matters. Different programming languages have their pros and cons. For example, some languages have excessive libraries to simplify the programming process and speed up the development process. These include Java, C# and more. Nonetheless, this simplicity very often comes at a cost. If we are talking about Java in particular, which is very often used for programming in the FX and CFD’s industry, the low-level code optimisation will always suffer allowing a lot less processing power than for example with C++ or C.
It’s important to note that both MetaTrader 4 and MetaTrader 5 are written in C++, therefore the plugins or any apps for those trading platforms should be written in C++. Some technology providers create plugins in C# language and this might negatively influence the processing speed of the technology. Also, there is no control over how much memory the .Net framework will utilise and this becomes a critical factor for the MT4 server (the .Net framework can allocate all the memory on highly utilised servers and cause MT4 to crash). It is to note that the MT4 server will print a warning if any plugins in C# are activated on the server.
MetaTrader 4 Bridge and MetaTrader 5 Gateway plug-in architecture:
Another important question to ask your Bridge or Gateway provider is regarding the API used to connect to the MT4 and MT5 trade platforms. Both MetaTrader 4 and MetaTrader 5 have two types of APIs created for different uses and purposes. The first one is called a Manager API and the second one is called a Server API.
The main difference between the Manager API and the Server API is that the Manager API is a stand-alone dynamic library used in a separate application. While the Server API is a plug-in integrated into the server process directly. Therefore, using Manager API creates additional points of failure and increases market data/order processing time. This is a poor architectural choice for a performance-critical component such as MT4 Bridge or MT5 Gateway.
In conclusion, if your technology provider is using the Manager API for the bride or gateway they are increasing latency because to execute trades, the Manager API has to subscribe to pricing before it can perform any actions. Therefore, if the broker has a large number of symbols the traffic passing through the Manager API will be huge and the latency will increase due to the need to subscribe to each one of them. Some price updates might be dropped (especially in volatile markets) because backpressure on the connection where the connection might even drop, resulting in a small downtime.
On the other hand, using the Server API is straightforward and does not require any additional applications to be installed outside of the server. Most importantly using Server API for order insertion and processing is in the MetaQuotes’s guidelines for the developers. Usually, inability to follow those guidelines may potentially indicate other flows in software architecture - in general the MetaTrader 4 and MetaTrader 5 development guidance are crystal clear.
Self-hosted vs. Independently hosted solution?
We’ve discussed the architecture of the technology and that the coding language, as well as the development logic, are very important for the smooth performance of technology. Let’s assume that you are happy with the tech and satisfied with its architecture and processing power. The next step to consider would be the hosting of the solution.
In general, there are two options available. Hosted solutions and self-hosted solutions. In the first case, the technology company would usually cover all the infrastructure associated costs, including support and maintenance associated with hosting the solution. In the second case the solution would be hosted by the broker directly on the hardware belonging to or rented by the broker.
There are pros and cons to both options. The hosted solution is usually much cheaper for the broker as it’s included in the monthly bill for the chosen technology, while a self-hosted solution allows for full control over the broker’s infrastructure. Some larger brokers have internal procedures, which require them to host everything in-house, while smaller brokers would prefer to outsource the whole infrastructure, as they do not have their own racks in the data centres.
Regardless of the preference, the technology provider should always be able to provide two options: hosted by the technology provider and a self-hosted solution. If the technology provider asks the client to host the solution on the clients’ servers, it’s always a good idea to ask the direct question: why? Mainly because this indicates a hidden cost. Perhaps, the technology is heavy and requires powerful and expensive servers to operate; therefore, the technology provider prefers to simply divert the cost to the client.
As a rule of thumb, a well-written, agile and scalable technology must be cheap to run and its operation should not require expensive hardware.
Trade Execution Technology as a “Hub” vs. “Stand-alone” platform:
The “Hub” mentality appeared in the industry a few years back when the main technology providers started offering volume fees discounts on the trade volumes executed within the “hub” or the provider’s internal ecosystem.
However does the “ecosystem” really exist from a technological point of view?
In truth, very often the ecosystem will only be “commercial” and not technological. The “technological” ecosystem might attract some serious issues from the security and business continuity point of view, so let’s dive deeper into this matter.
When it comes to a real technological ecosystem the provider would often refer to the hardware used for hosting the solution. The provider may mention that by hosting several brokers on one server, they are minimising the latency between the brokers who are looking to manage their liquidity. In truth, being hosted on one server together with other brokers hold a serious security risk. The simplest threat is human error. For example, during routine maintenance, an employee makes a mistake, and the server goes offline - all brokers hosted on that machine are affected.
Another serious threat is the potential DDoS attack on one of the “neighbour” brokers. Of course, the clients have no way of knowing who they are co-hosted with and no way of vetting the company’s client base. In a nutshell, if one broker is attacked, everyone is attacked.
Now let’s speak about the “commercial” ecosystem or ultimately a discount on volume fees. Some technology providers will try to motivate brokers to use liquidity providers within their “ecosystem” at times charging the brokers extra if they would like to use someone outside of the “ecosystem” justifying it with “hub to hub” connections and providing other reasons to charge extra for LP’s that do not use their solution.
From the technological standpoint of view, especially if we are talking about the FX and CFDs or as a matter of fact about the financial markets, we are looking at a hand full of data centres around the globe – mainly, Equinix. Most hosting providers within those data centres allow “cross-connect” between the servers and the data centres if they are in close proximity. Hence, from the technological point of view, there is very little explanation as to why “hub to hub” within the same tech provider should be “easier” compared to a FIX API connection between the two technological providers and critical a cross-connect within one data centre.
Therefore, if your technology provider is referring to “ecosystem” related discounts it’s always good to check where the discounts are coming from. In an ideal and fair world the technology provider should do its best to help the broker grow. Which LPs to work with is essentially a business decision. It should not be affected by the choice of a technology provider, especially if those savings are artificially invented by the technology provider to force clients into dependency.
Why choosing the technology provider with the correct architecture is essential for the successful operation of a broker’s business?
For the FX and CFD’s professionals outside of the software development space all bridges may seem the same and may only vary based on the end functionality and the cost structure, however there is actually a lot more to consider than just the monthly bill.
The programming language, the architecture of the solution, the performance and the scalability all play a very important role in the day-to-day operations of the broker. There is no point in having a shiny risk management dashboard if the solution is using a Manager API and delays in order execution result in latency arbitrage and direct losses to the broker.
It’s similar to having a car with a Ferrari bodywork but with an engine of a lawnmower. There is no point in choosing a solution that has the best cost structure at first glance but requires the broker to host it on machines that will cost the client twice the amount of money than the solution itself.
At Your Bourse, we build an elegant human-friendly and most importantly, fault-tolerant solution within the rapidly growing financial environment. Our mission is to help financial firms succeed in the challenging financial industry. We strive for perfection in everything we touch starting from point zero.
For example, Your Bourse matching engine is written in C++ with some parts of it written in C allowing it to process more than 500’000 order events per second on 1 CPU. The system is fully scalable and by adding more CPUs we are able to increase the processing power proportionally. There is no other matching engine in the financial industry that can deliver this speed of order processing.
Recently, Your Bourse has been rewarded with the “Best Technology Provider” by the Ultimate Fintech Awards 2022. This reflects our commitment to providing a cost-effective yet bulletproof technology. No matter if it’s the bridge, the matching engine or business analytics - we achieve perfection in everything we do and we will continue developing the best solution to help our clients’ business succeed.
About the author:
Elina Pedersen is a Co-CEO and a member of the Board of Your Bourse, an award winning FinTech provider of order execution and multi-asset connectivity for MT4/MT5 and Crypto brokers. Elina is a firm believer that when there is will there is way. At Your Bourse Elina’s main goal is to help the firm's clients grow in volume and revenue through the use and customisation of Your Bourse order matching technology, risk management and reporting tools. Elina holds an EMBA degree and has over a decade of senior management and executive role experience in retail/institutional brokerage including marketing, operations, regulation and strategy. Elina’s past roles include Global CMO of Admiral Markets Group and CEO of Admiral Markets UK (Admirals).
