Last reviewed · Version 1.0.0 · Evidence cutoff
Core banking deployment topology and regulatory alignment — multi-tenant SaaS vs single-tenant in customer cloud account
This buyer guide compares deployment topology, not vendor quality. The two reference patterns are Topology A — multi-tenant SaaS in a vendor-controlled cloud environment and Topology B — single-tenant deployment in a customer-controlled cloud account or private-cloud boundary. The guide is written for regulated institutions that must evidence outsourcing classification, auditability, exit, data-location control and concentration-risk management before putting a core ledger, account platform or payment core into production. It does not rank products, does not claim that either topology is automatically compliant, and does not treat cloud as a proxy for weak control. The governing regulatory point is the same across the regimes reviewed: the regulated firm remains accountable for the service, even where technology operation is outsourced. DORA Article 28 requires financial entities to manage ICT third-party risk as part of their ICT risk-management framework and remain fully responsible for compliance obligations (DORA Regulation (EU) 2022/2554, accessed 2026-05-08). The EBA outsourcing guidelines state that outsourcing does not lower institutions’ and payment institutions’ obligation to comply with regulatory requirements (EBA Guidelines on outsourcing arrangements, accessed 2026-05-08).
Corebanq is the Finray Technologies Limited product in the single-tenant-in-customer-cloud topology. Corebanq is recused from any qualitative ranking on this page. The analysis is about the topology category, not Corebanq specifically. Vendor pages are used only to identify public deployment claims: Mambu describes itself as a cloud-based composable banking architecture and separately describes a multi-tenant SaaS engine (Mambu documentation, accessed 2026-05-08; Mambu architecture article, accessed 2026-05-08); Thought Machine states that Vault Core can be delivered as SaaS, bank-hosted public cloud, private cloud or hybrid deployment (Thought Machine Vault Core, accessed 2026-05-08); Tuum’s developer portal describes an API-first core-banking solution offered as SaaS and its documentation refers to multi-tenant logic (Tuum Developer Portal, accessed 2026-05-08; Tuum getting started, accessed 2026-05-08); SaaScada describes a cloud-native core banking platform but the source pass did not locate a primary public architecture document proving multi-tenant SaaS (SaaScada platform, accessed 2026-05-08); Corebanq’s public page lists multi-tenant managed cloud, single-tenant dedicated cloud, and enterprise private-cloud/on-premise models (Corebanq product page, accessed 2026-05-08).
Topology comparison
1. Outsourcing classification
Under DORA, the starting point is not tenancy. It is whether the arrangement is an ICT service supporting a financial entity, whether it supports a critical or important function, and whether the firm has performed risk assessment, due diligence, register-of-information recording and contractual control. Article 28 requires a strategy for ICT third-party risk, a register of contractual ICT arrangements, due diligence before contracting, and concentration-risk assessment for services supporting critical or important functions (DORA Article 28, accessed 2026-05-08). The EBA guidelines define a harmonised outsourcing framework for institutions, payment institutions and electronic money institutions and focus on whether a service provider performs a process, service or activity that would otherwise be undertaken by the institution (EBA outsourcing guidelines, accessed 2026-05-08). PRA SS2/21 similarly defines outsourcing by performance of a process, service or activity that would otherwise be undertaken by the firm, and expressly covers cloud and third-party risk management (PRA SS2/21, accessed 2026-05-08). FINMA Circular 2018/3 defines outsourcing by independent and ongoing performance of significant functions for banks, insurers and financial institutions (FINMA Circular 2018/3, accessed 2026-05-08). Structurally, Topology A is usually easier to classify as outsourcing because the vendor controls more of the runtime, operating processes and release management. Topology B may still be outsourcing if the vendor operates, monitors, updates or materially supports the core; if the customer merely licenses software and operates it internally, some regimes may treat parts of the stack differently. A primary-source rule stating that customer-cloud single-tenancy is automatically non-outsourcing was not located; status: primary-source-not-located.
2. Critical Third-Party Provider designation under DORA Article 31
DORA Article 31 gives the ESAs power to designate critical ICT third-party service providers using criteria including systemic impact if the provider fails, the systemic character of financial entities relying on the provider, the extent to which services support critical or important functions, and substitutability or migration difficulty (DORA Article 31, accessed 2026-05-08). The implementing designation criteria further state that subcontractors can be assessed and that the ESAs should use registers of information and other available information in the assessment (Commission Delegated Regulation (EU) 2024/1502, accessed 2026-05-08). The ESAs published the first Union list of designated CTPPs in November 2025; it includes cloud, infrastructure, data, technology and business-service providers such as Amazon Web Services EMEA, Google Cloud EMEA, Microsoft Ireland Operations, Oracle Nederland, FIS and others (ESA CTPP announcement, accessed 2026-05-08; List of designated CTPPs, accessed 2026-05-08). Topology A can aggregate concentration at the core-banking SaaS vendor and again at its underlying cloud provider. Topology B can reduce aggregation at the application operator if each bank controls its own account, but it does not remove cloud concentration if many banks use the same hyperscaler or managed services. DORA does not state that either topology avoids CTPP analysis; the assessment is provider-, service- and reliance-based.
3. Audit rights
DORA Article 30 requires ICT contracts supporting critical or important functions to include unrestricted rights of access, inspection and audit for the financial entity, appointed third parties and competent authorities, plus cooperation during onsite inspections and audits (DORA Article 30, accessed 2026-05-08). The EBA guidelines require full access to premises, systems, networks, information and data for critical or important outsourced functions, while recognising practical constraints in multi-tenant environments and permitting pooled audits or third-party certifications only where they remain sufficient and do not replace retained individual audit rights (EBA outsourcing guidelines, accessed 2026-05-08). FCA SYSC 8 requires firms to avoid outsourcing that impairs controls or regulator monitoring, and FCA FG16/5 states there is no fundamental reason public cloud cannot comply with FCA rules if properly considered (FCA SYSC 8.1, accessed 2026-05-08; FCA FG16/5, accessed 2026-05-08). FINMA requires contractual inspection and audit rights and requires that outsourcing not make FINMA supervision more difficult (FINMA Circular 2018/3, accessed 2026-05-08). In Topology A, audit evidence usually depends on vendor-controlled logs, attestations, security reports, inspection procedures and contractually arranged access. In Topology B, the customer can usually inspect its own cloud account, IAM, network controls, backup stores and telemetry directly, but still needs vendor audit rights for software development, release, support and managed-service components. A regulatory source saying topology alone satisfies audit-right obligations was not located.
4. Sub-contractor chain
DORA Article 30 requires contracts to state whether subcontracting of ICT services supporting critical or important functions is permitted and under what conditions, including locations where contracted or subcontracted functions and data processing or storage are provided (DORA Article 30, accessed 2026-05-08). Article 29 requires financial entities to assess whether long or complex subcontracting chains may affect monitoring capability and supervisory effectiveness (DORA Article 29, accessed 2026-05-08). The DORA subcontracting RTS located at this cut-off is Commission Delegated Regulation (EU) 2025/532, which specifies elements to determine and assess when subcontracting ICT services supporting critical or important functions (Commission Delegated Regulation (EU) 2025/532, accessed 2026-05-08). Commission Implementing Regulation (EU) 2024/2956 is the DORA register-of-information templates ITS, not the subcontracting RTS (Commission Implementing Regulation (EU) 2024/2956, accessed 2026-05-08). FINMA Circular 2018/3 covers sub-outsourcing and requires the supervised company to preserve control and auditability over the outsourced function (FINMA Circular 2018/3, accessed 2026-05-08). Topology A tends to produce a deeper vendor-controlled chain: core vendor, cloud provider, database, monitoring, support, security tooling and sometimes regional processors. Topology B can shorten the application chain because cloud contracts sit directly with the customer, but it can also create dual chains: the customer’s hyperscaler chain plus the software vendor’s support, update and telemetry chain. The control question is therefore chain visibility, change notice and termination rights, not the number of tenants alone.
5. Exit strategy
DORA Article 28(8) requires exit strategies for ICT services supporting critical or important functions that enable exit without business disruption, without limiting regulatory compliance and without detriment to continuity and quality of services; the provision also calls for transition plans and data transfer to alternative providers or in-house solutions (DORA Article 28(8), accessed 2026-05-08). DORA Article 30(3) requires contracts for critical or important ICT services to include exit strategies and a mandatory transition period during which the provider continues functions to reduce disruption risk (DORA Article 30(3), accessed 2026-05-08). The EBA guidelines require documented exit strategies covering termination, provider failure, deterioration in service quality and transfer to another provider or back in-house without undue disruption (EBA outsourcing guidelines, accessed 2026-05-08). In Topology A, exit is structurally dependent on the SaaS vendor’s export formats, transition assistance, continued platform availability and access to historical data, logs and configuration. In Topology B, the institution may retain the runtime environment, storage, logs and backups, which can shorten some evidence and data-control steps, but it can still be locked into proprietary data models, business-rule engines, ledger semantics and vendor release tooling. No primary source sets a maximum core-banking cutover time by topology; status: primary-source-not-located.
6. Data sovereignty and localisation
DORA Article 30 requires ICT contracts to identify the locations where ICT services and data processing and storage are provided and to require notification before material location changes (DORA Article 30, accessed 2026-05-08). The EBA guidelines require outsourcing registers to record countries where the service is performed and where data are stored, including cloud deployment models, and they require data security and confidentiality controls in outsourcing agreements (EBA outsourcing guidelines, accessed 2026-05-08). GDPR Chapter V Articles 44–49 govern transfers of personal data to third countries and international organisations through adequacy, appropriate safeguards, binding corporate rules or derogations (GDPR Regulation (EU) 2016/679, accessed 2026-05-08). FINMA permits outsourcing abroad only where the company, audit firm and FINMA can exercise and enforce inspection and audit rights and supervision is not made more difficult (FINMA Circular 2018/3, accessed 2026-05-08). The EU Cybersecurity Act creates a certification framework for ICT products, services and processes, and ENISA states that the EUCS cloud-services scheme remained under development at this cut-off (Cybersecurity Act Regulation (EU) 2019/881, accessed 2026-05-08; ENISA cybersecurity certification framework, accessed 2026-05-08). Topology A can meet localisation requirements if contract, architecture and sub-processing controls are adequate; Topology B gives the institution more direct control over region selection, keys, logging and network perimeter. A binding EU sovereign-cloud rule that makes one topology presumptively compliant was not located.
7. Concentration risk
DORA requires financial entities, when contracting for ICT services supporting critical or important functions, to consider concentration risk from reliance on the same or connected ICT third-party service providers and from non-substitutability (DORA Article 28, accessed 2026-05-08). The EBA guidelines require competent authorities to identify concentrations at service providers using documentation from institutions and to assess whether concentration could pose risk to financial stability (EBA outsourcing guidelines, accessed 2026-05-08). The FSB third-party risk toolkit states that financial institutions’ reliance on third parties can bring flexibility and resilience benefits but, if not appropriately managed, disruption to critical services or providers can pose risks to institutions and financial stability; it also includes tools for identifying systemic third-party dependencies (FSB final toolkit, accessed 2026-05-08). Topology A concentrates operational expertise, release cadence and production control at the SaaS operator; if many institutions use the same core SaaS and underlying cloud, common-failure and correlated-change risk are easier to aggregate. Topology B distributes application operation across customer accounts, which can reduce common application-runtime control by one SaaS operator, but it may increase concentration at hyperscaler, managed database, identity or security-service layers. The buyer due-diligence question is therefore not “is multi-tenant bad?” but “where would a single outage, forced change, legal restriction or vendor failure affect multiple regulated firms at once?”
8. Operational resilience
DORA Articles 5–9 place ICT governance and ICT risk-management duties on the financial entity’s management body, require a documented ICT risk-management framework, and require identification, classification and documentation of ICT-supported business functions, information assets and dependencies (DORA Articles 5–9, accessed 2026-05-08). PRA operational-resilience policy requires UK firms to identify important business services, set impact tolerances and remain responsible for resilience even where services depend on third parties (PRA SS1/21, accessed 2026-05-08). PRA SS2/21 is designed to complement operational-resilience policy and facilitate adoption of cloud and other new technologies without weakening accountability (PRA SS2/21, accessed 2026-05-08). Structurally, Topology A places more resilience execution inside the vendor control plane: failover, patching, incident response, tenant isolation and release rollback are vendor-operated controls. That can be efficient, but it demands stronger contractual evidence, service-level reporting, testing participation and incident cooperation. Topology B places more resilience operation inside the institution’s cloud boundary: backup policy, region architecture, IAM, monitoring, change windows and disaster recovery can be directly governed by the institution. That can improve inspectability, but it increases the institution’s engineering burden and can fail if the bank underinvests in cloud operations. No primary source found gives a categorical resilience preference to either topology; status: primary-source-not-located.
Reading the graph, cut-off and refresh triggers
The graph accompanying this guide places the two topology nodes at the centre and connects them to eight control axes, the regulatory instruments that require those controls, and public product/vendor evidence limited to deployment-model identification. A primary-source-not-located marker means the evidence pass did not locate a regulator-side source resolving the specific topology question; it does not mean that the position is false. The page is intended for quarterly refresh and signal-event refresh on DORA level-two changes, ESA CTPP list updates, FINMA Circular 2018/3 amendments, FCA/PRA outsourcing policy changes, Cybersecurity Act certification developments, and material changes to public vendor deployment documentation. The conclusion is deliberately narrow: multi-tenant SaaS and single-tenant customer-cloud deployment are both capable of being used in regulated finance, but neither shifts accountability away from the supervised institution. The topology changes what evidence the buyer must obtain, who operates the runtime, where concentration accumulates, how audit is performed, and how credible exit must be demonstrated.