Core Banking Architecture for Multi‑Licenced Groups: The Powerful Balance Between Efficiency, Separation and Compliance

Core banking architecture is often debated as a technology decision: monolith versus microservices, cloud versus on‑prem, buy versus build. In regulated banking and payments, it is equally a governance decision, because regulators, auditors, and card/payment schemes  tend to evaluate segregation and protection of sensitive data, operational resilience, accountability and risk at the level of the licensed legal entity, not at the level of an internal configuration boundary inside a shared platform. 

In this article, we explain why “multi‑entity in a single core instance” can be far more difficult to justify than it first appears, we translate the relevant regulatory expectations into practical core banking architecture patterns, and we set out how a provider such as Baseella can support per‑entity deployment without forcing organisations to rebuild everything for each new licence or jurisdiction. 

To be clear about terminology, the issue here is not whether a single legal entity can run multiple currencies, products, or countries. Many firms do. The question is whether multiple regulated legal entities (for example, different subsidiaries with separate regulatory authorisations) should share one production “core instance” and rely on logical segregation, such as tenancy flags, configuration partitions, and RBAC scoping to keep boundaries intact. 

That is where the regulatory compliance and audit burden typically spikes, because it becomes harder to demonstrate that cross‑entity access is not merely “unlikely” but operationally contained and technically constrained. 

In multi-licenced groups, core banking architecture is judged through entity accountability. The closer your boundaries are to “contained by design”, the lower your evidentiary burden tends to be.

Core banking architecture and the regulatory unit of accountability

Across modern regulatory regimes, obligations are repeatedly framed in terms of the entity that is authorised, supervised, and accountable. That framing matters for core banking architecture because it implies that governance, risk appetite, control evidence and incident accountability must be defensible for each  licensed firm, even when a group tries to centralise technology. For example, DORA requires each financial entity to have a documented ICT risk management framework and assigns governance responsibilities to the management body. 

DORA sets expectations that are difficult to evidence in a “shared‑instance” model if one entity’s operational decisions (deployment cadence, configuration changes, backup frequency, access administration, incident response priorities) can materially affect another. 

The same “entity accountability” logic appears in outsourcing and third‑party guidance. The FCA guidance on cloud outsourcing states that regulated firms retain full responsibility and accountability for discharging regulatory responsibilities and cannot delegate that responsibility to a third party. This becomes relevant when a group attempts to make Entity A’s core “owned/operated” by Entity B, because the operational dependency may complicate how Entity A demonstrates independent governance, oversight and control. 

At the pan‑European level, the European banking supervisor’s outsourcing guidelines require contracts to preserve effective access, information and audit rights (including for competent and resolution authorities), and emphasise ongoing oversight and exit planning. When multiple legal entities share a single production core instance, proving that each entity has sufficient access, auditability and termination/exit capability – without creating cross‑entity risk – can become structurally complex. 

A practical way to see the direction of the regulator’s view is to look at how major structural reforms forced operational separation. During UK ring‑fencing implementation, HSBC publicly stated it “separated over 250 IT systems” as part of completing ring‑fencing – an illustration that, when regulators demand separation, the work often becomes concrete infrastructure and systems change rather than policy language. 

The key inference for core banking architecture is that regulators and auditors tend to favour controls that are easier to evidence as “contained by design”. Logical segregation can be made robust, but the burden of proof increases sharply, especially where shared runtime, shared operators, or shared privileged access exists. 

If your operating model relies on a single shared production core instance across regulated entities, your core banking architecture must prove isolation under real operational pressure: deployments, incidents, privileged access, and audit access. Evidence requirements tend to rise faster than expected.

Table 1: Regulatory “Entity Accountability” Implications for Core Banking Architecture

Designing core banking architecture for hard isolation

When regulators or regulatory compliance advisors say “one instance per regulated entity”, they rarely mean “separate branding and a tenant ID”. They usually mean a stronger isolation boundary that is legible to auditors: separate deployment environments, separated data planes, and separated privileged access paths. This maps well into DORA’s emphasis on resilience of processing systems and the ability to restore availability in the event of incidents. 

