Waters Magazine: Flying By Wire

Waters Magazine has just published my article "Flying By Wire" in its Open Platform section of the August issue. The article discusses how advanced trading systems need better control systems to dependably innovate and take new opportunities to market. I draw an analogy between trading systems and modern jet aircraft where stability, performance and control are essential characteristics that need to be considered during design, development and testing.

Flying by Wire

Financial markets are increasingly dynamic, fragmented and automated. Sophisticated financial instruments, innovative pricing models, new pools of liquidity and adaptive trading algorithms seem to be invented on a daily basis.

Advancements in processing speeds and distributed

architectures drive the markets toward low-latency trading. The automated trading engines that buy- and sell-side firms deploy have therefore become correspondingly complex. Yet many of these systems are not well controlled and present serious financial, legal, technical and operational risks.

Controlling modern trading systems is rather like flying modern jet aircraft. Both are complex systems that need to respond to demanding conditions, execute various strategies and facilitate user control. This needs to be done while providing effective real-time risk management, reliability, and performance. An aircraft's control systems are often triple-wired and it can fly on a subset of its engines, thus ensuring redundancy, capacity, and, ultimately, safety. It must also conform to the various authorities' standards and codes.

So, why is a high-performance automated trading system really so different?

In-Flight Stability and Risk Management

Aircraft are designed with two types of stability characteristics in mind: static stability and dynamic stability. Static stability produces reliable and manageable reactions to expected and instantaneous changes in user controls or external events, such that it quickly returns back to its intended mode of operation. This is a critical characteristic for aircraft and trading systems alike.

If a currency trading desk starts to experience a large volume of euro-dollar, pound-dollar, yen-dollar spot trades that conform to a user-defined "per trade size" limit for auto-quoting purposes, the resulting net dollar and non-dollar positions could quickly deviate away from target position level—a statically unstable situation. To address this, systems should be measuring, or deriving, in real time the trends in market data, orders received and last few trades executed. They should then dynamically adjust the limit controls, or actively engage smart algorithms to counter those orders and positions. This may include increasing the size of spreads, or changing the bid and/or offer sides of the quotes.

Dynamically stable aircraft are able to actively handle random and variable changes in their external environment over short and long periods of time. Advanced fighter jets are dynamically unstable to promote extreme agility and responsiveness. But they require sophisticated control processes and a massive amount of computational power to prevent them from losing control and falling from the sky.

Do you want your trading system to do that?

Atmospheric turbulence is an example of high-frequency, short-term oscillations that can induce severe forces on an aircraft and hurt performance. Likewise, an automated market-making engine operating in a volatile market will experience large oscillations. Aside from the "whipsaw" effects on bid-offer quotations, the demand on the system's computational resources will spike as it tries to price and re-price quotes. Trading systems need to be designed with active controls, limits and risk management built in-line to the trading process to "ride the storm." The control environment needs continuous processes that accurately instrument and correlate market dynamics and trading events in real-time.

This information is used by predictive models to actively feed back incremental control changes that dampen the undesirable deviations from the target strategy. Doing this across all trading processes yields benefits such as better net hedging and lower transaction costs.

Some of the more innovative banks have started to create predictive systems that offer improved financial and operational risk management. Factoring the state of order books into risk management processes help to refine prices from auto-quotation engines. The end-to-end instrumentation of the entire trading infrastructure allows performance bottlenecks to be identified in real-time. When correlated against trading and market activity, the infrastructure is then able to forecast future performance issues and dynamically scale accordingly.

The deployment of automated trading strategies should be predicated on their certification against a variety of market operating conditions to test their stability under dynamic load conditions, and to understand their response to different boundary conditions. This can be achieved via back-testing against historical data that can be "played back," or against well-defined market simulations characterized by specific events. They could also be run against live market conditions in parallel to the production environment.

Further, these algorithms need to be testing alongside one another to understand any correlations or conflicts in their inter-related effects on marketplace dynamics or the firm's net positions.

