HSM for cloud payments: everything you wanted to know

Cloud payments are here to stay

Zilvinas Bareisis: Nearly 60% of financial institutions surveyed in our recent research are being selective about how they are migrating their systems to the cloud. So perhaps some things like core banking platforms are still staying on premise, but almost 40% say that they’re going to migrate very broadly to the cloud. Attitudes certainly have been changing in the last few years. Most banks say that it’s just a matter of time before they start running in the cloud. Before, it was very much a story about hosting and therefore cost reduction. Now it’s becoming increasingly about agility, speed to market, and flexibility. People are starting to realize the very different benefits of the cloud.

We’re still in the relatively early days of full-scale cloud adoption. One of my questions when talking to a lot of different people was: where do we see the likely early adopters? It is helpful to think in terms of where you are as a company. Are you an established company or a greenfield designer? Are you an issuer or an acquirer? And then, in terms of what kind of solution you have in mind. Obviously, if you’re a greenfield company, it’s much easier for you to start in the cloud. There are a lot of fintechs that are born in the cloud. They don’t know anything different, so for them, it’s a very natural choice. If you’re an established bank that has always run your payment infrastructure in house, that’s a different story. You’re probably more likely to start off with a testing environment rather than moving to a full production environment.

The other distinction is between issuers and acquirers. I’d say acquirers have probably been leading the way. Credorax (now part of Shift4) is a good example of that, in terms of really disrupting the industry and being innovative, creative in terms of how to service the merchant side. Issuers are starting to catch up. There’s a lot of change happening in the issuing front as well, but I would say acquirers are probably more likely to be first adopters of cloud-based services.

Companies who work with software vendors like OpenWay are more likely to be early adopters than those working with homegrown apps that are probably deeply embedded into the rest of the infrastructure. Part of the reason is that companies like OpenWay collaborate and work with providers like MYHSM to make sure that their solutions can make use of these offerings and benefit from them.

What are the trends that you at OpenWay have witnessed over the last 12 months, and how have they impacted the payment industry and customer requirements?

Dmitry Yatskaer: There are similar trends across our customers, who are of different scale and working in different payments domains – regardless of whether it is card issuing, merchant acquiring, or digital wallets. OpenWay serves both established companies such as Credorax and Nets in Europe as well as fintech companies like Enfuce, an innovative cloud payments processor in the Nordics, with whom we jointly won the PayTech Award 2019 for Payment Systems in the Cloud. At that time, it was not considered easy to run payments in the cloud.

I would say first thing that over the last 12 to 18 months, due to well-known events, remote has become the new normal. You don’t face many questions about where your team is, because nobody really cares as long as you have good connectivity. And at the same time, it really pushed and accelerated cloud readiness and cloud adoption by the banking and payment industry. We see a similar trend with e-commerce adoption. It has been growing, but then suddenly, it saw a huge boost. The same happened with cloud adoption. The pandemic helped the cloud to become the new normal, rather than something totally innovative. Then, because of it being a quite recent new normal, customers don’t have much experience with it, except for those greenfield cloud-native companies that Zil has mentioned. But if you talk to established banks and payment processors, they want to learn about cloud adoption. We are supposed to provide solutions to fit on many deployment models, on anything, because there is no one-size-fits-all cloud. So we have to be flexible. That’s what we have observed for the last 12 months.

What impact will moving to cloud technology have on payment solutions?

Zilvinas Bareisis: As payments moved to the cloud, the initial premise was to move for cost reasons. But I think people are starting to realize that it’s more about agility. It’s about being able to componetize the solutions and allow clients to put together on the fly what they want to do. It’s not just the cloud, the hosting aspect, but whole technologies like microservices and API connectivity. That’s what allows people to be agile. The other reason why cloud is so critical is resilience. The pandemic showed how critical the resilience of payment systems is. While mainframes are the gold standard for reliability, the cloud can give you built-in elasticity and scalability. Look at what happened with payment volumes, for example, how suddenly they dropped overnight during lockdowns, how varied the drops were, the cross-border volumes versus supermarkets, or the travel sector versus breadmaking machines. Being able to cope with that drastic change in volumes is very difficult without cloud. 

Darren Busby: One of the other key benefits of the cloud is accessibility and removing geographic boundaries. When companies who operate in the cloud and have operations in different locations are deploying their payment solution, new instances will be deployed in new regions virtually immediately. There’s a clear advantage.

With companies using and being born in the cloud, what does this mean for their ability to innovate?

