On this page
  1. Why it matters
  2. The model explained
  3. How it plays out in Indian banking
  4. Trade-offs
  5. Failure modes
  6. When to use it, and when to avoid it
  7. Questions for a design review

Why it matters

Cloud platforms offer capacity on demand, managed services and fast environments for development. Banks also carry obligations that do not move to the provider: data residency, security, resilience and the ability to leave. Most banks therefore run a hybrid estate, keeping some systems in their own data centres and putting others in the cloud. The architecture question is which workload goes where, and how the pieces connect safely.

This page describes general patterns. It does not describe any organisation’s actual estate.

The model explained

Three kinds of place

On-premises means the bank’s own data centres and hardware. Private cloud means cloud-style automation on infrastructure dedicated to the bank, in its own premises or a provider’s. Public cloud means shared infrastructure from a provider, rented by the hour. A community cloud is shared among a defined group, such as banks of one type.

Placing workloads

A useful first sort uses two questions: how sensitive is the workload, and how much does it benefit from elastic scale?

A first cut at workload placement

Workload placementWorkloads placed by elasticity need and data sensitivity. The core ledger and payment interfaces are high sensitivity and low elasticity. Mobile backends and analytics need more elasticity with moderate sensitivity. Development and test and a marketing site are low sensitivity with high elasticity. Steady loadSpiky load Less sensitive More sensitive Own data centre or private cloudPrivate or tightly controlled cloudEitherPublic cloud Core ledgerPayment interfacesMobile backendAnalyticsDev and testMarketing site
Text description
  • Core ledger: Steady load, More sensitive
  • Payment interfaces: Steady load, More sensitive
  • Mobile backend: Spiky load, More sensitive
  • Analytics: Spiky load, Less sensitive
  • Dev and test: Spiky load, Less sensitive
  • Marketing site: Spiky load, Less sensitive
Illustrative. Real placement also weighs latency, cost, skills and regulatory approval.

Connectivity and identity

Workloads in different places must talk to each other securely and predictably. Private, dedicated links between the bank’s data centres and the cloud region carry traffic that should never cross the public internet, usually over two separate paths. Identity federation lets staff and services use one identity across both environments, so access is granted and removed in one place.

Connecting a data centre to a cloud region

Hybrid connectivityThe bank data centre holds core banking and the identity provider. A cloud region in India holds channel services and analytics. Core banking and channel services exchange API calls over private links, and the identity provider federates sign-in to the cloud services. private links federated sign-in Core banking Identity provider Channel services Analytics Bank data centreCloud region in India
Text description

The bank data centre holds core banking and the identity provider. A cloud region in India holds channel services and analytics. Core banking and channel services exchange API calls over private links, and the identity provider federates sign-in to the cloud services.

  • Bank data centre: Core banking, Identity provider
  • Cloud region in India: Channel services, Analytics
  • Core banking and Channel services: private links
  • Identity provider to Analytics: federated sign-in (optional or asynchronous)
Illustrative and generic.

Making the exit plan real

An exit plan is only useful if it can be carried out. That means knowing, for each workload, which provider-specific services it depends on and what would replace them; keeping data in formats that can be exported; and holding enough skills in-house to run the workload elsewhere. Some banks rehearse exit by periodically restoring a workload’s backups into another environment and running it there. The cost of exit is lowest when it is considered at design time, before the workload has grown around one provider’s features.

Multi-cloud

Using more than one cloud provider can reduce dependence on one supplier and give a way out if a relationship ends. It also multiplies skills, tooling, security configurations and network links. Many banks use multiple providers for different workloads rather than running the same workload across several.

Cost governance

Cloud costs grow quietly: idle environments, oversized instances, data moving between regions. Tagging every resource to an owner, setting budgets with alerts and reviewing spend regularly keep the bill tied to value.

How it plays out in Indian banking

