SMBC’s World-First Multi-Cloud/Single-Address Resilience Strategy: How the Bank Built an “Always-On” Email Platform

Today, banking systems have become part of social infrastructure. To be prepared for a system failure, we have to ensure a high level of resilience not only for customer-facing systems like core banking and channel platforms, but also for communications infrastructure like email.

It’s become the norm for email and other communication tools to be cloud-based. Even cloud services used worldwide, though, ultimately still run on physical data centers and server hardware. As long as physical infrastructure exists, we can never entirely eliminate the risk of service disruption.

That’s why concentrating an entire communications infrastructure on a single cloud service isn’t great from a business continuity standpoint. With resilience emerging as a key management strategy, there’s been growing momentum within SMBC to pursue resilience enhancement even in the communication tools used by employees. That led us to explore a resilience plan that would avoid dependence on a single cloud provider by complementing our primary Microsoft environment with an additional cloud platform.

The project began with the recognition that communication tools like email had to be made more resilient so as to respond not just to cyberattacks but also growing geopolitical risks as well as earthquakes and other natural disasters. It’s effectively realizing a business continuity plan (BCP)* for the cloud era.

Email addresses are becoming increasingly important—look at how they’re now being used in security systems to send out authentication codes, for example. Where they were once a supplementary communication tool, now they play a critical role in security measures like phishing prevention, becoming a digital lifeline in their own right.

Different systems have a completely different user experience and feel. We chose Google Workspace as a platform that many people would already be familiar with.

Normally, when two separate email systems are introduced, you need two different email addresses. But that would have placed the burden of our organizational agenda onto our customers, with customers worrying whether emails arriving from an unfamiliar address were fraudulent and the loss of continuity with previous correspondence disrupting smooth communication. We were determined to prioritize customer trust and convenience regardless of the technical difficulty, so we set out to build a system that would allow users to send and receive email using the same address no matter what.

First we asked Google Cloud whether there were any existing cases of two email systems using the same email address. None, we were told. Well, in that case, we would have to design something from scratch. We went straight to Google’s headquarters in Silicon Valley to present our vision and discuss the technical challenges it presented. Google told us that no other financial institution was taking resilience that far—our project would be a world first.

While there were cases of both Microsoft and Google email platforms being used, this was apparently the first time that a backup environment was built using the same email address across both systems for the purpose of resilience.

Cloud services are usually designed as complete ecosystems in themselves, but we had to combine multiple complete cloud platforms without creating incompatibilities. On top of that, the SMBC email system had been in place for so many years that the architecture had become quite complex. During the testing phase, that meant days and days of discussion on specifications, concepts, and policies.

What made the project particularly difficult was that, although Microsoft and Google Workspace are both cloud services, not just their configurations but also their underlying design philosophies are fundamentally different. We had to thoroughly understand both platforms in order to determine which features to keep and which to abandon.

We had to decide just how important each feature was to our system. For example, full integration of Microsoft and Google Workspace causes calendar desynchronization, so we abandoned scheduling and focused on email functionality. Even something as simple as sending an email involves security checks and other background processes. The hardest part was standardizing those processes across both platforms without creating any security loopholes.

Frankly, probably because of the expense of the double investment. A huge number of licenses are also involved, with those costs continuing indefinitely. There were certainly moments when we questioned the wisdom of pressing ahead, but in the end, we decided that the greater resilience justified the cost.

Google Workspace has already been brought into play on multiple occasions now, and users say that it’s been a real lifesaver. We also work with the help desk to ensure that inquiries can be handled smoothly.

If our regular email service fails, we immediately issue an alert through the bank’s intranet and provide a link to Google Workspace so that employees can switch over instantly.

We’ve also had a lot of feedback from the bank’s various systems departments saying how incredibly valuable it is to have a backup method that will never fail. Many of these teams are responsible for high-pressure operations like modifying customer-facing systems or managing large-scale system upgrades. I think that the guarantee of uninterrupted internal communication gives them real peace of mind.

Because the email system is our department’s responsibility, when problems occur, complaints come to us. The fact that those complaints have dropped dramatically shows that the project is delivering meaningful results.

We’ve had inquiries from other banks in Japan, and there’s also been quite a response from financial institutions in Europe and elsewhere. We exchange ideas with domestic institutions from time to time, and the most common response is frank amazement that we managed to pull this off.

When we gave a presentation at Google Cloud Next, which is the global conference that Google Cloud holds in Las Vegas, we got amazing ratings in the post-event survey. Both in Japan and overseas, everyone has been surprised by just how far we’ve pursued resilience, with the project striking a chord with financial institutions in particular. In Asia, we’ve seen strong interest from the perspective of preparing for natural disasters, while in Europe and North America, resilience seems to be viewed more through the lens of geopolitical risk. Overall, our commitment to failproof financial infrastructure really seemed to resonate even with a tech giant like Google, so that it treated us not as just another user but instead as a partner in an extraordinary challenge.

And this wasn’t limited to the initial Google Cloud discussions—group members still visit Google’s US headquarters several times a year. If things go through Google’s Japanese subsidiary, they still need sign-off from headquarters, and that always takes time. By going directly to headquarters, we can discuss functionality on the spot and everything moves much faster, decision-making included.

The single greatest insight we gained from this project is that the most important aspect of defensive DX is creating an environment where business operations can continue even when something fails. There are two keys to achieving that: proactively developing your own means of enabling business continuance, and clearly distributing risk rather than relying on a single vendor.

You can’t accelerate offensive DX without first establishing a solid defensive foundation. Building resilience through the introduction of Google Workspace is what enabled us to move forward aggressively in adopting Google’s generative AI model Gemini. We see the evolution of defensive DX as fundamental to supporting and accelerating the paradigm shift toward offensive DX that is occurring across banking operations, and we will continue to drive forward on both fronts in the years ahead.