IBM executive sets out active-active cloud model for core banking

Srini Bala, a partner and industry leader at IBM, has argued that banks running critical ledgers need active-active hybrid multi-cloud architectures as regulatory scrutiny of operational resilience rises. In an external opinion published on Finextra, Bala said passive disaster recovery arrangements can leave institutions exposed to outages lasting 15 to 30 minutes before full service is restored.

Bala framed the issue around systems of record, including core banking ledgers, where availability cannot come at the expense of transaction consistency. He cited Europe’s Digital Operational Resilience Act and updated guidance from US federal regulators as examples of a tougher supervisory stance toward technology concentration risk at large financial institutions.

According to Bala, relying on one cloud provider, or on one cloud region backed by a standby disaster recovery site, creates unacceptable risk for Tier-1 banks. A regional failure at a primary provider could disrupt card payments and point-of-sale activity during the period needed to activate a passive environment, he wrote.

How the proposed model works

The architecture Bala described routes, processes and validates transaction traffic at the same time across separate public cloud platforms and on-premises environments. In this active-active model, more than one environment remains live, rather than keeping a secondary site idle until a failure occurs.

The technical constraint is data consistency. Bala said stateless web applications can be spread across clouds more readily, while bank ledgers are tied to data gravity and the requirement for a single authoritative account balance. He said banks cannot permit a customer to spend the same funds twice because separate cloud environments hold different views of the ledger.

To address that problem, Bala pointed to globally distributed, strictly serializable SQL databases, naming Google Spanner and CockroachDB as examples. These systems use consensus protocols such as Paxos or Raft, along with precise time synchronisation, to validate and commit transactions across a majority of nodes, according to his analysis.

That approach differs from traditional synchronous database locking, which Bala said can slow transactions when systems are spread over long distances. Distributed consensus is intended to preserve a single transaction order without depending on one central data centre.

Routing, compute and network layers

Bala set out three infrastructure layers for banks considering such a design. At the edge, he proposed cloud-neutral global server load balancing and Anycast routing to monitor health, latency and capacity across environments such as AWS, Azure and private cloud infrastructure.

For compute, he said banks should standardise applications on enterprise Kubernetes platforms, citing Red Hat OpenShift as an example. Containerisation allows the same core banking code to run across private servers and public cloud infrastructure, according to Bala.

For connectivity, he argued for dedicated private links, including AWS Direct Connect and Azure ExpressRoute, tied through carrier-neutral facilities. The purpose is to keep replication traffic for ledger synchronisation off the public internet and maintain low-latency communications between environments.

Data sovereignty constraints

Bala also addressed the limits imposed by national data rules. He said some jurisdictions restrict sensitive customer information from leaving national borders, which complicates global cloud routing for banks.

His proposed response is to place masking and tokenisation proxies at local network edges. Under that model, personally identifiable customer data remains in on-premises data centres or sovereign cloud zones within the relevant country, while non-identifiable transaction data is synchronised across the wider cloud network, according to Bala.

This story draws on original reporting from Finextra Research.