For a regulated entity, cloud is a form of outsourcing. RBI's IT outsourcing Direction counts cloud computing services as outsourced IT services and adds specific requirements for storing, computing and moving data in the cloud.1Reserve Bank of India. Master Direction on Outsourcing of Information Technology Services (RBI/2023-24/102). As of 10 April 2023. When using cloud services, a regulated entity's outsourcing policy must cover the whole lifecycle of data, from creation and entry into the cloud until it is permanently deleted.1Reserve Bank of India. Master Direction on Outsourcing of Information Technology Services (RBI/2023-24/102). As of 10 April 2023. RBI's Direction describes cloud security as a shared responsibility between the regulated entity and the cloud service provider.1Reserve Bank of India. Master Direction on Outsourcing of Information Technology Services (RBI/2023-24/102). As of 10 April 2023.

Where payment data may be stored limits where some workloads can run: RBI's circular of 6 April 2018 requires payment system providers to store the entire data relating to their payment systems only in India; data on the foreign leg of a transaction may also be stored abroad.2Reserve Bank of India. Storage of Payment System Data (RBI/2017-18/153). As of 6 April 2018. And every arrangement needs a way out: A regulated entity's outsourcing policy must include termination processes and exit strategies, including business continuity if a service provider leaves the arrangement.1Reserve Bank of India. Master Direction on Outsourcing of Information Technology Services (RBI/2023-24/102). As of 10 April 2023.

Shared platforms are not new in Indian banking. IFTAS's Indian Banking Community Cloud provides core banking and other applications, such as SFMS and mobile banking, as web services.3Reserve Bank of India. Chief Executive Officer (CEO) for Indian Financial Technology and Allied Services (IFTAS). As of 20 September 2022.

Trade-offs

Deployment choices
ChoiceYou gainYou give up
Keep a workload on-premisesFull control and simple residencySlower capacity changes and hardware to own
Move it to public cloudElastic capacity and managed servicesOutsourcing obligations and dependence on a provider
Single cloud providerOne set of skills and toolsConcentration risk and harder exit
Several providersLess dependence on any oneMore complexity, cost and security surface

Failure modes

  • Accidental exposure through a misconfigured storage bucket or network rule in the cloud.
  • Data outside approved locations, for example backups or logs replicated to another region.
  • An exit plan that exists only on paper, never tested and dependent on provider-specific services.
  • Hidden coupling, where an on-premises core cannot work without a cloud service, or the reverse, making both a single point of failure.
  • Cost overruns from resources nobody owns.

When to use it, and when to avoid it

Use public cloud for workloads that benefit from elastic scale, such as channels, analytics and development environments, once the outsourcing, security and residency requirements are met. Keep the systems of record where the bank has the strongest control and the clearest exit path, unless a considered risk assessment says otherwise. Avoid moving a workload only because it is fashionable; move it because the gain is clear and the obligations are covered.

Questions for a design review

  • Why does this workload belong where it is placed, in one sentence a regulator would accept?
  • Where will its data, backups and logs physically reside?
  • Which controls are the bank’s responsibility and which are the provider’s?
  • How would the workload leave this provider, how long would it take, and has that been tested?
  • Who owns each cloud resource and its cost?

Sources

  1. Master Direction on Outsourcing of Information Technology Services (RBI/2023-24/102). Reserve Bank of India. Primary source, accessed 29 September 2026. Supports: RBI's IT outsourcing Direction counts cloud computing services as outsourced IT services and adds specific requirements for storing, computing and moving data in the cloud (as of 10 April 2023); When using cloud services, a regulated entity's outsourcing policy must cover the whole lifecycle of data, from creation and entry into the cloud until it is permanently deleted (as of 10 April 2023); RBI's Direction describes cloud security as a shared responsibility between the regulated entity and the cloud service provider (as of 10 April 2023); A regulated entity's outsourcing policy must include termination processes and exit strategies, including business continuity if a service provider leaves the arrangement (as of 10 April 2023).
  2. Storage of Payment System Data (RBI/2017-18/153). Reserve Bank of India. Primary source, accessed 29 September 2026. Supports: RBI's circular of 6 April 2018 requires payment system providers to store the entire data relating to their payment systems only in India; data on the foreign leg of a transaction may also be stored abroad (as of 6 April 2018).
  3. Chief Executive Officer (CEO) for Indian Financial Technology and Allied Services (IFTAS). Reserve Bank of India. Primary source, accessed 29 September 2026. Supports: IFTAS's Indian Banking Community Cloud provides core banking and other applications, such as SFMS and mobile banking, as web services (as of 20 September 2022).