Insights

Business Perspective

service-slider-placeholder.jpg

Embracing Cloud Solutions

As fintech professionals with long experience of on-premises and private cloud installations for swaps trading platforms, we made a conscious decision in 2015 to ‘go cloud’ with a highly scalable, intuitive and powerful cloud-based offering. As we expand to other financial services software, we have no “all or nothing” perspective on cloud computing. In this whitepaper, we call on our collective experience working in and with investment banks to describe what cloud applications can deliver in terms of security, flexibility and value for money. We acknowledge that on-premises, private cloud and hybrid solutions have an important and perhaps even inevitable place in the financial services IT playbook.

“Security is still very important and compliance is still a non-negotiable thing for many of our clients. But what is happening now is that instead of saying, “OK, we’re just not even going to discuss cloud because of those constraints.” People are saying, “OK, well, those constraints are there. Let’s talk about specifically how they’re going to be addressed when we use public-cloud services.”

- McKinsey Podcast, July 2017
Corporate IT Decision-Making

Spurious factors are often at play, consciously or unconsciously when making important decisions. In our experience, that is no more true than in the sphere of IT infrastructure selection and software deployment by financial services organisations. One side of the ledger may present clear benefits for making change, but fear about how one might be perceived within the company often tip the balance in favour of muddling through with what one has.

Boards often discount the merits of cloud based on a perception that it introduces new risks, while simultaneously being unaware of the vast array of risks embedded in legacy systems, including the risks of continuing to maintain and operate those systems going forward. They may just see an IT budget line-item which is simply expanding. We hope this whitepaper helps not only to shine a light on some of the underlying issues and hazards but also to offer up ways in which new software deployment models can mitigate them.

Perceived Risks of Cloud

Novel courses of action have ‘asymmetric risk profiles’ as a trader might put it. That is especially true of cloud computing, where truths, myths and false perceptions combine in ways which tend to polarise, paralyse or postpone decision-making. Nuvo Prime itself was forced to address these issues in making its own move to the cloud. Some key drivers informed the move, as discussed further below. We recognise that our clients have similar considerations to confront. In this paper, we consider their concerns against the backdrop our team has, not only in managing software development, but in running lines of business and products within financial services companies and hedge funds.

Internal decision-making at banks hits the first obstacle when it comes into contact with pitches delivered by IT providers. Each has its own axe to grind. Some push “hybrid cloud” because their edge is in providing consulting services and hardware. For others, public cloud is the only way to go, because that is what is on offer. Still others say only private cloud or on-premises can provide the right level of service.

While it may sound strange coming from a cloud-based software provider, we are agnostic. Each financial services company and each functional area within that organisation must cut its fabric to match its pattern. A sophisticated proprietary algorithm driving trade executions or an application managing hedges on the firm’s exotic book are probably not top of the list for recoding or redeployment in the cloud. Equally a US margin calculator which, although performing pedestrian tasks, is nevertheless complex, may also not be a good place to start. For a number of other reasons, some applications within a large financial services organisations will need to stay in legacy code and legacy infrastructure for some time, possibly indefinitely.

Getting Started

So, where to begin? Our own journey to the cloud as an organisation began two years ago when Nuvo Prime started thinking about the next chapter in its development of equity finance software solutions. Our founders, each with 12-17 years of consulting and software development experience in the investment banking IT space, had witnessed the same problems arise time and again. A bank had decided to build and implement a swaps system. From that decision, a whole chain of events predictably issued forth: production and UAT hardware procurement, installation, and commissioning. A disaster recovery stack would follow. Operating software was integrated, configured, tested and deployed. Financial firms needed the trading software developed in-house. And so, iteratively, over periods measured in years, that development would converge on a fully-specified swaps application. By the time the software went into production, millions of dollars in network, hardware and software had been installed, with a full suite of IT professionals to develop, maintain and operate it all.

Two years after go-live, some or all of the original hardware was either out of date or was in some way inadequate to support the scale of the operation. Then, like groundhog day, new hardware would be procured, installed and commissioned, and the whole cycle would repeat itself. As staff turned over, institutional knowledge about the trading platform was lost. Enhancing and extending it became increasingly difficult. The whole process was not only cumbersome, it was extraordinarily costly.

Back in the day, it seemed to make sense. Fully functional trading platforms were not available, outsourcing technology was not mainstream and the banks believed that there was an edge to be had in building a best of breed trading system in-house.

