The biggest barrier to clouds in banking is the banks themselves

Returning to the subject of cloud computing, I mentioned that it is starting to succeed by being more relevant through a vertical focus, but there is still more to be done for cloud to truly take off in banking.

In particular, most banks have a concern about the risk of cloud and who is accountable. 

If a payment is dropped it creates great reputational risk, and this is a valid concern.   If a trade is missed, even with zero latency, the issue exposes the bank to fundamental weaknesses in its investment operations.

It’s not like dropping a phone call or a plane taking off late.  The movement of monies and access to profits in a secure and resilient fashion is a fundamental and, for today’s technology in banking operations, there is the core issue.

It is the risk of system failure or IT exposure that causes most banks to want to control the whole operation internally.  Develop and build within the bank, run and maintain within the bank, operate and support within the bank.  That has been the mantra for decades and it is hard to change.

This does not mean that banks do not use cloud services.   Outsourcing and offshoring are good examples of where banks have moved to lower cost business models, and the move to operational expenditure rather than capital expenditure for their operations. 

But what have they outsourced and offshored?

Systems development and call centres.

Non-strategic services.

Nothing of any core exposure or value, such as trading and payments processing.

Even today, there are few banks that outsource their core payments processing and, when a bank does, it is usually to a trusted counterparty bank.

This is the biggest barrier for cloud therefore.

Add on to these issues the scare stories of companies such as Netflix being unavailable at peak times due to Amazon Web Services and you can see why banks are avoiding cloud.

Amazon claims it is the type of contract Netflix signed up for that was at stake, but who is to blame when there is an outage?

That is the concern.

If a bank has an outage, is the blame with the bank’s systems, the contracts they sign up for with cloud providers, the service providers to the cloud providers, the communications firms that link the bank to the cloud services... who’s to blame?

And, for all the good intentions of Service Level Agreements (SLAs), can they really be enforced if you have multiple issues between diverse providers in different geographies with different national laws?

In other words, the risk of cloud causing outage to mission critical services is the biggest barrier to cloud adoption, even when it is offered in a bank-specific verticalised approach.

I think it was best summed up by a colleague at a recent meeting, who said that banks have done all they can to ensure they have fault tolerant computing, at the expense of customer-centric services.

In other words, it is the mission critical uptime that is the focal point of technology in banking, especially in core services.

Until cloud providers can prove their ability to provide banks with mission critical uptime under a pay-as-you-go agreement can be delivered 100% accurately every time, banks will still be nervous about moving core systems operations into cloud-based services, no matter what the gain.

After all, there’s no gain without pain, and banks just cannot afford the sort of pain that might be unleashed if there were a cloud meltdown.

On the back of this article, a friend pinged me the following (published on Business Cloud News in June):

John Finch, CIO of the Bank of England was speaking at the Cloud World Forum in London on Wednesday

Firms looking to adopt cloud-based services should consider the security and data privacy implications associated with moving critical systems into the cloud, and not let vendors drive their technology strategies for them, according to Bank of England CIO John Finch.

Finch, who was speaking at the Cloud World Forum in London on Wednesday, told an audience of enterprise IT professionals and technology vendors that businesses should consider the data sovereignty implications when moving into the cloud.

“If you go to a partner to host your data, you need to ask questions. Do you know where the boxes it runs on are and do you know the legislation that covers those boxes?” he said. “One well-known provider promises your data will stay in Europe. But with this provider the boxes sit in the Nordic region somewhere. Who here knows Nordic law?”

He said that businesses should exercise caution when it comes to assessing cloud service providers’ approach to security, a huge area of concern for the Bank and the rest of the financial services communityamong others.

“Remember, when you go to a third-party provider you are placing some of your security posture in their hands. That may be a good thing if they have the expertise, but remember you are leasing part of their perimeter,” he said.

While stressing the challenges associated with bringing more cloud services into organisations more barodly he did say that he didn’t want to seem like a “cloud denier,” acknowledging the many benefits his among others have realised as a result of using these platforms (he said he couldn’t discuss specific systems for security reasons) – agility, reduced cost, and faster time to market for instance.

But Finch also suggested that cloud vendors have had a tendency to over-promise and under-deliver, particularly on the cost of cloud services, and that businesses should resist letting vendors set their technology strategy for them.

“All the vendors will be telling you ‘you don’t need IT teams, they’ll do the heavy lifting for you.’ That is sometimes true, and there are cases where cloud can be a real enabler, but that doesn’t mean it’s always right,” he said.

“The vendors will also tell you there is a financial upside but my answer is, don’t let their bean counters tell you how to count your beans, go and see an external accountant.”

The Bank of England is among a number of financial services companies stressing caution when it comes to cloud adoption, in large part because of the often significant cost implications of a security breach, but also because of data sovereignty restrictions within some contexts.