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
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
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
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)
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
| Choice | You gain | You give up |
|---|---|---|
| Keep a workload on-premises | Full control and simple residency | Slower capacity changes and hardware to own |
| Move it to public cloud | Elastic capacity and managed services | Outsourcing obligations and dependence on a provider |
| Single cloud provider | One set of skills and tools | Concentration risk and harder exit |
| Several providers | Less dependence on any one | More 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?