Vontobel's SOR Infrastructure

Today, the European exchange landscape is fragmented more than ever. MiFID II, post-Brexit, and the nonequivalence of the Swiss exchanges are some of the factors behind this. As a response to this new situation, we have developed our own smart order router (SOR) over the last three years, which clearly positions us at the top of the Swiss market and puts us on the same level as global brokers and Tier-1 banks in Europe.

01010011 01001111 01010010 – this binary ASCII code represents the word “SOR” in the digitized world. Although the ASCII code standard is now more than 50 years old, it is still successfully used in our IT systems. In the Trading Product Development department, we connect the real world with the digital one, leveraging available tools and systems, or building them ourselves if it is economically justified. In order for us to successfully develop systems in the trading domain, we need to understand how the real world can be mapped onto the digital one. Therefore, we require specialists such as software engineers, quants, and IT solution architects who are able to transform analog business procedures into formalized digital processes.

When I talk with the traders from the Electronic Sales Trading team, they often joke that I am able to process data in this type of binary form in my brain. I can assure you that this is not the case. However, today it is almost impossible to work in an industry that digitalization has not yet disrupted. In cash equities, electronic trading was introduced more than 25 years ago. Since the start, the systems involved have been continuously improved, refined, and adapted to ever-changing conditions. In this article, you can read more about what we have done over the past few years to stay on the cutting edge of the electronic trading space. 01000111 01001100 01001000 01000110.

Creating a magic moment

When you look back on your career, you will remember the best boss you had, the best team you were on, and the best project you worked on. All of those memories will change over time as you make new memories. The more you experience, the more you will have to compare these memories to.

I wanted the project to build our own SOR infrastructure to serve as all of these things for everyone who worked on the project. If I was only able to form the best team that any of the participants had worked on, then that would have been a great success. I can only speak for myself, but for me, it has been one of the best projects I have worked on and definitely the best team I have been a part of!

The story starts in autumn 2019. At that time, we had been using SOR solutions. All of them came with pros and cons. With our latest software license, the biggest con was an inflexible software improvement process, which came with a very special piece of software that is only licensed by a handful of clients. We lacked the flexibility we needed to react to all of our clients’ wishes. In addition, the product had come to the end of its life span, and we were looking at alternatives.

In addition to a replacement, one alternative we looked into was the decision to make our own. We carefully considered this option and then drew up a promising business plan that covered all of the details, including charts that pointed to the first quadrant in terms of cost and performance.

In the end, the decision to make or buy came down to a proof of concept that showed us that we have the right tech and experience to do this in-house. With the amazing engineers from our team, including Tobias Moser, Cyril Hottinger, Evangelos Papakonstantis, and everyone else who was involved in the project, we could see a PoC working in just a few weeks. With design patterns like the finite-state machine (FSM) and the actor programming model implemented by the Akka framework, we were able to use the right abstraction layers to build our version of an SOR infrastructure on top of this foundation.

Once we had the proof of concept, we had everything we needed to carry out a realistic estimation, and, together with the business plan, we pitched our senior management on the “make” option. They accepted our pitch in January 2020, and so we had to deliver.

Chart 1: Life-Cycle-Management of a PULS child order

After 15 months of very hard work, many releases, hundreds of unit tests, endless sleepless nights, and plenty of blood, sweat, and tears, the SOR went live and operational. We needed a name for it, and an internal team poll found it. Our new SOR is called PULS because it functions at the heart of our equity execution management system. By May 2021, all of the existing SOR profiles – these are strategies for how to trade on the markets – had been built. Even better, all the profiles we always wanted to build, but were unable to due to a lack of flexibility, had been built as well. This means we went live not with a product that merely replaced the existing one, but with an even better version of what we had before.

But the story does not end there. Since May 2021, we have taken the opportunity to build even more on top of the PULS infrastructure, which turned out to be the next-level framework we always wanted to have. In the past year, we have created special profiles to not only trade equities but also structured products, ETFs, and fixed-income products on European cash equity markets.

Looking back now on the whole initiative, I can say that we created more than just one magic moment – we created many of them. For me, the most important aspect is the fact that our team has been able to build and maintain higher-quality cutting-edge technology than an existing software provider. It is fair to say that it has been easier to build software that fits 100 percent of our specific requirements than it is to build a full-fledged software product that can be adopted by many clients who all have different requirements.

The best thing about our new situation – now that PULS is live – is that we now have a tool that meets all of our needs, its intellectual property belongs to Vontobel, and we have it under our full control. We can decide what will be the next improvement or the next bug fix. We are now in the driver’s seat of our SOR infrastructure.

Why did we build our own SOR infrastructure?

The smart order router is the piece of software that makes the final decision on which market is best to trade on at what time. On European cash equity markets, this corresponds to the heart of the execution platform. Vontobel has licensed various smart order router software in the past, but has never been fully satisfied with the results. For this reason, at some point, we reached the point where we made the decision to bring our smart order router infrastructure under our full control. This means we developed the software by ourselves in the Trading Product Development department, and we built up a corresponding IT architecture to operate the SOR.