In a cloud‑native context, public cloud documentation frequently recommends account/project separation as a strong isolation boundary for security, access and billing, precisely because it reduces the impact of compromise and makes guardrails easier to apply. For example, AWS’s Well‑Architected security guidance explicitly recommends separating workloads using accounts as an isolation boundary, and its multi‑account whitepaper describes accounts as IAM isolation boundaries where no access is allowed by default without explicit enablement. 

Similarly, Google Cloud guidance explains using folders and projects to create isolation between resources and establish trust boundaries, with centrally defined policies inherited down the hierarchy. 

Translating these ideas into core banking architecture, “hard isolation” typically includes a combination of:

• separated compute/control planes (for example, separate production environments or clusters),
• separated data planes (distinct databases for ledger and payments data),
• separated secrets and key management domains,
• separated audit logs and immutable evidence trails,
• separated CI/CD promotion and change‑approval gates.

These are not aesthetic choices. They reduce the blast radius of incidents, make cross‑entity data access materially harder, and simplify the narrative during audits: boundaries are enforced by technical constraints, not only by policy and careful configuration. The security and availability expectations embedded in GDPR (security of data processing) and DORA (ICT risk management, protection and prevention) push organisations toward demonstrably robust separation and resilience measures. 

It is also important to distinguish platform reuse from environment sharing. You can reuse the same codebase, shared engineering standards and shared observability patterns while still operating separate instances per entity. Public‑cloud resource hierarchy patterns explicitly support central governance with isolated projects/accounts, showing that “separate” does not have to mean “duplicated chaos.” 

Core banking architecture can be standardised across entities without sharing the same production instance. Reuse sits above the isolation boundary; accountability sits below it.

Core banking architecture implications for access control and auditability

Most “multi‑entity in one instance” debates eventually converge on a single, uncomfortable question: who can do what, where, and how do you prove it with evidence that stands up to a hostile audit? This is not just a cybersecurity question; it is a governance and accountability question that intersects with DORA, outsourcing expectations, and data protection. 

DORA requires financial entities to establish an ICT risk management framework that includes strategies, policies, procedures and tools to protect ICT assets, and it explicitly expects segregation and independence across ICT risk management functions, control functions and internal audit functions (aligned to “three lines of defense” concepts). While DORA does not mandate a particular deployment topology, it does raise the bar on demonstrating effective governance and independence, something that becomes harder when multiple regulated entities share the same privileged administration surface. 

The EBA outsourcing guidelines reinforce this by expecting access, information and audit rights for both the institution and competent authorities, including “full access” to relevant premises, systems, networks, information and data for critical or important outsourced functions, and unrestricted inspection/audit rights. If a single shared core instance supports multiple licensed entities, each entity must be able to evidence that it has meaningful auditability and effective oversight over the parts that matter to its regulated activity without creating cross‑entity exposure through shared audit access or shared operational tooling. 

The Bank of England supervisory statement on outsourcing and third‑party risk management also stresses materiality assessment at an individual firm level: even when a group performs a group‑wide assessment, “materiality should be assessed at an individual firm level” and each firm should take reasonable steps to reach an informed view as an individual firm. That principle is difficult to operationalise if the control environment is materially shared and one firm cannot, in practice, change or exit the arrangement independently. 

The practical core banking architecture takeaway is straightforward: the more entities you pack into one production instance, the more your RBAC model becomes a critical compliance artefact, especially for the firms with large teams. You are asking auditors to trust that a complex permission model, applied across shared infrastructure, shared logs and shared operational tools, will never leak privileges or be mis‑operated, even under incident pressure. 

By contrast, separate instances give each entity its own “exclusive control plane” where SoD and RBAC controls are simpler to design, test, evidence and defend. This is an inference from how the regulatory requirements emphasise demonstrability, auditability and resilience rather than mere intent. 

In shared-instance core banking architecture, RBAC becomes a primary compliance control. In separate-instance core banking architecture, RBAC remains important, but the isolation boundary carries part of the evidentiary load.

Core banking architecture through data and safeguarding lens