Darren Busby: Сompanies that start off in the cloud don’t have to worry about managing outdated and cumbersome processes that are tied to static on-premise systems. Like cash, the commercial and operational overheads… To give you an example of the payment HSM ecosystem that we provide as a service — the cost of operating and management is totally disproportionate to the cost of the device itself. That’s just one element of what companies need to consider if they want to bring these great ideas to market. For those who are looking to launch new services, choosing that cloud-first strategy frees up the cash and resources that would otherwise be used just to implement and maintain on-premise systems. That cashflow can instead be used to focus on the company’s core business offering, or whatever disruptive technology they have, and to be able to bring that to market, adapt, and innovative very quickly.  

When companies choose cloud technologies, they reap the benefits by combining the value of the existing platform, let’s say Way4 (OpenWay’s platform), with technology enabled by the cloud service provider. So that payoff provides greater reliability and greater flexibility to scale up the infrastructure, because you’re not building redundant capacity to handle peaks. And the amount of investment that cloud service providers put on their services to make them more reliable and resilient is far greater than any one payment company could invest themselves.

What are the most common challenges that payment companies will face if they start deploying cloud-based payment solutions or move their systems to the cloud?

Ilya Dubinsky: If we are to cover the issues by priority, one of the biggest challenges is that many cloud payment solutions and cloud service providers do not really understand the business. Let’s take a generic IaaS provider. They can configure a lot of things to your requirements, certainly. But they won’t be ready to give you PCI-DSS compliance. This is something that is only beginning to appear on the market. If we take a cloud solution that is generic and is not directly connected to the payment business, we are still bound by compliance. This is something that is barely understood out there. But we were born as a technology company, so we have a large technological arm, and we can move systems and migrate with relative ease. So the biggest challenge is that we basically need to tell a lot of vendors how to do things, so that we are compliant with both the payment-specific and the European-specific legislation, GDPR, for instance.

I would say that’s the #1 concern, and the rest are pretty common to other companies: the degree of operational control, the resilience, the maturity of the solution, and the connectivity. But these are not specific to the industry. It’s very easy to throw a bunch of computers out there and provide a good solution to the theoretical problem of sharing computing power, but the gap and the challenge of actually being payment-industry ready is not fully understood by most.

How can companies deliver a full-stack cloud-enabling payment solution to the market?

Dmitry Yatskaer: Well, what we have generally learned is that, if we are not born in the cloud, we have to be as good as being born there. So we have to embrace cloud advantages, starting with the most obvious one, which is just being able to run in the cloud. There, luckily, as we had already architecture for years that was fit for the cloud, there was no real issue.

The other challenge that we had in the very beginning was: where do I place my HSM boxes? Until MYHSM appeared, it was really a serious question. If I place them in my data center, how do I ensure a reliable link to the cloud? If I want to place them in my country, is there a cloud data center nearby? Now this is not an issue. I just need to look at where the closest MYHSM data center is. For Visa and Mastercard access points, of course, you still have to put them somewhere. But in a year from now, hopefully, there will be cloud-based access points as well.

Another interesting aspect of being able to create a cloud offering is that now, by default, you are supposed to offer many different cloud operation models. You are supposed to operate it as much as the customer wants you to operate it. Or you should stay away from operation if that is what the customer prefers, but if they want you to take care of all the PCI DSS compliance, that is what you should do. If they want to do it by themselves, then you must give them smart advice.

So payment solution vendors are expected to fit a multitude of different cloud models anywhere in the cloud, anywhere in the world. If you are good at that, then you can deliver a full cloud solution. 

Intricacies of moving HSMs to the cloud

Zilvinas Bareisis: Some of the research that I have done last year was actually looking into payment HSMs, and specifically, the potential challenges of migrating payment HSMs into the cloud.

I think all of us know how critical HSMs are. They’re mandated by security standards, so you have to use them if you want to offer retail payments. But the challenge is that the cost of running them in your own data center actually adds up. Not only do you need separate HSMs for different environments, whether it’s testing production or backup, you know you have an upfront investment cost, the lifecycle of HSMs. So every 5-7 years you have to upgrade —buy new ones, dispose of the old ones securely. There’s a whole raft of things that you have to do that are not only costly but also require attention from your people.

And that really sort of gets us to the operating costs. You know those HSMs have to be part of your data center, consuming data center resources. But most importantly, you have to have skilled personnel to operate and manage not just the actual hardware, but also the cryptographic keys, which is a really big component that requires specialist knowledge.

On top of that, you have the compliance costs. You have certifications and audits not only just for PCI DSS but depending on the environment in which you operate, it can be PCI PIN Security, PCI Point-to-Point Encryption (P2PE). All of these standards and procedures need to be documented, evidenced. We need to re-certify every 24 months, so you can imagine, that’s quite an overhead. Many companies would just be quite happy to get rid of it.