One of the main reasons for us to build our own infrastructure was all of the small details that we were unable to control in the software products that we had licensed, either because the software did not support it, the concept did not fit, or it simply did not work anymore because the market conditions had changed. One concrete example is the dynamic adjustment of network latencies. The network topology can change at any time – for example, an excavator can cut a fiber optic cable that we use to send our messages from our data center to another one at any moment. If you think this is an improbable example, you might be wrong. It can occur a few times a year. With the existing product, latency adjustment was only possible with millisecond precision, which is no longer sufficient in reality. Nowadays, we have to be able to scale down to microseconds. Today, we are able to react in such a scenario down to the microsecond level. Our SOR is able to add the least necessary artificial delay to the child order, so that all the child orders arrive simultaneously at marketplaces where we want to trade in parallel.

To demonstrate the best execution to our clients, we have created a database to store every event created in the decision tree of the lifecycle of the full trading process. With our Trading Analytics Platform™, we measure the SOR KPIs and continue to improve prices and fees where we can.

Did we use AI, blockchain, or polyglot cloud infrastructure to build PULS?

The simple answer is no. We used plain old Java technology coupled with the Linux operating system. Everything ran on purely physical, nonvirtualized hardware, which are referred to as bare-metal servers. The software design concepts on which we were building, like the finite-state machine or the Actor programming model, are from the 1970s or even older. We see these concepts as universal, and they have proven to be bulletproof software concepts in recent decades.

We need bulletproof concepts in order to build something that has to be fully reliable at all times. The most important thing is to have deterministic software concepts that we can understand and control. By definition, a deterministic system is a system in which no randomness is involved in the development of future states of the system. This needed to be our foundation.

To come back to the original question, for me, it is very difficult to separate AI from randomness. In fact, I cannot differentiate one from the other. Determinism is the opposite of randomness, and so, in some ways, it is also the opposite of AI. We believe that simplicity is the key to success in our business. It was extremely important for us to be able to follow a fully auditable trail on every decision in the system. Any form of nondeterminism would make it impossible to prove the best execution after finishing a trading strategy.

With such a solid foundation, the next step in our philosophy is to build our business in a data-driven way. It is important to have access to the relevant data and be able to make use of it. If you come up with a hypothesis in any sort of algorithmic trading strategy, you need to make sure you are able to test this hypothesis on the right data. Nowadays, everyone does back testing, but it is even more important to test the results from the production environment and validate your initial hypothesis.

When we built PULS, we did not need any buzzwords. Instead, we relied on a solid software engineering process, bulletproof software concepts, and – most importantly – the right people and enough time to bring everything together.

What needs to be considered during implementation?

•  Regulatory factors like legislation and regulatory requirements
  
  • EU MiFID II
  • Swiss FinfraG, FinfraV, FINIG, and, above all, FINMA Circular 2013/8 “Market conduct rules”
  • UK pre-/post-Brexit
  • Swiss exchange equivalence
  • Trade and transaction reporting
• Topological factors, such as the difference in time zones between Central Europe and the UK, within Europe come with all sorts of problems to solve. While the MTFs are mainly located in London, Amsterdam, or Paris, matching engines are still physically operated out of London. The regulated markets are located physically and operated across several cities in different countries, such as Zurich, Frankfurt, Stockholm, London, and Bergamo. Connectivity to the relevant data centers is a key component for an SOR. In some cases, co-location in the respective data centers is required in order to be as near as possible to the corresponding exchanges. Otherwise, you will need to be aware of the latency topology of the network backbone of the major connectivity players in Europe.
• Liquidity sources: All sorts of different liquidity pools, such as regulated markets and MTFs (mainly representing the lit, dark, and periodic auction venues), systematic internalisers, and RFQ platforms. Every liquidity source has its own justification. Some have come into regulatory existence through MiFID II, others are the backbone of the European stock market. In addition, innovation in this area is unstoppable, and today we can react quickly and efficiently to any market adjustment or innovation.
• Specific venue functionality: Different order types per venue, such as iceberg orders, limit-plus orders, or the ability to sweep an order through different order book types. Different orders have different validities, such as immediate-or-cancel orders, fill-or-kill orders, day orders, or good-till date orders. Sometimes, even very common things like an opening or closing auction behave differently between the venues.
• Data processing and scalability: We need to feed all sorts of data into the system. From the referential data of traded instruments to the real-time level-2 market data of all tradable markets, all the way to the client information and additional metadata that is important for the SOR to get the context of the child order. All this data needs to be streamed and available in real time, and it needs to be accessible in a deterministic way for every strategy running in parallel.
• Auditable decision processes: To be able to prove the best execution after every execution we carry out, we store every market data snapshot we can see on the market in a special database. Even market data that does not lead to an execution is important for us and needs to be stored so that we can see afterwards why we did not execute.
• Trading analytics: We have to have a separate system validating and measuring our achieved performance in the SOR. For this, we need an independent benchmark provider to benchmark every single trade from our SOR. All benchmarked trades aggregated together will show the performance of the SOR and will make it measurable on the general level. This is a must in order for us to always be on top of things and to monitor the SOR properly.
• Trading strategies: The core of every SOR is the available trading strategies. This is why we build the infrastructure and where we can differentiate ourselves from our peer group. More about the available trading strategies will follow.

