The targets of this article are typically sell-side financial institutions that build or buy, and then integrate trading platforms. The ideas in this post can also apply to investment managers and the broader buy-side to better understand how their order flow is managed.
As an owner of a brokerage and its electronic business function, or their technology teams this article contains the basic concepts and structures for how to manage client order flow (and ensure downstream clearing, performance, risk, reporting and surveillance systems take this structure into account).
The example used here is a broker desk trading Listed Derivatives. These securities have variants and permutations that are not so well known outside of those who trade and clear them. Various US exchange and clearing house websites provide excellent introductions for anyone wanting to understand the financial exposures of these instruments, why a bank or corporation may want to hedge or speculate with them, and the contract lifecycle itself. By comparison, this article will focus on the more arcane nomenclature, the nuances and bespoke industry workflows – aspects you wouldn’t likely find elsewhere.
Futures trading is at its heart a commoditised business. The taxonomy of products and standard workflows has evolved over time, driven by a need to process more order flow and transactions faster and more cheaply. This is known as parameterisation, and is analogous to containerisation. Buyside clients have desired to route orders to their sellside brokers faster, to look into the status and performance of their orders in real time, whilst being able to adjust these orders (without taking the full risk of trading DMA). This interaction began over the phone, then email and spreadsheet, and finally platforms formalised the order and instruction interaction between client and broker. However, something was lost between trader and technology – and the proliferation of systems in the 2000s often failed to adequately capture all of the order flow in the optimal way, and often left certain instruments and certain flows unsupported or inadequately supported. There was an oversimplification of a more complex set of hierarchies and linkages. More recently these design errors have been repeatedly made, but in downstream systems. I will illustrate and allude to some of these in three defining aspects of a broker desk’s activities.
Firstly there is the product symbology. The Futures and Options covered here are exchange traded, so the full list or dictionary of ‘available’ instruments can be looked up and identified. There are over 80 exchanges globally, and although the majority of volume trades on around 200 products, some venues boast of tens of thousands of available instruments. Filtering out by using Open Interest or ADV may separate the Hard Red Wheat from KCBOT’s other products. Exchange’s own instrument codes usually equate (or resolve) to a Bloomberg code, RIC and other industry symbols. These ‘outright’ F&O (individual expiry months visualised as a single line) are available in combinations, which are called strategies (as investors will use the combination to express a particular view, or to alter an existing position). The most common example are calendar spreads, of two usually consecutive expiry months in opposing sides (e.g.”SellSep20F+BuyDec20F”). This would be used to roll an existing position in the front month (i.e close out the September position) and simultaneously trade into the back month (i.e. open a new position in December) in one single execution on the order book, that then settles (or clears) into its constituent parts. This is done to improve price discovery, and to reduce the execution risk of the trader getting ‘legged’, where only one of the expiry legs is done at the desired price, with the other expiry leg not done (as the price happens to move away from them). Option Strategies are more exotic, with call ratio spreads, straddles and strangles to name a few. There are also strategies that enable exchanging a certain position in the underlying, or even to combine various products in various ratios (e.g. HOGO spread, the Heating Oil, Gas Oil combination, or in the Soybean, Oil, Meal complex). Given these numerous permutations, and also some ability to set non-standard expiries or strikes (such as for equity options) some exchanges offer the service for the user to request the contract or strategy is made available. These are often called User Defined Strategies, and Flex contracts. Symbology is complex and varies across venue and jurisdiction, but nevertheless it is still formulaic, and hard to get badly wrong. Various cross asset downstream platforms fail to treat the trading multi-leg structure at all, instead defaulting to single line interments/ constituent parts. Misnaming and miscategorising are common faults in the trading platforms themselves (where the appearance needs to be intuitive, and fills and allocations aligned to individual legs as well as the head of the strategy). The time window of instrument availability poses technical problems, particularly if markets reserve to change a handful of their 10,000+ instruments just before market open. That said, due to the formulaic structure of the instruments, systems should be able to cope with these changes, and indeed provide an ability to sensible override or manually adjust when events require. The same applies to risk systems.
The second aspect structure of the order itself, and its associated trades. The order is the record of the client’s instruction. At a minimum it will contain the instrument, a quantity (in lots), a side (buy or sell), and a price or price conditions (like an order type and expiry type or time in force). If the client changes that instruction, then it needs to be modified. There is an industry practice of the broker repeating instructions back to the client over the phone (to ensure accuracy) and not accepting the instructions until they have acted upon them. This avoids promising the client something you then can’t deliver as the market moves away from you. Order workflow typically starts as Open (either as Unreleased to Market, or Working on the Market, potentially as a PartFilled with Balance Working) and ends as Closed (Fully Filled, Cancelled, BalanceCancelled, or perhaps an Expired or Rejected status if you’re less lucky). A useful way to think about orders status is to consider how much is sent out to the exchange (typically the central limit order book or CLOB) and in respects of how much is filled. In other confusingly similar terminology, the order may be opening a position, or closing a position (that the client already has). This however, is not normally captured on the order at the point of trade (except in certain markets like China). In most parts of the world, trading and clearing is a bifurcated service, that is to say that it can be done by two different brokers (an ‘execution only’ broker who ‘gives up’ the trade, to a clearing broker who receives the ‘give in’). Just as some clients choose to execute the orders themselves (using the broker’s membership, but not the broker’s execution desk) and use one of their execution algorithms, so can the broker’s desk also use these algorithms. These algos often create ‘market slices’, often represented as mini order lines that are automatically released to the market, linked back to the original order (or instruction). A broker may also be instructed to execute the order as a block (to block the order): this is to say they are asked to trade off the CLOB, finding a suitable counterparty to the order, often within certain price and volume conditions (e.g. must be at least 100 lots and between the best bid and best offer only). As you are becoming aware, the structure of the order can be visualised and structured in different ways in alternative platform. This is despite some commonality as single paper tickets were replaced by single rows in excel like grids (the platform’s order book). Order Status is a simple problem with far too many half baked solutions, and no industry standards. Type of order, how it is worked, and which also is used (or other execution methods) is often patched together without much foresight. This causes downstream issues when trying to separate certain workflows and Algos (particularly when normalising data across systems). How to visualise fills or order events in summary (i.e. within the line) as well as in more detail, is sometimes poorly representing and prevents the efficient capture of order, trade and position state.
The third and final aspect is that the order instruction may be received and accepted electronically (rather than via phone or chat). The order may also be subject to grouping or ungrouping, and it may be assigned or routed, all within the broker’s own control. The receipt is important, because the broker should see the order beforehand, in order to review it, before he formally accepts it (or occasionally when he rejects it). The client may have sent it in error, or the broker may offer his expert judgement on it, or may simply be too busy to work it with those conditions (free text fields are still used for those instructions that the various order types just can’t reach). As well as the new order, there may be amendment or cancellation requests – similar to the voice order, the trader will want to review the request beforehand, in order to see if he can do this (before confirming back to the client that their latest instruction has been accepted and successfully acted upon). There may be multiple orders, and these expected to be released to the market en-masse, or possibly grouped together and worked in a bulk. This may be due the client adding further quantity throughout the day, or representing different accounts or clearing instructions (such as different give up) or some form of separate allocation instruction be used instead (pre-trade or post-trade). Orders that trade over multiple days (Good Till Date, or Good Till Cancel) will likely require re-entry for market open, or at least oversight by another broker desk (like a follow the sun support model). Rather than routing (which often transfers where the order is actually hosted across firms or systems) this is purely a transfer of ownership (typically between desks or individuals within the same system and same firm). Such a transfer would always require a handshake – a send action (not yet accepted or rejected) and a receive action (accept or reject). As you may well imagine, with these additional order management workflows and combinations, various platforms attempt solve in a multitude of ways – and most finding this pure UX challenge the most difficult to solve.
In conclusion, within the context of one asset class (in this case listed derivatives), it is clear that the evolution of exchanges and the various pressures on the broker’s business has changed how instrument, order and trade data are represented in various systems. It has taken well over 15 years from the initial electronic trading of these instruments before the trading systems became broadly optimised for the majority of the order flow. There are, however, still outliers causing trading difficulties, and looking downstream (to clearing, risk, performance, reporting and surveillance) there is usually even more work to do. Knowing your data structure is key to being able to efficiently process more of it, and to ultimately do much more with it to differentiate your business.
More information, platform assessments and formal selection review is available upon request.
Norton Edge provides Subject Matter Expertise, helping you understand your electronic trading and downstream technology needs. Our experience is cross asset class, and a broad range of firms from small family office and proprietary trading companies, to large buy or sell side institutionals integrating or developing new systems. Norton Edge provides guidance straight from the designers-in-chief and business owners of trading platforms and downstream architecture.