Multi-Tenant vs Single-Tenant Core Banking — Regulator Questions [2026] | CoreFi

In 2026, "multi-tenant SaaS core banking" stopped being a controversial position and started being a default. What did not become a default is the regulator's comfort with multi-tenant deployments — and the gap between vendor marketing and supervisor expectation is where many modernization programs run into a wall.

This article is the CIO/CRO view we use with regulated institutions evaluating CoreFi (or anyone else) under that lens.

Note. Regulatory expectations vary by jurisdiction, license type and the specific national competent authority. This article reflects observed lines of questioning from EU supervisors and analogous regimes; it is not a substitute for advice from your regulatory counsel or for direct dialogue with your supervisor.

What the deployment models actually are

The vocabulary is loose enough to be unhelpful. The deployment patterns that actually exist:

Pure multi-tenant. One software instance, one database, multiple customers (tenants). Logical isolation between tenants is enforced in the application layer. Underlying compute, storage and network are shared.

Multi-tenant with isolated data plane. Shared application instance, separate database per tenant (or strong per-tenant logical isolation backed by separate keys, separate encryption envelopes, separate backups). Compute may be shared or dedicated per tenant.

Single-tenant SaaS (sometimes "dedicated tenant"). One software instance per customer, typically deployed and managed by the vendor, often on cloud infrastructure dedicated to that customer.

Single-tenant managed. The vendor's software, deployed and operated by the vendor, but on infrastructure the customer either owns or has direct control over.

On-premise / customer-managed. The customer owns the deployment. The vendor provides software and support.

These are not five points on a continuum. They are five distinct postures, with very different supervisory characteristics.

The five questions a regulator will ask

We see the same lines of inquiry from EU supervisors across DORA, MiCA and national banking law contexts. Here is what they are actually probing.

1. "Where is our data, and can we prove it is segregated from other customers' data?"

In a multi-tenant deployment, segregation is a property of the application code and the operational discipline of the vendor. The regulator wants to see:

• A documented data model that demonstrates per-tenant separation
• Encryption practices that limit blast radius — ideally per-tenant keys
• Logging and access controls that prove no cross-tenant data exposure has occurred
• The vendor's incident history, specifically for cross-tenant events

The single-tenant equivalent is mostly self-evident: the supervisor can see that this institution's data is in its own database, its own storage account, its own backups.

A multi-tenant deployment can absolutely answer these questions well. But it must answer them, and the institution — not just the vendor — must be able to demonstrate the answer.

2. "What happens to our service if another customer of the same vendor has an incident?"

This is the blast radius question and it is rising sharply on the supervisory agenda. Under DORA's operational resilience expectations, supervisors expect institutions to model and limit the scenario where a vendor incident in one tenant degrades another.

The vendor's answer needs to include:

• Architectural isolation that prevents one tenant's load or failure from impacting others (rate limits, tenant-specific resource quotas, separate workloads where it matters)
• A documented dependency map for shared infrastructure
• An incident-handling playbook that explains what happens to tenant A when tenant B is in incident

A "we share everything but it's fine" answer here is not a sustainable one in 2026.

3. "How do you exit?"

The exit question is the one most often underinvested. The regulator wants to know that the institution can transition off the vendor — with its data, its books and its operational continuity — within a defined window, in a number of named scenarios (vendor failure, vendor acquisition, deteriorating service, contractual breach, regulatory action against the vendor).

In a single-tenant or on-premise model, exit is operationally complicated but conceptually clear: the data is here, the runbook is here, you can run it without the vendor.

In a multi-tenant SaaS model, exit is harder, and the artefacts the supervisor expects are different:

• A documented data-export specification (with formats, scope and tested retrieval times)
• A documented re-platforming plan (which alternative platforms, with what effort)
• Contractual exit assistance commitments from the vendor
• Annual or semi-annual exit testing (not just a clause — an actual rehearsal)

DORA explicitly raises the bar on exit testing for critical ICT third-party providers. Multi-tenant doesn't preclude meeting that bar, but it raises the diligence required to meet it.