What does our smart order router (SOR) infrastructure include?

With our SOR infrastructure, we manage the cash equity markets of the European exchanges. The clear focus is on the Swiss equity market, with SIX Swiss Exchange as the primary market, and Aquis, Cboe Bats, Cboe Chi-X, and Turquoise as the MTFs. Furthermore, we have a connection to all relevant European SIs and dark pools.

We are a member of the Deutsche Börse (Xetra), the Euronext Franchise (Paris, Amsterdam, Brussels, and Lisbon), and Nasdaq OMX (Stockholm, Copenhagen, and Helsinki). Our SOR has different strategies that can be executed for an instrument on the markets.

Primary Only

As the name suggests, this strategy only trades on the primary market and guarantees that we integrate the market according to the rules. The market-specific phases are handled internally. This includes auctions, stop trading, and special order types for the market, such as iceberg orders or the Limit Plus and Iceberg Plus.

Best Price

The “Best Price” strategy only trades according to the best price that can theoretically be achieved. Here, the costs that arise in the trade are completely ignored.

Best Net Average Price

The “Best Net Average Price” maps the fee structures of the respective markets in the trading process and tries to achieve an optimum from the combination of the price achieved and the fees incurred. The exchange fees are not always clearly determinable pretrade, since an order is never really guaranteed in the execution. Thus, this is a nonlinear problem, which we try to solve here.

Hybrid Markets

In the “Hybrid Markets” strategy, markets are combined via direct market connections and connections via a third party or a broker. From this combination, we can access the existing exchange memberships at the MTFs and SIs so that we can use them for primary markets where we do not have a direct membership. Today, we trade equities on the London Stock Exchange (LSE) and Borsa Milano using this strategy. The primary markets are connected via our broker network.

Price Validation Model

SIX Swiss Exchange introduced a new “Price Validation Model” in its XQMH Segment in 2020. It is primarily used for structured products that are operated in a so-called quote-driven market (QDM). We have developed a specific SOR strategy for the price validation phase in this segment so that we can handle market orders cleanly.

Rebound

ETF and fixed-income trading with an SOR infrastructure. The “Rebound” strategy was developed for the operation of automated RFQ platforms. Today, we serve Tradeweb, MarketAxess, Bloomberg MTF, SIX QuoteOnDemand, and Xetra EnLight, and we see a great deal of potential in his area. Why did we develop a special strategy for the emerging RFQ-based platforms and exchanges? The reason is the time component. In an RFQ process, an order is never placed in a single place. The order is sent around in the form of an indication of interest (IOI) with a timeout. This kind of process may result in immediate or delayed execution. When the timeout expires, the process is usually terminated with a cancel message. Each RFQ platform has its own way of implementing the RFQ process. We have recognized that it is necessary to standardize this process as much as possible and to handle it via a controlled trading strategy. From the outside of our SOR infrastructure, the strategy can be seen as a standard marketplace. The order is sent to the “Rebound” strategy and will either be executed or expire at the end of the validity of the order. All the heavy lifting and the recurring processes to maintain the order at the right time and the right place during the execution process are carried out by the SOR strategy.

In combination with the existing RFQ platforms, there are still exchanges or brokers that can be served via traditional OMS functionality. With the “Rebound” strategy, we want to bring the new RFQ-based world together with the old exchange- and broker-oriented world. The magic word here is business process automation engine. Every exchange, every RFQ platform, every broker comes with a specific set of order types and asset-specific configurations. Until now, these systems were all handled separately by our execution traders. We believe we have found a useful combination of the different trading venues that in turn greatly simplifies execution.

The “Rebound” strategy is optimized for long-lasting executions, which are the norm in particular when it comes to very illiquid assets. In the fixed-income area, for example, it may well be that an order is placed for many days very close to the last price paid along the primary market in the order book. Keeping track of all orders placed in all order books is often difficult. Trading strategies are the ideal solution to this problem. Emotionlessly, a strategy will dedicate itself to the process of monitoring all order books and operating all RFQ platforms, and will trade the order through the best possible available liquidity.

Is PULS finished?

Yes and no.

Yes, because we have gone live with all the trading strategies described above. This means PULS has been fully operational since May 2021. Accordingly, we shut down our earlier existing SOR infrastructure in February 2022. In this sense, we are already past the point of no return. But, to be honest, we do not want to go back to where we were.

At the same time, the answer is also “no” because you are never truly finished building a product. Especially with all the things we see coming in the future. Right now, we are in the position to build the new trading strategies that we could only dream of in the past. The only limit now is our imagination.

Summary

To me, this whole journey has been one big magical moment. Having to thank all of our clients, our senior management, and the whole team for the opportunity to create memories that I will cherish for the rest of my professional career. This is why I come to work every day, and it is what keeps me doing what I am doing.