Payment HSMs historically have been a barrier to actually move payments into the cloud, because even the largest public cloud providers today don’t offer payment HSMs in the cloud due to the specific PCI security standards and other requirements. So you need an alternative approach.

What Payment HSM-as-a-Service does is exactly that. It is an alternative approach to allow people to get the benefits of the cloud while still recognizing and always staying compliant with all the requirements around payment HSMs.

So what’s required to build that as a service? What are the building blocks? Of course, you still need the hardware, like, for example, Utimaco HSMs or other products. You still need to host them somewhere, you still need a data center. There are providers like Equinix and Cystera for that. Essentially, they allow you to be very close to public clouds and thereby maintain low latency and very fast connectivity. You still need to manage keys, but part of the beauty of HSM as a Service is that the provider can help with key management, either essentially offering BYOK (Bring Your Own Key), or by taking it over through Key Management as a Service. There are also other services that differentiate providers, such as how quick the provisioning happens, or which environments are offered. One thing that’s a given is that you have to have all the relevant certifications, compliance and standards.

How can companies deliver a full-stack cloud-enabling payment solution to the market?

Darren Busby: For those who haven’t heard of us, we provide a fully managed service for payment HSMs. It’s not just hosting, racking and stacking HSMs. It’s a fully managed service. We take care of the vast majority of all the responsibilities around payment HSMs. The service itself is a multi-vendor service, fully PCI PIN and PCI DSS certified. It’s got some of the highest availabilities in the market and is globally accessible. We’ve been going now for just two years, but we’re in 30 countries, already with 100% uptime. The service that we have is very relevant to any company in the payment space, whether they’re a brand-new fintech, or an established Tier-1 bank. They can all equally use our service.

We work with a couple of data center providers — specifically, Equinix and Cyxtera. We deploy our payment HSMs in their data centers globally. So we are benefiting from those world-class providers and all the investments they’ve made in their data centers. We stand up the payment HSMs in those and in the UK, we have a service whereby we remotely control, manage and configure and support all of the HSMs geographically around the world, irrespective of where they are. And our clients can all connect to us irrespective of which cloud they’re deployed on, whether it’s a mixture of clouds, or even if they’re connecting from on-premise. It doesn’t really matter. So it’s a really universal service and it is filling in the gap in the public cloud, because as most people are aware, none of the public cloud providers can support payment HSMs.

How does a customer decide between an on-premise, hybrid, or fully managed payment HSM?

Ilya Dubrovsky: We went from using HSM as part of the general processing service to on-premise, and now to the managed solution provided by MYHSM. One reason for these decisions was the availability and maturity of the solutions. It is of course difficult to move something that you’ve bought after all the capex until it burns out, especially with relatively expensive equipment, and with a setup like payment HSMs. But I believe we never shied away from moving to the cloud or from starting the launch a new application in the cloud, that was never a problem.  

The triggers for our specific move were quite obvious. We made some assumptions regarding global stability, which proved to be untrue. There is actually a longer story to it, and it’s a bit dark. We have two data centers: one is located in Frankfurt, and the other one in the United States. During the design and deployment phases, we were always joking that the solution was built to withstand a nuclear attack on the Eastern seaboard. At some point, there was a WWII bomb discovered in Frankfurt about 300 meters from our data center, which had to be evacuated, so that was the end of assumption #1. Then we had this travel freeze, so it was impossible to reach our HSM. We had no remote hands whatsoever. So we looked at the general picture and understood our challenges. We got introduced to the MYHSM solution, and it was a no-brainer from there.

Darren Busby: Yes, that was quite a strong statement by Ilya. Customers are lucky when they have a choice. In this case, they’ve got three choices as to what they do with their payments.

1. They can do what companies have done for decades now: buy on-premise HSMs that they need to feed, water, purchase. They need staff to operate them. These resources are becoming rarer, they have to put them in at least two data centers for resilience and have a number of HSMs across them. The list goes on, the overhead and such.

2. They can get Equinix or someone else to take away the cost of having their own data center, to a degree, but they still have to find a way to be compliant. They still have to ensure that the environment is PSI DSS and PCI PIN certified. They still need people to operate it. They’re still going to buy the machines up front and have that capex. They’ve still got to worry about upgrades, maintenance, the geographic reality, as we pointed out, of actually going to those HSMs and doing stuff on them, so this offers some benefits of co-locating, but it’s not everything.

