Traditional FSIs are embracing the public cloud one project at a time

The public cloud has been great to fintech start-ups keen to disrupt the stodgy financial sector, but traditional players like banks and stock exchanges are also dipping their toes in the public cloud – and loving it.

Image courtesy of Hong Kong Stock Exchange

When Amazon Web Services organized last week’s online Financial Services Cloud Symposium for existing and potential customers in the financial services field, the line-up was more or less what you’d expect – a blend of AWS sales pitches and customer testimonials. The latter ranged from start-ups like B2B payment gateway YedPay, white-label insurance platform CoverGo and cryptocurrency service provider Crypto.com to more traditional financial services players like HSBC and Hong Kong Exchange (HKEX).

Use cases varied, but there were a couple of common themes (apart from AWS): (1) traditional financial players are learning to love the public cloud, and (2) they’re learning to love it one step at a time rather than going all in – at least for now.

Event-driven data lake

For example, HKEX is using AWS to build a data lake that also functions as a data-as-a-service platform for monetization purposes.

According to HKEX data architect Derek Yeung, the basic objective is to construct a cloud-native data lake and analytics platform that bridges the gap between HKEX’s existing data warehouse (where all its fully governed data resides) and its application database archive (where all raw data is stored, inaccessible to most people) by making more raw data accessible in real time so that users can play with it and create refined data sets that have business value.

“Sourcing data should be just as simple as going to a data warehouse for approval, and then the data is on your way and then you can make use of it as a business case and realize business value on top of it, rather than in the traditional fashion, where you talk to your technology friends and it takes them couple weeks or even months to pull this data out for you,” Yeung said.

The data lake project is also designed with monetization firmly in mind, Yeung added. “We definitely want to monetize our data by offering some external APIs to our participants, but also setting up a data marketplace, so that we can start to develop a bit more of a product mindset around data.”

At the same time, that can’t come at the expense of compromising on privacy and security, not least because HKEX is already beholden to strict regulatory compliance, which is why data ops is a key component of the project as well. This not only ensures data is protected and properly tagged, but also easy to trace and locate in case, for example, someone files a “right-to-be-forgotten” request under GDPR.

Yeung said that the public cloud enables the usual benefits like greater scalability and flexibility to optimize storage and compute costs: “We estimate public cloud will allow us to realize a 6x reduction in data costs compared to doing the same thing on-premise.”

Moving forward, HKEX wants to leverage AWS to adopt an event-driven architecture for its data lake (which has already been designed to capture data as ‘events’) to enable it to build different types of data and analytics products.

“We see a lot of benefits by doing that,” Yeung said. “The total cost of ownership will dramatically decrease, because we won’t need to look after our own infrastructure anymore – that will be AWS’s job. It also allows us to do things in a way more agile fashion. It’s also easy to trace how the application goes across each of the microservices. And it really makes it easier for us to move into a hybrid-cloud, multi cloud strategy.”

Wealth management in the cloud

Meanwhile, Joseph Mak, Cloud Engineering Lead for Wealth Management IT at HSBC, described how his company migrated its wealth management platform onto AWS last year – which, as it happens, was HSBC’s first venture into the public cloud after deciding to adopt a “cloud first” strategy for any development of new apps.

The reason for cloud-first, Mak said, is that customer demand is growing and changing exponentially, and HSBC needs a platform that can anticipate and respond to that demand.

“We also wanted to migrate our applications to a cloud-native architecture, which basically means changing to a microservices architecture, where we move away from the traditional monolithic system design that we had towards a more modular design, where all our applications are run as microservices and they can benefit from the latest technology advances,” he said.

For all that, HSBC approached the public cloud with caution, starting with just the Wealth Management platform, and only in one country out of the 16 where it is available, Mak said.

“When we began the journey over a year ago, we hardly knew anything about AWS. We had not deployed any application on AWS before, but we took the plunge,” he said.

The Wealth Management IT team followed a seven-step process: define the architecture for its applications, deploy the cloud infrastructure in AWS using Terraform, change everything to cloud-native microservices running as Docker containers in Kubernetes, deploy everything using a unified CI/CD pipeline, automate as much as possible, implement monitoring tools to make sure that everything is running smoothly, and write run books for production support team members.

In all, the entire Wealth Management platform was deployed into AWS in about nine months, and went live in November 2019.

Mak said the differences between running Wealth Management on public cloud vs on-prem are dramatic, particularly in terms of automation, elastic infrastructure costs and giving the wealth management IT DevOps team full control over most of the infrastructure.

He added that the project was so successful that all of HSBC’s remaining wealth management platform applications across the globe will also be migrated into AWS.

Cloud security: it’s fun to share

Not unexpectedly, a common denominator of each session was security, which is not only a mandatory requirement for financial services of any kind, but also one of the key reasons why traditional financial institutions have balked at the notion of putting anything into any cloud they didn’t have direct and exclusive control over. But that has changed as public cloud providers of all stripes have gone out of their way to promote their security features.

Thomas Kung, Director of Information Security at Crypto.com (which offers various cryptocurrency services), highlighted the security features within AWS’ Well Architected framework, including identity and access management, detective controls, infrastructure protection, data protection and incident response – all of which Crypto.com uses as part of its cloud infrastructure.

However, he added, the secret to getting security right is to have a clear understanding of the “shared responsibility” model in which both the cloud provider and the customer have specific roles to play. 

“We need to understand the cloud shared responsibility model – this is a pain point for all professionals on security compliance, because we need to figure out what are the security responsibilities that we have when we engage with a cloud vendor,” Kung said.

One key reason this matters is that the level of responsibility the cloud provider covers will depend on which of its apps or services you’re using, he explained.

“For example, if we engage AWS to use ECS or Fargate as the container service model, these two service offerings have different security responsibilities to the customers. If we choose to use ECS, because we have access to the Docker host, we need to cater to the security controls of the Docker host, as well as the containers running on it,” Kung said. “However, if we choose to use Fargate, we don’t need to cater to the security level of the Fargate infrastructure because this is provided by AWS. So the boundary of the cloud shared responsibility model is blurred.”

Joseph Mak described how HSBC shared security responsibilities with AWS for its Wealth Management migration, with AWS handling security for its managed services like RDS, the actual hardware, and the data centers in which they sit. Everything else was handled by HSBC by two different teams – the DevOps team from Wealth Management IT handled IaaS services like EC2 instances, and all security issues related to accounts, while HSBC’s central global cloud services team managed everything else, including the leased lines between HSBC data centers and AWS data centers and a compliance framework to continuously monitor accounts.

For HSBC, the shared responsibility model ended up being the best of both worlds, enabling HSBC to keep control of account security whilst still being able to outsource some responsibilities to AWS. “AWS managers run lots of the managed services for us. So if you need help with any of the managed services or with any of your accounts, you can also go directly to AWS and ask for help,” Mak said.

- Advertisement -