Cloud Computing’s Readiness

Not so in the 21st century. For Nuvo Prime, cloud computing seemed a strong candidate to deal with the problem of perpetual obsolesence. The cloud had matured in its security, scale and resiliency. In fact, Amazon Web Services (AWS) in particular had reached a size, which some would call ‘hyperscale’, at which accommodating the needs of even the largest financial services organisations would not move the needle.

Most important, cloud was and is ready for financial services firms’ compliance needs. Flexible data residency, hardened facilities, inherent disaster recovery mechanisms, powerful record retention capabilities2 and other stringent compliance features are built-in. These have been designed to meet the specific legal and compliance requirements of financial services organisations. Acknowledged by regulators as a suitable platform for IT outsourcing3 , financial services regulators such as FINRA had adopted the cloud wholesale for their own operations.

We turned to AWS, which has well over a million active users and some of the largest corporate, governmental and health care organisations in the world running their businesses and maintaining sensitive data on it4 . Among the drivers commonly cited as a reason for the growth of the cloud is cost. Case studies recite how one company cut its storage costs by 80%. Another cites agility: one company cut its time to market for new products by 25%. A third company found the cloud to be the source of very inexpensive and durable data storage.

We saw things differently. To us, the increasing trend towards cloud computing was not about any of these benefits in isolation. Collectively, they are an expression of specialisation at work in Information Technology. Whereas at one time, sophistication in network, computing, database or storage capability could give a financial services business an advantage, today they are more likely to be a millstone. These IT utility functions are now largely commoditised. In AWS they operate in an environment which is readily configurable, flexible, mobile-ready, distributed in its footprint, and which operates at immense scale and speed. Specialisation has gone well beyond hardware and infrastructure. Cloud providers and cloud specialists provide a wide range of managed services which are beyond the capabilities of any single company not focussed exclusively on IT. These organisations offer concentrated expertise in security, threat monitoring, penetration testing, provisioning, and continuity management, to name a few examples.

The availability of such a computing infrastructure on a usage-based pricing model makes it inevitable that the cloud will grow in both dominance and importance. It means that financial services firms can themselves now specialise in financial services.

Spinning Plates: The Tech Debt

For us, transitioning to the cloud went well beyond infrastructure. SwapScale, Nuvo Prime’s cloud-based flagship swap trading application, would need to be developed in a cloud-suitable programming language and would need to exploit the managed services and scalability features native to cloud computing. It is one thing to say that cloud computing will become ubiquitous; that is hardly an insight. It is another to say that now is the right time to embark upon that venture. So in making the leap to this new environment, we had to consider carefully whether a swap trading platform was well-suited to cloud deployment.

Wall Street firms have accumulated and suffer chronically from what is commonly referred to in the IT community as ‘tech debt’. That condition describes a mass of installed code which becomes ever more difficult to manage and change.

It is worth recounting how this situation developed because it helps inform how one goes about resolving it. Many of the largest banks have serially acquired other organisations, both large and small in the last 20-30 years. With each corporate assimilation, came a choice about how to integrate applications and infrastructure. Inevitably, a comprehensive restructuring and integration onto a common IT platform was perceived as either too complex, too time consuming, too expensive, or not ‘accretive’ within the timeframes that banks once judged return on investment, usually 3 years. Putting it differently, the timeframe for rationalisation of infrastructure and applications would have exceeded the timeframe in which banks’ business plans were measured and implemented. Confronted with a low to zero ROI on investment, the ‘tech debt’ problem would be postponed to another day. Making disparate systems inter-operate was more often than not a more cost-effective and rapid means of integrating two businesses.

The consequence at most financial firms is a vast patchwork of systems. Mapping them out, even in summary form, consumes the largest of paper sizes, taped edge to edge. From an infrastructural perspective, each system has different hardware which needs to be separately supported. The applications running on them are equally diverse, requiring discrete teams with differing programming language skills. Not only must each of those teams have a minimum size (2-3 FTE) but many of them will not have fungible skills. On the edges of these stacks are often other teams, middle or back office, struggling with a range of manual tasks run on desktops and macros. These are the financial services equivalent of ‘black-ops’ forces which operate unseen by governance structures at the top of the house. At one organisation we encountered, one half FTE a day was devoted to entering 550 lines of securities trading information which could have been easily and more safely been achieved with a short script. At another, dozens of regulatory margining tasks were performed by staff on banks of desks running spreadsheets.