3. They can choose to outsource it, and that’s where we fit in. It’s a neat model, we take away all that overhead of the payment HSM. These are metal boxes with flashing lights, they sit in the data center and people don’t really care about them. The boxes carry on doing what they’re doing, but if they stop working, you haven’t got a business. So we’ve provided a world-class service. We’ve got a 100% uptime since operating. For those companies looking to make the move, we understand that there’s concerns that they have to do things very differently from what they’re used to. But we’ve got a great track record. We’re working with some of the biggest companies in the world, who have invested millions in their data centers. We’ve got some very skilled staff who are well-versed in payment HSMs, and access to those skills is another benefit of the service that we offer.

So these are the three options available to companies and there’s not much else otherwise.

Is OpenWay’s platform compatible with MYHSM? Does it matter to Way4 whether a Thales HSM or an Utimaco HSM is used for the MYHSM service?

Dmitry Yatskaer: The answer is yes, our digital payment software platform Way4 is compatible with MYHSM. We have successfully run the tests. As for the second question: you just pick what protocol you want to use. If you see there is some kind of pricing difference or advantage in a particular HSM depending on your existing expertise, then it’s really up to you to decide.

What is Visa or Mastercard’s position on cloud-based HSM solutions?

Dmitry Yatskaer: It is neutral, as long as you ensure that you pass PCI DSS compliance or PCI PIN or PCI 3DS. They are fine with them, at least from our experience.

Ilya Dubinsky: I’m not at ease with the usage of the term “cloud HSMs”, because cloud HSMs, in my world, are subpar or unfit for this specific use case — I mean those offered by generic cloud service providers. I saw somebody mention Azure as well, we took a look. They’re not fit for processing PINs. What really matters to schemes, and that’s according to their official documentation, if you need to do the audit, your dedicated PIN auditor must approve your solution. Once you have that, it can be generally anything. Specifically, you probably want it to be one of those cloud HSMs. It will be something like MYHSM’s version.

Is it faster to deploy MYHSM compared to a hardware HSM?

Darren Busby: Without a doubt. We can get our client connected to our service in 3 working days, and if they want to connect to our shared live service, our SLA is 10 working days. You need to contrast that to all the things that need to be done. Not just to get the physical kit installed, but in terms of the infrastructure, the people, the staff, the audience, there’s no comparison.

Ilya Dubinsky: Our biggest challenge with connectivity to MYHSM is properly documenting the architecture and the confirmation from the security team, all the rest is a breeze.

How do PCI security standards work with cloud HSMs?

How can companies whose payment solution is living in a public cloud utilize the MYHSM service and ensure PCI PIN compliance?

Darren Busby: MYHSM service is fully PCI PIN compliant. That doesn’t take the customer out of PCI PIN themselves. They’re still within scope of PCI PIN, but it does mean that a lot of the burden and responsibilities are taken over by MYHSM. When we work with our clients, we work with their QSA when needed to provide the required evidence of PCI PIN certification. We work with Advantio, they’re one of the biggest QSA’s in Europe. And there’s often a benefit where our customers also use Advantio as their QSA. But we can work with any QSA. So the short answer is: it doesn’t take away the reality of PCI PIN, but it does reduce the burden that companies have to carry.

What is the added value of the MYHSM solution for a customer versus the managed one offered by public cloud providers — Azure, for instance, who claims to have all the necessary payment certification?

Darren Busby: I’ve not seen an Azure service that uses payment HSMs that are PCI PIN certified. I know that they have the ambition to provide that as a hosted service, not fully managed, at some point of the future. But I don’t know where they are on that roadmap. The service that Azure provides today is for general purposes and does not support payments.

Dmitry Yatskaer: That is quite a common misunderstanding in the industry, because there is a perception that if there is an HSM offered by a public cloud and if the public cloud is PCI DSS certified, it should be a PCI compliant payment HSM, which is not the case at all. It’s just a general purpose HSM which is good enough to encrypt your PAN and your sensitive customer data on file. But it doesn’t support anything like PIN translation or EMV crypto verification at all.

Ilya Dubinsky: And even if it technically does, you really shouldn’t use it.

Having a solution like MYHSM as part of our offering to our partner ecosystem helps us. We have partners of different sites, some of whom are very experienced in the payment world. Some are just getting started. So if someone goes to them and says: "Yeah, we can do PIN translation, we have this nice cloud HSM, for example…",  we come over and say: “Look, you have to be compliant, this is not compliant at all. There is no physical access controls, you cannot use it for PIN translation. But we can show you a service that can be used.” And this really helps our partners,  because we’ve already vetted this service for them. We know that it is valid and our less experienced partners are having a smooth ride. They just need to implement a specific solution and move on to their next challenge. So we’ve been seeing that our partners are enjoying a major boost to their time-to-market.

How did MYHSM receive the PCI PIN certificate, as it usually needs a physical location for the HSM?