4. "Who is in control of changes that affect our service?"

In a multi-tenant SaaS, a vendor's deployment affects every tenant simultaneously. The supervisor will want to see:

• How changes are notified to institutions, with what lead time
• How institutions can defer or opt out of changes that affect their regulatory posture
• How changes that affect model behaviour (for AI features) are versioned and disclosed
• The vendor's change-management process, audited

A vendor that pushes a change to production without notifying institutional tenants creates a supervisory issue for those tenants. Many multi-tenant vendors have learnt this, but not all.

5. "Where is our data, geographically?"

This is the data-residency and data-sovereignty question, and it is the one where regulators are increasingly specific. EU regulators, in particular, expect concrete answers about:

• Which EU jurisdictions the data is hosted in
• Which non-EU jurisdictions the data is processed in (including support access, monitoring, telemetry)
• The legal basis for any non-EU access (Standard Contractual Clauses, supplementary measures, transfer impact assessments)
• The vendor's exposure to extraterritorial legal demands (US CLOUD Act being the most-cited example)

This question is somewhat independent of the multi-tenant / single-tenant axis — both models can answer it well or badly. But it is asked in every meaningful regulator conversation in Europe in 2026, and it conditions every other answer.

Which model fits which institution

There is no universally-right answer. There is a defensibility answer that depends on three things:

Your supervisor's posture. Some supervisors are comfortable with multi-tenant SaaS for everything. Some require single-tenant for critical infrastructure. Many will accept multi-tenant with strong segregation evidence and an exit-tested contract. Know your supervisor before you choose your model.

Your risk concentration. A small institution running multi-tenant SaaS may, in some cases, end up with better operational resilience than running its own dedicated stack — because the vendor's operational maturity exceeds what the institution could replicate alone. A very large institution may face the opposite: concentration risk from sharing infrastructure with peers materially exceeds the operational benefit.

Your data sensitivity. Certain data classes (full PII, account-level transactional history, AML case files) sit on the conservative end of supervisor expectation. Workloads handling those classes often default to stronger isolation than other workloads, regardless of the model chosen for the rest of the stack.

A pragmatic 2026 institutional pattern is hybrid: multi-tenant SaaS for non-sensitive workloads (customer interaction layer, knowledge management), with a more isolated model for the ledger of record and the audit plane.

What "defensible multi-tenant" looks like

If the multi-tenant model is the right answer for the institution, the architectural ingredients of a defensible deployment are well-understood:

• Per-tenant encryption keys under the institution's control (not the vendor's), so the vendor cannot decrypt data without institutional cooperation
• Per-tenant data stores (separate database / schema / partition, not just a tenant_id column)
• Per-tenant audit log for both data access and configuration changes
• Resource isolation that prevents one tenant's behaviour from affecting another's performance
• An exit framework: documented data formats, tested extraction, contractual exit-assistance commitments
• Geographic transparency: the institution knows, at all times, which jurisdictions data is in and processed from
• A change-disclosure regime: notifications, opt-outs and version pinning where regulatory posture is affected

A vendor that cannot evidence these is not selling defensible multi-tenant. They are selling regulator risk dressed as cost efficiency.

Where CoreFi sits

CoreFi's deployment model is designed to allow institutions to choose where on the spectrum they sit — without re-platforming. The platform's deployment options include per-tenant encryption keys, per-tenant data stores, EU-hosted infrastructure, isolated audit planes and a documented exit framework, available on request and scoped per customer as part of onboarding. Institutions that need stronger isolation for their ledger or audit plane can deploy those components in a more isolated posture while running the rest of the stack multi-tenant. The platform is designed to support DORA's operational resilience and third-party risk expectations; final supervisory positioning depends on your jurisdiction, your supervisor and how the configuration is operated.

The architecture question is not "multi-tenant or not." It is "which workload, with which isolation, for which regulator." Vendors that pretend the first question is the whole question are selling a slogan.

For the broader trust posture, see CoreFi Trust Center.