Having accumulated these problems for decades, that tech debt is now enormous at some firms. Code has been modified and remodified, data feeds both upstream and downstream have proliferated, while a constellation of applications revolve around the main books and records of the firm. Sometimes there is more than one set of books and records. Many if not all of these systems run in batch, meaning that job scheduling becomes complex. The wide assortment of differing coding languages requires middleware to translate, aggregate or manage the interactions amongst these systems. All of these interdependencies comprise a complex system with a large body of employees devoted to managing coordination, increasing concurrency between tasks and responding to incidents which flow naturally from increasing entropy.

Some of the programming languages are so old that practitioners of them have become vanishingly small in number. Over time, turnover in these diverse areas may mean that the code itself is not well understood, making it difficult to change and regression test. A good portion of the “QA” budget may be devoted to managing this complexity.

Risks of Legacy Technology

In short, there are usually many spinning plates, more in most cases than senior management may realise.

Inefficiency and high cost are one obvious direct impact: a third or more of revenues may be consumed by IT cost allocations, just for “lights on”. Complex and lengthy regulatory examinations are another. What may be less obvious is that the fragility of these arrangements creates second-order hazards. Post financial crisis, simply being unable to retrieve records within a reasonable time period can bring on a fine from a regulator. Operational deficiencies leading to loss will directly impact capital requirements under the Basel Committee for Banking Supervision’s Standardised Measurement Approach. And then, regulators want certain risks, for example, high-frequency trading, to be managed in real time, not in batch.

Tech debt is thus much more than simply a spaghetti junction of legacy technology. It calcifies bad practices and inhibits the firm’s progress, prosperity and even survival. With time, the perception of the enterprise in general and the experience of the customer in particular deteriorates. The bank is no longer the first port of call for innovative solutions.

Transitioning to Cloud

Cloud used to be about cost, particularly in network heavy or data storage intensive applications. We see cost advantages as an effect not a driver. Data sensitive players such as health care companies, banks, financial regulators and government intelligence organisations have all adopted cloud. Security, transparency, agility, and resiliency are, in our view, the prime movers. Another is that a complex legacy IT stacks offer up a wider and more fragile attack surface each disparate element of which must continuously be monitored. While the cloud presents a larger target, it is hardened by dedicated and expert teams. With one eye on ensuring that cloud security obligations are being discharged, corporations moving to cloud can focus much more of their attention on managing their customer delivery model and controlling risks which are germane to their core business.

Financial organisations have reached a point in their development where cloud computing for certain applications makes eminent commercial sense. It is likely to become an imperative for most tasks.

That lengthy description of the multi-faceted problem banks face sets the backdrop against which our swaps trading platform, SwapScale, was developed. Why deploy this particular application in the cloud? Our interactions and observations of working in and with banks have yielded some insights on areas opportune for the introduction of cloud technology. We look for one or more of the following features from this list, which is non-exhaustive:

  • a relatively commoditised application with low intellectual property potential for any one firm;
  • a clearly circumscribed set of workstreams;
  • well-defined upstream and downstream data feeds;
  • a reasonable level of abstraction, in other words calculation or other tasks which are suitable for automation and are not inherently manual;
  • moderate levels of data transfer;
  • network opportunities to create an application ecosystem, for example mobile applications or a customer portal; or
  • possibilities for ease of use, better management visibility, control and a shorter learning curve achieved by exploiting the cloud’s native GUI web technology.

A swaps trading platform fits the bill on most of the above measures. It is a manageable objective to identify the likely 20-40 integration points and control groups within a large financial services organisation that are connected to the swaps trading system, for example, trade pricing, order management, credit, collateral management, risk, treasury, regulatory and client reporting. Again, it is manageable to connect these to a cloud-based system which controls swaps workflow, marks, collateral and reporting. Where a large legacy swaps system is already in operation, running the two swaps systems in parallel for a period of time is of course mandatory.

Although by no means painless to analyse and implement, decommissioning the legacy system will yield a number of clear benefits. Views will differ as to which benefits are the most significant or most important but we would put transparency first.

Transparency of Cloud

For the reasons described above, managing IT budgets and creating a direct and clear connection between IT spend and IT output is exceptionally difficult in a legacy environment. The cloud pricing model for SwapScale, excluding the support desk, is a single number which flexes with the volume of business, declining asymptotically as a function of rising transactional volume. At high volumes, its marginal price converges on the wholesale cost of network, compute, storage and archive resources. Not only will the costs of the system therefore be strictly variable but the demands that the bank places on the underlying resource components of the stack itself can themselves flex.