Data protection is often the decisive factor in core banking architecture discussions, because it creates non‑negotiable obligations around security, breach response and accountability.

Under GDPR, the controller must implement appropriate technical and organisational measures and be able to demonstrate compliance. GDPR also embeds “data protection by design and by default”, requiring safeguards to be built into the means of processing and ensuring that only necessary data is processed by default. These concepts generally become easier to evidence when personal data for each regulated entity is processed within clearly bounded systems, with clear ownership of configurations, logs, retention and access paths. 

GDPR’s security of processing requirements include the ability to ensure ongoing confidentiality, integrity, availability and resilience of processing systems and services, as well as the ability to restore availability and access in a timely manner after incidents, plus regular testing of security measures. A shared core instance can meet these requirements, but it concentrates risk: an incident or operational failure affecting one entity’s workload may threaten the availability, integrity, or confidentiality of another entity’s data if isolation is not truly robust across runtime, storage, logs and administration. 

Breach handling further illustrates why boundaries matter. GDPR requires controllers to notify personal data breaches to the supervisory authority without undue delay and, where feasible, within 72 hours (subject to conditions), and to communicate breaches to data subjects where the breach is likely to result in high risk. 

In a shared‑instance model, incident forensics and scoping become harder: you must prove whose data was affected, which entity’s controls failed, which logs are authoritative, and whether cross‑entity contamination occurred. Clear instance boundaries can reduce ambiguity and reduce the time needed to establish facts under incident pressure. 

For payment card data, the scoping discipline of PCI DSS pushes in a similar direction. The PCI Security Standards Council’s scoping and segmentation guidance recommends starting with the assumption that everything is in scope until verified otherwise, and it explains that segmentation can reduce the number of systems requiring PCI DSS controls, but warns that attackers often target systems deemed “out of scope” to reach systems where cardholder data can be found. 

This is directly relevant to core banking architecture: shared services, shared admin workstations, shared directory services and shared runtime environments can accidentally pull more systems into scope and expand audit overhead, while also increasing the risk of lateral movement. 

Safeguarding and customer funds protection adds a further jurisdiction‑specific constraint. The UK regulator’s policy statement on changes to the safeguarding regime for payments and e‑money firms sets new rules and guidance coming into force on 7 May 2026 and emphasises improved books and records, safeguarding audits for certain firms, and enhanced reporting/monitoring expectations. 

When regulatory requirements diverge across jurisdictions, separate instances per regulated entity allow configuration, controls and reporting pipelines to evolve without creating coupling risk for other entities operating under different expectations and timelines. 

The core banking architecture conclusion from this lens is not that “multi‑entity is impossible”, but that it forces you to fight scoping creep, ambiguity of accountability, and expanded incident blast radius. Separate instances materially simplify demonstrating ownership, data boundaries and compliance evidence, even if you still standardise engineering and operations centrally. 

Shared-instance core banking architecture can satisfy GDPR and PCI obligations, but it tends to concentrate risk and complicate breach scoping. Separate instances reduce ambiguity when accountability and timelines differ by entity.

Core banking architecture for operational resilience and third‑party risk

DORA is particularly important for the “shared core instance” debate because it operationalises resilience as a regulated capability. DORA requires an ICT risk management framework, identification of ICT‑supported business functions and dependencies, and protection and prevention measures for ICT systems and data. It also sets out incident management and major incident reporting requirements. These obligations become more straightforward to execute and evidence when each regulated entity can demonstrate containment and recovery within its own bounded environment. 

DORA also stresses governance at the management body level and the need to set roles, responsibilities and appropriate governance arrangements, with focus on availability, authenticity, integrity and confidentiality of data. If a regulated entity’s “core” is deployed, managed, or effectively controlled by another regulated entity (for example, due to shared ownership of the runtime environment, shared privileged accounts, or shared change management), the second entity’s operational resilience story becomes fragile: it must explain how it meets these governance duties independently, including during major incidents, contentious change windows, or financial stress at the group level. 

Third‑party risk is another stress point. DORA requires financial entities to manage ICT third‑party risk as an integral component of ICT risk, and it states that where financial entities have contractual arrangements for ICT services, they remain fully responsible for compliance and for discharging obligations under DORA and applicable financial services law. 

