A trading platform is a program that enables the front office traders to price and book trades, the middle office professionals to manage the trade lifecycle and risk, and the back office staff to settle them. This definition contains a lot of jargon: front/middle/back offices, booking a trade, trade lifecycle, risk management, settlement etc. Don’t worry, we will go through the lingo in great detail in the subsequent posts. Some of it will become clear in this post.
First, let’s be clear about what we mean by a trading platform. It is a piece of software that answers to a set of requirements coming from the business side as well as from the software architecture perspective. From the business side, the trading platform acts like the repository of the pricing models coming from the in-house quants. Since most of these models would not be ready when the system goes live, we should be able to add models on the fly. In other words, the trading platform should be incrementally deployable. It should also have built-in sockets to receive and archive market data feeds from multiple providers. In addition to persisting the market data, the trading platform should have a database backend with a robust schema to persist the trade data. It should be able to support regular processes like daily marking-to-market of the trades, flagging fixings and cash-flow requests etc. As with all financial programs, the trading platform should be able to provide indelible audit-trails, coupled with a highly granular access control mechanism. These security and authentication features have become even more relevant in light of the high-profile rogue trader instances of last decade.
All these high-level business requirements translate to architectural choices in the program. The design of the trading platform calls for a higher level of code maintainability than is obvious in normal software engineering, because the banking field suffers from a rather large personnel attrition rate. In order to minimize the key-person risk, we should insist on detailed documentation in addition to sound development practices. The scalability requirement of a trading platform is also more stringent than is common in normal programs. The volume of trades can jump from a handful to hundreds of thousands in a matter of weeks when the system goes live. Similar to that kind of scalability is another requirement — the ability to incrementally add modules to roll out the pricing models originating from the mathematicians of the bank, which calls for a very careful design. The robustness of the system will also have to the very high even at single transaction level. We have to ensure transactional integrity (no half-booked trades, for instance), and zero downtime because, after all, time is money in the bank. The authentication and security mechanisms are to be top-notch. To top it all, the performance has to be top-notch as well. So the design of trading platform is a daunting task from a software architecture perspective.
The question is not whether a modern bank should have a trading platform. All banks do. In fact, they have multiple trading platforms. The question is not even whether they should attempt to build a trading platform in-house. Again, most modern investment banks do build their own in-house platforms. The question I want to explore here is regarding the advantages and disadvantages of doing so. And to study some of the options when it comes to deciding how deep we want to go in the endeavor of building a trading platform in-house.
The real impetus behind any endeavor in a bank, of course, is money. An in-house trading platform is essential to harness the efforts of the highly paid model quants. In its absence, their mathematical models and implementations will be a confusing mess of prototypes and spreadsheets. A well-designed quant library and a trading platform riding on it can turn them into revenue generators. If the trading platform is built in-house, it offers additional advantages of speediness to respond to transient market conditions. For these reasons, most modern banks decide to invest in at least one in-house trading platform.
Once we decide to build it in-house, we have a slew of choices. First, we can think of extending the existing commercial trading platform. We can ask our vendor to incorporate our models and thus customize the platform. But this option usually doesn’t work out well because it tends to be slow and expensive. Besides, once the modules are developed for us, the vendor might want to sell the system to our competitors as well, unless we are prepared to accept even more expensive terms and conditions. This aspect will pretty much nullify any profit motivations that the bank had to begin with.
Another option is a middle ground of using the vendor’s interfaces (API) to implement our models on the commercial system. Although it might initially look attractive, it’s allure diminishes at closer inspection; once we realize that vendors have no incentive in making it easy for the users to modify the system. If anything, it only increases their support headaches with uninitiated IT managers mucking up the core functionalities. Perhaps for such reasons, vendor APIs tend to be both expensive and incomprehensible. Besides, this route of designing a customized trading platform ends up creating highly-skilled and mobile key persons, with the associated risks.
For ultimate control and flexibility (and for most fun), nothing beats a fully in-house designed trading platform. It can be highly nimble and responsive. But it is also an adventurous and error-prone undertaking. Nonetheless, it is this route we will explore in great detail in my book, and to a lesser degree, in this series of posts.