Skip to content
  • About Us
  • Our Services
  • Case Studies
  • Content Hub
  • Blog
  • Join Us
  • Contact Us
Investment Banking in the Cloud: Overcoming the Limits of Grid Computing
Ben Saunders

Investment Banking in the Cloud: Overcoming the Limits of Grid Computing

"This is not a growth sector".

That’s what then-CIO of J.P. Morgan Chase Michael Ashworth said in 2004. At the time, the bank was embarking on one of the largest grid computing projects in the world, which, in Michael’s words, “gives us more progress toward that goal. It's something which is difficult to put a price on."

The need for, nor the price of, ‘infinite capacity’ has not been diminished by the financial crisis.

Regulation, in particular, continues to heavily impact capital markets, driving an ever-increasing need for investment banks to respond to regulatory change at speed and with increased transparency across the entire business. The likes of the ‘Fundamental Review of the Trading Book’ (FRTB), for example, require wholesale optimisations to both risk operations and technology.

Managing risk

In order for capital market organisations to manage risk more effectively and respond with greater agility, many are investing in building their own proprietary real-time risk and pricing engines that enable their business to remain ahead of the competition.

This is particularly important at a time when increased regulation and risk are pushing many organisations away from the volatile, exotic portfolios of 2008 towards increasingly vanilla - not to mention low-margin - product sets. This is because the fall in profit margins of individual trades places huge importance on real-time risk and pricing as a central means of optimising overall profits.

As a strategy, this technology-led optimisation has significant precedent: it was the capability of JP Morgan’s real-time risk engine, Athena, that enabled them to limit their respective losses at the height of the financial crisis in 2008 and others now need to follow their lead.

However, for many banks, the capital investment, time and effort required to implement such a technology solution is a challenging undertaking, as meeting these goals with traditional infrastructure presents a number of significant obstacles.

Why the grid is not enough

Grid computing, in particular, which rightly won praise in 2004, can no longer meet the requirements of modern investment banks and capital market organisations for a number of reasons.

Firstly, when building proprietary grid capabilities, it can be difficult for organisations to understand the amount of capacity they will require across any given period. And upfront CAPEX investments to purchase hardware can lead to long and onerous procurement cycles. This is compounded by costly overheads to patch, maintain, monitor and secure the grid environments.

Secondly, grids often lack dynamically scalable architecture. For many organisations, once capacity is hit, it means further capital investments, lead times and management overheads to build extensions to their grid.

Thirdly, in our experience of working with capital market organizations, their grid architectures are highly-contested and are under significant stress as they are called upon to calculate prices a risk for a multitude of asset classes and products. These calls come from different geographical regions and different time zones: either during the trading day, across a single trader’s portfolio or at the end of the day, for reporting purposes across the entire organisation.

The shared nature of grid environments means that real-time analytics is challenging for many and will become even more so as regulations such as MiFID II require that all quantitative risk models be stress tested to breaking point whilst ensuring that there is no impact on production system performance.

The power of the cloud

As the limits of grid compute become increasingly evident, there is only one potential solution to the search for ‘infinite capacity’: the cloud.

This is due to its powerful capacity to run the pricing and risk calculations for multiple scenarios in parallel, whilst allowing for the horizontal auto-scaling of environments, which is both cheaper and faster than the grid.

However, there are many other benefits the cloud can afford to help firms build, deploy and leverage real time pricing engines at speed.

First and foremost, by leveraging the cloud the need for an upfront capital investment is avoided, allowing organisations to switch to an OPEX accounting model. This will not only mean that organisations can avoid having to write off technology infrastructure from their balance sheets but it will increase their capacity to manage cost more efficiently across asset classes, ensuring that business units are only being charged for what they use and when they use it.

Secondly, because of the on-demand nature of the cloud, organisations can build new, or add to existing, architectures in an automated manner. There is also the potential to isolate business lines, products or asset classes through network topologies in order to meet the demands of your internal security teams or internal compliance. Alternatively, infrastructure and network zoning can be shared across teams to reduce costs. It is worthy of mention that many cloud providers have already been approved for use by external financial services regulators, including AWS and Microsoft Azure.

Thirdly, the elasticity of the cloud means that, with the capacity to rapidly trigger change across their infrastructure, organizations can allocate the necessary compute power required at any given time across core financial market geographies. For instance, AWS presently have data center coverage in the United States, the United Kingdom, Germany and Singapore (amongst 42 Availability Zones globally). Closer geo-located grid compute, powered by the cloud, can mean organisations don’t have to utilize a single grid architecture and then saturate their networks by trying to push elephants through pinholes. Furthermore, this means that organizations don’t have to invest and prepare for peak utilization from day zero.

This affords a greater level of agility and allows organizations to shift compute power to where they need it, when they need it, across the globe, whilst being able to deploy new grid engines in a repeatable manner that ensures that environments remain constant using automated configuration management practices and/or infrastructure as code. Furthermore, volatile markets can be handled with ease by scaling up grids to accommodate the demands of traders reacting to major market fluctuations.

Getting started with the cloud

It is these benefits which many customers are finding so attractive at present and driving their attention towards the use of cloud as a viable solution for their grid computing difficulties. Accelerated provisioning,cost reductions of up to 60% and flexible scaling capabilities make the cloud an attractive solution.

But getting started and understanding how to use the cloud as a viable grid solution is challenging for many an organisations.

Want to learn more? Watch the recording to see how we move a trading app and all dev and test data from on-premises into AWS in under ten minutes.

The webinar - Utilizing Contino's DevOps Framework to Move your Trading Workloads to the Cloud - will also cover:

  • The foundations for migrating trading apps and data to the cloud swiftly and safely
  • Ensuring compliance with regulatory controls
  • Architecting and optimising your trading applications for optimal cloud performance
  • Integrating tools and processes to streamline app and data migration
  • Measuring the business value of cloud migration
  • Buy-in and replication across your organisation

Watch the recording now

More Articles

Contino Is Now an Official HashiCorp System Integration Partner

Contino Is Now an Official HashiCorp System Integration Partner

2 February 2017 by Matt Farmer
Who's Using Docker?

Who's Using Docker?

31 January 2017 by Benjamin Wootton
Integrating AWS's EC2 Container Service into Continuum

Integrating AWS's EC2 Container Service into Continuum

27 January 2017 by Benjamin Wootton