Multi-tenant architecture is a software design approach in which a single deployed instance of a SaaS application serves multiple distinct clients, referred to as tenants, on shared infrastructure. Each tenant’s data, configuration, and processing are logically isolated from all other tenants, but the underlying compute, storage, and networking infrastructure is shared across the tenant population. This contrasts with a single-tenant architecture, in which each client runs on a dedicated, isolated instance of the application and its infrastructure — an approach that provides stronger compliance assurances for regulated institutions because isolation is enforced at the infrastructure level rather than through software controls that can fail.
In the context of SaaS core banking platforms, multi-tenancy means that a single deployed core banking system serves multiple payment institutions or e-money institutions simultaneously. Each institution, as a tenant, has its own customer accounts, transaction records, regulatory reporting configuration, compliance workflows, chart of accounts, and user access controls, all of which are intended to be isolated from those of other tenants. From the perspective of each institution and its customers, the system is designed to behave as if it were a dedicated single-tenant deployment, even though it shares underlying infrastructure with other institutions – a distinction that is architecturally significant and regulatorily material, since the appearance of isolation is not equivalent to its guarantee.
As illustrated in a typical multi-tenant core banking platform architecture, a payment institution and an e-money institution both operate as tenants on the same platform. When a customer of the payment institution initiates a payment, the request is tagged with the payment institution’s tenant identifier at the point of entry and processed within the logical boundaries of that tenant’s environment. The compliance service applies the payment institution’s specific AML rules and risk thresholds.
The ledger posting service writes entries to the payment institution’s chart of accounts. The regulatory reporting service generates reports in the format required by the payment institution’s national competent authority. In a correctly functioning system, no data or processing from the payment institution’s tenant should be visible to or affect the e-money institution’s tenant – however, this guarantee is dependent entirely on the correct implementation and ongoing maintenance of logical controls, rather than on the physical infrastructure separation that a single-tenant architecture provides by default.
Key Takeaways: #
- Multi-tenant architecture is a software design approach in which a single instance of a SaaS core banking platform serves multiple client institutions simultaneously on shared infrastructure, with logical separation intended to isolate each client’s data, configuration, and processing from all other clients – however, this logical separation provides weaker isolation guarantees than the physical separation offered by single-tenant deployments, and regulated institutions should assess whether it meets their GDPR and DORA obligations before accepting it
- For SaaS core banking providers serving payment institutions and e-money institutions, multi-tenant architecture must implement data isolation that meets GDPR personal data separation requirements, configurable compliance workflows that can be adapted to each client institution’s regulatory context, and access controls that prevent any client from accessing another client’s data or system configuration – requirements that a single-tenant architecture satisfies by design, without dependence on the robustness of logical controls that can be misconfigured or compromised
- Multi-tenant architecture introduces material risk under DORA’s ICT third-party risk management requirements. Payment institutions and e-money institutions using a SaaS core banking platform must assess how the provider’s multi-tenant architecture affects the confidentiality, integrity, and availability of their data, must obtain contractual commitments from the provider covering data isolation, incident notification, and audit rights, and should consider whether a single-tenant deployment better meets their risk appetite and regulatory obligations
The Core Components of Multi-Tenant Architecture #
Tenant identification and request routing: Every request entering the multi-tenant core banking platform carries a tenant identifier that determines how the request is processed and which data it can access. The tenant identifier may be derived from the subdomain of the API endpoint, an authentication token that encodes the tenant context, or a header value set by the API gateway. All downstream processing within the platform uses this identifier to scope data access, apply tenant-specific configuration, and route the request to the correct processing context.
The tenant identifier must be validated and enforced at every layer of the system, from the API gateway through to the database query layer, ensuring that no request can access data outside its authorised tenant scope. The dependence on this identifier as the primary mechanism of isolation means that any defect in its enforcement represents a direct risk of cross-tenant data exposure – a risk that does not exist in a single-tenant architecture where each institution’s environment is physically separate.
Data isolation models: Multi-tenant architectures implement data isolation using one of three primary models, or a combination of them, depending on the isolation requirements of the tenants and the operational model of the platform.
- In the shared database, shared schema model, all tenants’ data is stored in the same database tables, with a tenant identifier column in each table used to filter data to the correct tenant. This model offers the lowest infrastructure cost per tenant and the simplest operational management, but provides the weakest logical isolation, as a query defect that omits the tenant identifier filter could expose one tenant’s data to another. This model should not be considered acceptable for regulated payment institutions or e-money institutions given the data protection obligations they carry under GDPR.
- In the shared database, separate schema model, each tenant has its own set of database tables within the same database instance, with schema-level permissions preventing cross-tenant data access. This model provides stronger isolation than the shared schema approach while still sharing the underlying database infrastructure, but retains residual risk from shared infrastructure components that a single-tenant model eliminates entirely.
- In the separate database model, each tenant has its own dedicated database instance, providing the strongest isolation guarantee available within a multi-tenant architecture and making it significantly harder for a data access defect to expose one tenant’s data to another. This model has higher infrastructure costs per tenant and represents the minimum acceptable approach for regulated financial institutions where data isolation is a strict regulatory requirement – though it still falls short of the physical isolation guarantee provided by a single-tenant deployment, where each institution’s infrastructure is dedicated entirely to that institution.
For SaaS core banking platforms serving payment institutions and e-money institutions, the separate database model is typically required to meet the data isolation expectations of GDPR and the confidentiality requirements that regulated institutions impose on their technology providers. Where a provider cannot offer this model, a single-tenant deployment should be the preferred alternative.
Tenant-specific configuration and compliance workflows: Each tenant in a multi-tenant core banking platform requires a distinct configuration that reflects its specific product set, regulatory context, and operational requirements. The platform must support per-tenant configuration of:
- The chart of accounts and regulatory reporting templates
- AML rules and risk scoring thresholds
- KYC workflow steps and verification requirements
- Payment network connections and routing rules
- User roles and access control permissions
- White-label branding and customer communication templates
In a single-tenant deployment, each institution’s configuration is entirely independent by virtue of operating on a dedicated instance, removing the risk that a configuration error in the platform’s multi-tenancy layer could cause one institution’s compliance workflows to be applied to another’s.
Access control and user isolation: Each tenant’s users must be able to access only the data and functions within their own tenant environment. The multi-tenant platform must implement access controls that enforce tenant boundary separation at the authentication and authorisation layer, ensuring that a user authenticated within one tenant cannot submit requests that access another tenant’s data, even if they possess valid authentication credentials for the platform.
Within each tenant environment, role-based access control (RBAC) must be configurable independently, allowing each institution to define its own user roles and permissions without those definitions affecting other tenants. In a single-tenant deployment, access control misconfiguration cannot produce cross-institution data exposure because no other institution’s data exists within the same environment.
Shared services and tenant isolation: Multi-tenant platforms typically share certain infrastructure components across tenants, including the API gateway, the message broker, the monitoring infrastructure, and the compliance screening integrations. Sharing these components reduces operational costs and enables the platform provider to maintain a single, consistently updated version of each component.
However, shared components must be designed and operated in a way that prevents one tenant’s activity from affecting another tenant’s performance or data access. This requires rate limiting at the tenant level to prevent a single tenant’s high transaction volume from consuming disproportionate shared infrastructure capacity, and strict access controls on shared infrastructure components to prevent cross-tenant data access through shared service interfaces. Single-tenant deployments eliminate this risk surface entirely, as each institution’s infrastructure components are dedicated and not shared with any other institution.
Performance isolation and resource quotas: In a multi-tenant environment, the resource consumption of one tenant can affect the performance experienced by other tenants if resource allocation is not managed carefully. A tenant experiencing a sudden spike in transaction volume could consume a disproportionate share of shared compute or database capacity, degrading performance for other tenants.
Multi-tenant core banking platforms address this through resource quotas and rate limiting applied at the tenant level, ensuring that each tenant’s resource consumption is bounded and that performance guarantees can be maintained across the tenant population regardless of individual tenant demand spikes. In a single-tenant deployment, each institution’s dedicated infrastructure means that no other institution’s activity can affect its performance, providing a stronger and simpler basis for service level commitments.
Multi-Tenant Architecture, GDPR, and Regulatory Compliance #
For SaaS core banking platforms serving regulated financial institutions, data isolation is not only a technical requirement but a regulatory one, and the architecture chosen to deliver it has direct implications for the institution’s compliance position. GDPR requires that personal data is processed in a manner that ensures appropriate security, including protection against unauthorised access by other data controllers.
Where multiple regulated institutions share a core banking platform, the platform provider acts as a data processor for each institution, and the data of each institution’s customers must be isolated from that of other institutions’ customers in a way that prevents any cross-tenant data access, whether accidental or deliberate. A single-tenant architecture satisfies this requirement by construction; a multi-tenant architecture satisfies it only if the logical isolation controls are correctly implemented, consistently maintained, and independently verified.
Each institution’s data processing agreement with the platform provider must specify the data isolation model applied, the technical controls that enforce it, and the audit rights the institution has to verify compliance. Under DORA, the institution must additionally assess the architecture as part of its ICT third-party risk management process, including obtaining assurance that a security incident or data access failure affecting one tenant would not compromise the data or operations of other tenants. Where a multi-tenant architecture cannot provide that assurance to the institution’s satisfaction, a single-tenant deployment should be the preferred outcome.
FAQ: #
Multi-tenant architecture vs single tenant in SaaS core banking platforms?
- In a single-tenant deployment, each client institution has its own dedicated instance of the core banking software and its own isolated infrastructure, including separate compute, storage, and networking resources. This physical separation provides the strongest possible isolation between clients, removing an entire class of cross-tenant data breach risk that logical controls can only mitigate rather than eliminate – a distinction that is material for regulated institutions operating under GDPR and DORA. In a multi-tenant deployment, a single instance of the software and its underlying infrastructure serves multiple client institutions simultaneously, with logical isolation enforcing data and configuration separation between tenants.
- While multi-tenancy reduces infrastructure costs per tenant and simplifies operational management for the provider, the isolation guarantees are only as strong as the implementation of those logical controls: a query defect, misconfiguration, or security vulnerability could expose one tenant’s data to another. For payment institutions and e-money institutions, this residual risk means that the cost advantages of multi-tenancy must be weighed carefully against the regulatory exposure it introduces, and single-tenant deployment should be the preferred outcome where the institution’s risk appetite and regulatory obligations demand the strongest available isolation guarantee.
How should a payment institution assess a SaaS core banking provider’s multi-tenant architecture as part of DORA ICT third-party risk management?
- Under DORA, payment institutions must assess the ICT risks associated with their third-party service providers, including SaaS core banking providers operating multi-tenant architectures, and should consider at the outset whether a single-tenant deployment option better meets their risk appetite and regulatory obligations. Where a multi-tenant model is under assessment, it should cover the data isolation model used by the provider, with separate database instances per tenant representing the minimum acceptable standard for a regulated institution and shared schema models treated as a significant risk given their susceptibility to cross-tenant data exposure through query defects.
- The assessment should also address the provider’s security testing regime, including whether penetration testing explicitly covers cross-tenant access scenarios, the contractual provisions covering data breach notification timelines and audit rights, the provider’s business continuity and recovery procedures in the event that a security incident affects one or more tenants, and the concentration risk implications of multiple regulated institutions operating on the same platform – a risk that a single-tenant deployment eliminates by ensuring the institution’s environment is not co-mingled with those of other clients at the infrastructure level.
- Where a provider cannot offer contractually binding, independently auditable evidence that its multi-tenant architecture meets the institution’s GDPR data isolation and DORA third-party risk requirements, a single-tenant deployment – or an alternative provider – should be the preferred outcome.