For example, a swaps business will evolve over time as market conditions and customer demands change. A low volume, high value structured finance business will place low demands on compute, but rely heavily on the visibility of GUI-based workflow and trade management tools as well as the reliability and availability inherent in multi-zone, multi-region cloud deployment. At the other end of the spectrum, high frequency trading will place high demands on network, compute and storage resources. The former business will pay a lower price for the swaps platform, the latter a higher but ever declining price. Both can be accommodated in a highly resilient and secure deployment model which has no effective upper limit on any of the system resources, each of which can be provisioned separately.

Transparency means not only understanding exactly the IT spend associated with the resources used by the platform but also being able to focus the efforts of those who work at the bank on the top of the value chain. The intuitive usability of a cloud-based application employing web technology means, for example, that governance and control functions can readily access the system in read-only mode with little training, improving direct management reporting and surveillance. What was once a two-day IT task to run a script that could generate an extract of all clients priced at less than 35 basis points over LIBOR, as an example, happens in an instant as the end user can interrogate a flexible and powerful embedded query capability pre-indexed in Elasticsearch, a search and analytics engine running on AWS. Visibility opens to client transactional behaviour, profitability and resource usage. Client entitlements, contractual terms and trading data come together in a coherent and integrated whole.

Cost of Cloud

What about cost? There are as many opinions about the total costs of ownership of competing systems as there are systems. SwapScale uses the “software as a service” model which means that the costs of the application and the infrastructure charges are applied on a subscription fee basis and therefore known with accuracy. While the costs of integration and migration to a cloud-based swaps platform can be significant, these will be offset over time by greatly reduced IT FTE, lower operational losses, lower costs of the SaaS application and infrastructure and the other direct and indirect benefits derived from fewer ‘spinning plates’.

Selecting a suitable system for cloud migration and implementing a cloud deployment for that application is not the starting point. Each firm needs to have a clearly defined cloud strategy, framed in terms of the timelines for IT investment which now must run out for a decade or more. It may be that having a cloud trading platform is too much to bite off. We have already engaged with organisations that know they must upgrade to the new languages and technologies of the cloud or be left behind. Some are looking at containerised deployments which could later be migrated to the cloud. A highly manual workflow environment, which could benefit from a flexible GUI, integrated four-eyes controls and a full audit trail, is being considered by one of them as a place to start.

Conclusion

We’ve attempted to share the details of our own decision to move to the cloud as a thought piece to stimulate consideration of cloud technology, where it is appropriate. We do not believe that every workload or every element of data should be on the cloud. Cloud strategy must be tailored carefully to the circumstances which are peculiar to each organisation.

But after more than a decade of experience with on-premises and private cloud technology, we saw immense advantages for a cloud-based swaps trading system.

There are those who claim that cloud is expensive or that it quickly becomes unclear whether you are getting value for what you are paying. That does not need to be true. Providers of cloud-based applications need to confront what could be an excuse on the part of their customers to muddle onwards, in the process, piling up more ‘tech debt’. We think subscription/licence and infrastructure costs should be upfront and fully transparent. As the customer’s business grows, so should the willingness of the provider to work with the client to refine the costs of cloud resources: downwards.

Cloud computing is gaining adoption speed in a financial services industry which is heavily laden with legacy technology costs. While managing significant infrastructural change may be daunting, it is not going to get easier the longer it is postponed. The sheer cost of IT at financial services firms makes that spend stand out as a target for digital transformation. Those firms who fall behind in modernising and leaning out their enterprise IT architecture expose themselves to competitive and disruptive forces which may soon prove to be astonishing. Starting now is a good idea.

“Illusions commend themselves to us because they save us pain and allow us to enjoy pleasure instead. We must therefore accept it without complaint when they sometimes collide with a bit of reality against which they are dashed to pieces” –

- Sigmund Freud

1 McKinsey Podcast, July 2017

2 For example, AWS’s archive facility, Glacier, meets the requirements of SEC Rule 17a-4(f), FINRA Rule 4511, and CFTC Regulation 1.31.

3 Outsourcing to cloud computing providers must be carefully managed. The legal, compliance and outsourcing implications of cloud computing in a financial services setting are the subject of a forthcoming thought-piece.

4 See: https://aws.amazon.com/solutions/case-studies/all/

Author