As a cloud service provider, we are frequently evaluated by a customer’s IT Security who conduct risk assessments on our Software-as-a-Service’s architecture, security and processes. These assessments are detailed and thorough. Clarus is not the only innovative cloud vendor doing this, we are one of many. The cloud is happening, and it is happening now.
Bloomberg recently reported an update on the US defence departments “cloud competition” the winner of which gets to host the Pentagons data on the public cloud. This is not about IF they should move data to the public cloud, rather it is about WHO will host this data on the public cloud.
Last week the Australian Prudential Regulatory Authority (APRA) published a revised information paper on “Outsourcing using Cloud Computing Services”. This gives a good regulatory overview of the risks of engaging with a cloud vendor. It does not question IF you should move to the cloud, it talks of how to mitigate the risks WHEN moving to the cloud.
The first part of the paper defines cloud computing as follows.
Cloud computing provides scaleable technology services through the sharing of IT assets (including computer processing, network, storage and software).
Storage always comes up in every risk assessment at every financial institution. How is the data stored? Where is the data stored? Is it encrypted at rest? Who can access the data? No regulator (or financial institution) wants a data breach. At best a breach causes reputational damage and at worst actual losses to the financial institution or its clients.
Risk as a function of usage
The APRA paper identifies three levels of “risk as a function of usage” of cloud providers.
Low Inherent Risk
This would generally cover data that is
- Of low criticality and sensitivity
- Publicly available information
- Test and UAT systems
Heightened inherent risk
Risk here is not so much about the type of data, but more about the experience (of the vendor/provider/financial institution) and processes in place to manage the cloud solution.
Extreme inherent risk
Here the level of risk would be the risk associated with maintaining a system of record for obligations to customers and counterparties on the cloud.
Legacy derivatives vendors such as Murex, Calypso, Finastra (Mysis) and FIS (SunGard)) are all systems of record/truth for a financial institutions trades with external counterparties. Given the tightly coupled nature of these existing vendor applications to their databases, for them to benefit from the cost reduction using the public cloud, the full application stack, including the database would need to be migrated to the cloud.
All are pitching their cloud solutions and it is safe to assume that all of these would be classified as systems of “Extreme Inherent Risk” when implemented on the public cloud.
Consequently we believe that very few customers of these legacy vendors will be able to take advantage of the massively better economics of public cloud infrastructure.
The Clarus Difference
At Clarus we have designed our applications to deal with what we believe is the new order for derivatives data. We have developed an architecture that does not fit neatly into one of the “Risk as a function of usage “category above. Why?
We don’t store trade data at rest, we only utilise the data in memory.
We can store data, and when we do it is done in a way that is decoupled from the application. That means that you as the client can control access to this data which can be stored in a secure repository and in a industry standard format.
The secure repository can be within a customer’s internal network, within a customers cloud infrastructure (for which a customer controls security policies) or it can be managed by Clarus with a range of configurable security policies.
We know from the security assessments that we have done with our customers, that this difference allows them to utilise the public cloud; quickly, securely and effectively.
Further the fact we can store data in industry standard formats (e.g. FpML for OTC Derivatives trade economics) and not our own proprietary formats, means that we do not lock customers data away and make it difficult to access or move. Avoiding such data lock-in is important in every IT strategy for cloud migration .
Source of truth
Historically derivatives transaction data, the source of truth of a derivative trade, was hidden somewhere in large monolithic enterprise trading system like Murex, Calypso or Summit. These enterprise trading systems spent a considerable amount of time managing the trade events on these transactions often delivering less than ideal outputs for risk managers and front office users, but they were the source of truth, the system of record.
With the advent of clearing, the source of truth has changed. Now it does not really matter what the internal booking system says for cleared products, as the CCP is the golden copy or source of truth for the trade. CCPs also manage life cycle events on trades and have introduced their own compression life cycle events, which further create complexity and disconnects with internal booking systems.
Reports from CCPs are the source of truth and legacy internal systems need to be updated to reflect this source of truth. If a CCP requests a VM or IM amount, a customer has to do provide this amount. Many organisations do not calculate or validate the numbers sent by CCP’s, they just assume that these numbers are correct.
There is obviously more to this, but we do believe that if you are about to start a new derivatives related business or you are considering a cloud infrastructure to lower costs, you should not implement a legacy system, These systems are not designed from the ground up for the cloud, will lock-you-in to closed proprietary formats and will fail to deliver their touted benefits.
Look for the source of truth for these transactions and then talk to Clarus.
We are always willing to help.
Do contact us on firstname.lastname@example.org for a follow up discussion.