Many risk management systems lag actual market activity. In many cases, end-of-day batch processing is the first time that daily trading activity is aggregated and official positions, profit and loss, credit exposures and other risk measurements, such as value at risk, are calculated. Often, these measurements are used to initialize the next day’s opening position, which can be problematic if the overnight processing has not completed before the market opens. Many systems also calculate intra-day extrapolations of prices, position and risk without reference to other trading activity occurring across the business.

Let's look at one example. The pricing of a diversified fixed-income portfolio can be time consuming due to the complexity of generating cashflows. Often, institutions will pre-calculate the cashflows overnight and then extrapolate the deltas to cashflows during the day. A better approach would be to re-price individual bonds based on specific events that affect the cashflows and pricing in real-time, and to distribute these more granular tasks across a scalable compute infrastructure. This would also provide better audit trails showing which factors impacted the prices.

Heads-Up Displays and Controls

The large volume and high frequency of market data places a massive computational and data warehousing burden on modern financial IT systems. Rather like the pilot of a jet aircraft who would simply have their hands full flying the plane manually, traders cannot observe and process every single data tick.

Instead, like an autopilot that can consume and process large volumes of data in real-time, trading systems need to present traders with the appropriate visual indicators of derived data, overall aggregated positions, risk metrics, trends and market conditions. These indicators need to present this multi-dimensional information intuitively, allowing traders to focus on broader strategies, anomalies and "big ticket" items. This way, when conditions drastically change or big events occur traders can apply their full attention to that particular issue.

Flying by wire is clearly a safer and more reliable mode of operation, but when things go wrong the pilot must still be able to override the autopilot and take full responsibility and control to guide-and-land the aircraft safely.

Control by Design

Innovation, responsiveness to change, time to market, and dependability are critical to a trading business. The research and technology organizations supporting each business therefore play a critical role in modeling and building trading systems, but are often unable to meet delivery expectations. Worse, poor accuracy and performance of the delivered systems may actually harm the trading operation.

If managed well, a variety of iterative development techniques can be used to facilitate frequent delivery of production-quality systems. Good source code and version controls, continuous build and integration environments are also needed to allow systems to be modified, tested, deployed and reconfigured dynamically, automatically, and reliably. They can also facilitate an efficient codebase, fostering component re-use and productivity. Architectural decoupling such as the separation of business-logic from the runtime compute infrastructure; stateless user interfaces; and componentized business logic, all facilitate the performance and responsiveness demanded by new business initiatives.

Many buy and sell-side institutions trading systems lack a sufficient IT infrastructure for supporting key audit, compliance and regulatory reporting requirements. One of the most common problems trading systems experience is the lack of a decent security master or client reference data. This results in data duplication, mismatching information, convoluted mapping tables and staff burden. In addition to a common service layer for managing this information, firms need to implement a reasonable data distribution layer that might include locally cached copies of information, or a publish-subscribe service to access data on-demand.

Regulations such as the Markets in Financial Instruments Directive (MiFID) in Europe and Regulation NMS in the US require proof of best execution and transparency into the data and decisions that went into trade executions. Audit needs to capture similar information including who performed which trading event. One of Sarbanes-Oxley’s operational risk management requirements is the need to define roles and separate permissions and/or access to different data and functions. Fraud surveillance requires, among other things, that entire order books and trade executions be monitored—but often only executions are tracked.

Many of these requirements can be satisfied if trading systems can measure and capture the prevailing market conditions, all trader and client information, and all data, calculations and processes that go into every trading decision, calculation and execution. Systems must be able to reliably repeat those calculations based on that data later.

This requires that the software components' configuration and versions be captured along with the aforementioned market and trading data.

The need for a comprehensive control environment should not be thought of as a hindrance to trading. It should be the mechanism by which business can dependably innovate and take new business opportunities to market. The skies should be our only limit.

Ross Hamilton is the director of client engagements at Lab49, a technology consulting firm that builds advanced solutions for the financial services industry.