Darren Busby: Well, I guess that is the reason why the public providers can’t provide payment HSMs, because you can’t be on an Amazon or Google data center and expect to do anything there that complies with PCI PIN. We’ve created a set of approved processes, even from opening the box of the HSM, you know it’s dual control. When we follow that blueprint, the service is always PCI PIN certified. It’s a light touch at the data center. And we provide an attestation of compliance to all our clients that they can share to their QSA as evidence of our certification.

How do data residency laws impact the MYHSM service?

Darren Busby: Some countries have data residency laws, so  quite often we get asked by prospective customers how that impacts them, in cases where those countries insist on having data in country. The reality with the MYHSM service is that because we operate payment HSMs, when it comes to data residency, no data resides on the payment HSMs, so we can avoid that one. Any data that’s sent to the HSM is fully encrypted, so it can’t be reverse engineered to identify a person. It’s not classified as personally identifying information either. So we avoid any of those concerns around data residency and data sovereignty because of the nature of how the service works.

On the reliability of cloud HSMs

What happens if the transaction load suddenly increases? Does it have any cost implications for customers, and how does it affect MYHSM and customers in general?

Dmitry Yatskaer: There are different models that we agree on with customers, which are tailored to what they prefer.

For instance, if the customer is managing the software by themselves, typically there is very little dependency on the volume, because all you need is to make sure that your cloud infrastructure can elastically scale, or you can scale it upfront in anticipation of the peak. And the same applies to the HSM’s throughput capacity, which in most cases will exceed your expected peaks. Darren can tell you more about that.

If you prefer the subscription-based model, the SaaS model, then obviously it can be based on the transaction volume, when there is impact. So it depends on the case. 

Darren Busby: Each of the HSMs connected to our service on the shared service is fully licensed, so customers have maximum capacity on the actual service. There are no restrictions on their volumes as such. We invoice them only according to their usage each month. So we don’t have to do anything to the HSM as their volumes grow. 

Dmitry Yatskaer: The practical tests that we have performed show a couple of thousands of authorizations per second, including in the cloud. Then in real life, the fastest and highest value we have managed with our platform is around 4,500 authorizations per second, and in parallel, around 7,000 API calls per second. It is our sincere hope that there will be many more players in the payment industry, both issuers and acquirers, who will enjoy this kind of volume in the future.

Do you offer active-active solutions in each major geographical region, for example, North America and Europe?

Darren Busby: We do offer active-active in many regions. In the US, we’ve got data centers on the East Coast and West Coast, San Jose and Virginia, also in Washington, for our US clients. We also have some Latin American companies connecting to those, and in Europe, we’ve got the UK and Amsterdam. They are all active-active, as I said.

How is latency affecting performance on a fully cloud landscape and payment solution HSMs?

Darren Busby: Latency is probably one of the most common questions that we have, but it’s not just the only consideration when you look at overall performance. Sure, geographic proximity to the HSMs of the payment gateway is a consideration, but it’s not everything. We’ve got customers from Japan to South Africa to South America accessing our HSMs, some of which are in the UK and Amsterdam. They’re operating with great success. But there are also other ways in which the service can be optimized. We offer a best practice with our clients on how they can optimize the use of our service with the payment gateway. We’ve got a data center in each of the different regions, and if required, we can open a new data center depending on what’s needed.

Is there a latency metric that MYHSM can share?

Darren Busby: That’s more like saying how long is a piece of string. It depends on where the customer’s payment gateway is and where they’re connecting to. That can range from a single-digit millisecond roundtrip per call. And if a customer can concatenate all those HSM calls per visitor’s transaction into a single call to the HSM, which many times it can happen, within a business transaction you might have a couple of milliseconds. Some 10 milliseconds is very, very good. It doesn’t even move the needle. But when you’re looking across wider distances there can be latency of 80-90 milliseconds, depending on where the customer is located, and there are various other factors to consider there. But within the whole scheme of things within a business transaction, it’s manageable, and we’ve never had an issue before where customers haven’t been able to transact in a performant manner using our service, irrespective of where they are.

What happens if an HSM goes down?

Dmitry Yatskaer: That’s a good question. If you run Way4 Switch, it’s quite straightforward because we always use at least two HSMs, so if one is down, we just send requests to the one which is up. And if you’d like to be further protected, you can add even more HSMs.

Darren Busby: From our side, we offer a minimum of three HSMs in a group that the client connects to. Each of those HSMs is always active-active across two physically separate data centers. So that’s how they can offer five nines availability if one HSMs goes down. They can always get on a dedicated service and have as many HSMs as they want. But generally, it’s a minimum of three.

Participating companies