That principle is aligned with the FCA’s Operational Resilience policy statement  that firms cannot delegate regulatory responsibility. In a shared‑instance model, the “third party” may effectively become an affiliated entity or an internal operator, but the accountability principle does not vanish; it must still be evidenced. 

The operational question that boards and auditors ask is blunt: can a disruption, cyber incident, mis‑deployment, or privileged access compromise in Entity A cascade into Entity B? DORA’s framing around resilience, plus the supervisory focus on material outsourcing and exit planning, increases the value of architecture that supports containment by design. 

A useful discipline is to treat “instance boundaries” as “regulatory boundaries”, then build centralisation above, not below, that line: shared engineering standards, shared CI templates, shared security baselines, shared monitoring patterns, but separate production workloads and data planes per regulated entity. Public‑cloud governance patterns and outsourcing guidance both support the idea that centralised oversight can coexist with strong isolation boundaries. 

If you treat core banking architecture instance boundaries as regulatory boundaries, you can centralise standards and tooling while preserving per-entity containment, evidence, and exit capability.

How Baseella supports per‑entity core banking architecture without giving up scale

Vendor choices play a large role in whether per‑entity core banking architecture becomes sustainable or painful. If “separate instances per entity” means standing up an entirely new core, re‑implementing integrations, and rewriting controls from scratch each time, the model collapses under cost and complexity. If, instead, the platform is designed for modularity and repeatable deployment, per‑entity separation can be achieved with far less reinvention. 

Baseella positions modular architecture as a way to align system components with regulatory boundaries and to isolate or switch off certain payment methods, reports, workflows, or even modules where required. In its own discussion of global regulatory considerations, Baseella describes a model where each authorised entity within a group can deploy its own separately hosted instance in its jurisdiction, with data and payment processing confined within each instance, while still benefiting from a unified underlying platform that streamlines R&D and reduces development overhead. 

That framing maps directly onto the dominant compliance pressure points described above: the need to show per‑entity governance, per‑entity control of access and change, per‑entity incident containment, and clear boundaries for data protection and safeguarding without accepting that every new licence requires rebuilding the core. 

Baseella also argues for microservices‑style modular deployment where services can be instrumented and controlled independently (including, in its description, services operating independently with their own databases). Architecturally, that can support a “repeatable instance” strategy: you can standardise what “an entity instance” looks like (controls, logs, secrets, data plane patterns) and deploy it consistently, while still allowing local deviations when jurisdictional rules diverge. 

From a procurement perspective, the practical question to ask any core provider is whether their core banking architecture makes the per‑entity model the default path (repeatable, observable, and auditable), or whether it treats entity separation as an afterthought implemented via configuration switches. The evidence burden under DORA, UK Operational Resilience, GDPR and outsourcing expectations generally favours the former. 

Conclusion

The appeal of a multi‑entity, single‑instance core is obvious: fewer environments, lower operational overhead, and a simpler “single pane of glass”. But as soon as your business model spans multiple regulated legal entities, core banking architecture becomes inseparable from supervision reality: accountability is per entity, incident reporting is per entity, data‑controller duties attach per entity, and third‑party risk obligations sit with each regulated firm even when services are shared. 

A defensible architecture under modern expectations is therefore usually “one production instance per licensed entity” with shared organisational standards above that layer. This approach helps convert isolation from “we promise it is configured correctly” into a boundary you can evidence through infrastructure, data separation, audit trails and contained incident response – exactly the kind of proof regulators and auditors tend to reward. The scale‑separation work visible in ring‑fencing programmes shows how quickly separation becomes a concrete systems exercise when supervision demands it. 

Providers argue that you do not have to choose between per‑entity separation and platform efficiency: modular, repeatable deployments can allow each authorised entity to run a separately hosted instance while still benefiting from unified engineering and product development. In a regulatory environment shaped by DORA’s resilience expectations, GDPR’s accountability and security duties, and tightening safeguarding regimes, that is increasingly what “good core banking architecture” looks like in practice.