#1 in the Problem Solved series: Trade rejection rate reduced by a factor of 8


”Problem Solved’ series #1.

Many banks’ ecommerce teams obsess over reducing the frequency trade rejections – and for good reason – after just a few rejections, your clients will go away and use a different platform.

The problem often manifests itself during fast markets in high frequency trading scenarios, exactly when your clients want to move out of dangerous positions to reduce risk exposure. Sudden market changes generate a wealth of market data and trade messages, in turn overloading your distribution and trade capture systems, leading to delayed trade messages, trade rejections and headaches for your clients. But what can you do when market risk prohibits any further relaxing of trade latency allowance?

I’ve recently worked with a tier-1 investment banking client to reduce message latency and consequent trade rejection rate. The problem is long-lived in the industry, requiring analysis in trading behaviour, profiling of market data, and benchmarking of trade capture capability.

After similar engagements with other clients, the plan was to incrementally analyse and optimise each stage of the trading life-cycle, e.g. the quote-request, price generation and distribution, client processing, rendering and trade acceptance, with resolve to improve efficiency, performance and scalability of the trading system as a whole.

Many optimisations were easily achieved by leveraging standard product features within Caplin Xaqua such as trade message prioritisation, market data conflation, auto-batching and sending delta-updates only. Another optimisation was identifed halving message size by migrating an XML-based trade encapsulation across to the standard Caplin Xaqua record structure; using XML to model volatile financial objects is a often sub-optimal in terms of client processing overheads and bandwidth utilisation.

Trade behaviour analysis also revealed clients making concurrent trades when an efficient basket trading workflow was not in place. A simple optimisation was to send these trades for execution together rather than processing and sending them sequentially. Although the trading application could have easily been augmented, an enhancement was made to Caplin StreamLink so that all our implementations now leverage automatic batching of trade contributions under-the-hood.

Result = Trade rejection rate reduced by 8 times
After a period of production service testing, the mean trade rejection within the new browser-based platform was reduced 8 times below the ousted Java desktop trading platform. Furthermore, the Caplin Xaqua enhancements in place mean that we won’t need the solve the same problems again!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: