Multitenancy is an important feature of modern cloud native core banking systems (CNCBS). Customers looking to adopt a new CNCBS need to look out for this from the get-go.
Typically, core banking systems are targeted at two broad categories of clients – fully regulated banks and fintechs. Fully regulated financial institutions usually want to run the cloud native core banking system in their private cloud. Depending on the level of regulatory and security requirements, some fintechs may be content to run in a public cloud environment.
For public cloud deployments, multitenacy is clearly a requirement or else the CNCB provider would not be able to offer the service. For a regulated bank deploying a CNCBS in its private cloud, multitenancy is still an important requirement, even though it may first appear that the solution will be used by only one entity. I will explain why.
Regulated banks may operate across different jurisdictions and regions, and have different brands corresponding to different legal entities. They may offer banking as a service (BAAS) or white label banking. The parent bank may want to run a single instance of the CNCBS in its private cloud to gain the cost efficiencies resulting from the high resource utilization of cloud infrastructure. But it would still require logical data isolation for the different entities afforded by a multitenant architecture. Each legal entity owned by the parent bank using the CNCBs would require its own tenant key.
What this means in for the system’s APIs is that a cryptographically secure tenant key has to be used in API calls to identify which entity or tenant the request is for. The APIs are a good place to look to understand how the platform treats multitenancy. Although architectures may differ, typically you would expect to see 2 things – one API key for the user (customer, service operator, etc), and one API key – tenant key – that identifies the entity.