For financial institutions, the security question is not simply cloud versus on-premises. It is who controls the infrastructure, code, access, data and response process when something goes wrong.
A SaaS platform can be highly secure, but it requires the customer to delegate significant parts of application and infrastructure security to the provider. A customer-controlled SAMFCore deployment can give a qualified organisation direct control over more of the security stack, including infrastructure, network segmentation, access policies, logging, encryption configuration, patching, testing and incident response.
The trade-off is responsibility: greater control also means the customer must have the people, processes and technical capability to secure and operate that environment properly.
Quick answer
Not automatically. Security depends on architecture, controls and operational capability. SaaS transfers more infrastructure and application-security responsibility to the provider, while customer-controlled deployment gives the financial institution greater direct control over isolation, access, logging, testing, data location and incident response. For organisations with strong security teams, that additional control can be strategically important.
Control vs delegation
The defensible distinction is not secure versus insecure. It is how much of the security model the institution controls directly and how much it delegates to a software provider under a shared-responsibility model.
The customer commonly depends on the provider for application deployment, underlying infrastructure, tenant isolation, platform patching, infrastructure monitoring, core application security, some incident-response activity, availability and infrastructure change control.
The customer still retains responsibility for:
Depending on the agreed architecture, the customer can directly control hosting, network segmentation, infrastructure configuration, access, security tooling, logs, monitoring, encryption architecture, backups, patch timing, testing, approvals, incident response, data residency and disaster recovery.
Important: customer-controlled deployment is strongest where the organisation has mature infrastructure, security and governance capabilities.
Different trust model
Multi-tenant SaaS is designed to isolate customers while sharing underlying infrastructure. That model can be secure, but customers rely on the provider to design, test and maintain isolation so one tenant cannot affect another tenant’s confidentiality, integrity or availability.
A dedicated customer-controlled SAMFCore deployment lets the organisation design isolation boundaries around its own environment. Potential controls include dedicated network zones, private subnets, firewall policies, infrastructure segmentation, restricted administrative paths, private connectivity, customer-controlled monitoring, dedicated databases where the architecture permits, and customer-defined security baselines.
Canadian Centre for Cyber Security guidance on defence in depth and tenant isolationSource-code security
With qualifying perpetual licensing, SAMFCore customers may obtain full source code for their licensed deployment. This changes the available level of technical inspection—not the need for disciplined security engineering.
A typical SaaS customer evaluates a proprietary application through security documentation, certifications, penetration-test summaries, questionnaires, contractual controls, APIs and external testing where permitted. The customer generally cannot inspect or control the provider’s complete source code.
A licensed SAMFCore customer with qualifying source-code rights can perform deeper technical inspection of the software it operates and use its own or appointed developers within the agreed licence scope.
Source-code access improves transparency and control, but does not automatically make software secure. Security still depends on secure development, review, patching, configuration and operational discipline.
Review source-code and perpetual licensingOperational controls
Customer control can extend across architecture, access, telemetry, change and recovery. Each control must be designed and operated deliberately.
Define dedicated zones, private subnets, firewall policies, restricted administrative paths, private connectivity and customer-specific security baselines around the deployment.
Set the administrative boundaries, MFA, SSO, role-based access, service-account, secrets, PAM, access-logging and break-glass procedures for the customer environment.
Design telemetry around the institution’s SOC and integrate customer-selected SIEM, EDR, IDS/IPS, WAF, scanning, network-monitoring, archival and forensic tooling where technically appropriate.
Align encryption in transit and at rest, certificate handling, rotation, secrets management, key custody and customer-selected HSM infrastructure with internal security policy.
Establish testing environments, release gates, maintenance windows, patch validation, deployment approvals and rollback processes under the agreed support arrangement.
Control more of the containment, evidence collection, restoration, backup, disaster-recovery and incident-response process within the customer’s own operating model.
Security due diligence
These are the practical questions behind on-premises vs SaaS core banking security. The answer changes by architecture and support model, not by label alone.
A SaaS provider generally controls platform releases, emergency patches, infrastructure updates and change windows. This can reduce maintenance burden and speed central remediation. In a customer-controlled SAMFCore deployment, the customer can establish validation, approval, maintenance and rollback processes—but must actively operate them. Responsibilities and support depend on the agreed deployment and support arrangement.
Managed SaaS telemetry depends partly on what the provider exposes. A customer-controlled environment can be designed around the institution’s own SOC evidence requirements and customer-selected tooling. Those surrounding tools are not represented as built-in SAMFCore capabilities; they are controls integrated around the deployment where technically appropriate.
In SaaS, authorised provider personnel may hold defined operational responsibilities under the provider’s controls. Customer-controlled deployment allows the institution to define administrative boundaries and privileged-access processes for its own environment. Neither model removes the need for disciplined IAM, MFA, SSO, role design, service-account governance, access review and logging.
Security teams care about encryption at rest and in transit, certificate management, rotation, key custody, secrets and HSM integration. SAMFCore can be deployed within an architecture using customer-selected security and key-management infrastructure where technically appropriate; exact controls depend on the deployment design.
Data location can affect regulatory obligations, outsourcing requirements, internal policy, cross-border transfers, supervisory expectations and customer commitments. Subject to the agreed architecture, customer-controlled deployment may allow the institution to select the jurisdiction, data centre or cloud region and can support data-residency requirements. It does not guarantee compliance.
Control of the customer environment can provide greater freedom to schedule vulnerability scans, penetration tests, red-team exercises, configuration reviews, code scans, infrastructure assessments and recovery tests. Managed SaaS providers may impose approval requirements or restrictions on testing shared environments, although policies differ by provider.
A SaaS incident may require coordination among the customer, SaaS provider, infrastructure provider and other services. In a customer-controlled deployment, the institution may directly control more of the isolation, containment, logs, forensic evidence, restoration, backup recovery and application deployment. This reduces dependency only where the customer can operate the environment effectively.
Security review should address third-party libraries, packages, dependencies, build processes, deployment artefacts and update practices. Where relevant artefacts are provided or generated through the customer’s development and deployment process, source access can support composition analysis and dependency review. No SBOM is promised by this guide.
Security architecture includes availability and operational resilience. SaaS creates dependencies on the provider’s infrastructure, release process, incident response and commercial continuity. Perpetual usage rights can reduce some software-vendor dependency; qualifying source-code rights may allow the customer’s own or appointed developers to maintain the licensed deployment. Banks, processors, cloud providers and other external services can remain dependencies.
Direct governance of an environment can give auditors access to infrastructure logs, access records, deployment evidence, vulnerability results, configuration records, change approvals, incident records, backup evidence and DR test results. Customer-controlled deployment may help some institutions align evidence with their control framework; it does not automatically create regulatory compliance.
Architecture model
A customer-controlled deployment can place SAMFCore inside the institution’s security boundary, surrounded by customer-selected controls and connected to the external providers required for the business model.
Customer security boundary
Application layer
Customer-selected external services
Exact architecture depends on the customer’s infrastructure and deployment design. Security, regulated and specialist services remain customer-selected and are integrated where technically appropriate.
Trade-offs
This table compares common responsibility patterns. Specific provider contracts, deployment designs and support arrangements may differ.
| Security area | Typical multi-tenant SaaS | SAMFCore customer-controlled deployment |
|---|---|---|
| Infrastructure ownership | Provider-managed | Customer-selected or controlled according to deployment |
| Tenant isolation | Provider responsible for platform tenant isolation | Customer can use dedicated deployment boundaries |
| Application source code | Usually not available to the customer | Available under a qualifying source-code licence |
| Patch management | Provider managed | Customer controlled, or managed under the selected support arrangement |
| Release timing | Provider controlled | Customer-controlled deployment schedule |
| Network architecture | Primarily provider controlled | Customer-designed around the deployment |
| Security tooling | Provider controls plus customer-accessible tools | Customer can integrate its security stack around the environment |
| Logging | Visibility depends partly on provider exposure | Customer can design logging around the environment |
| Data location | Provider service and region options | Customer selects location subject to the agreed architecture |
| Penetration testing | Subject to provider policies | Customer controls testing of its deployment, subject to third-party rules |
| Privileged infrastructure access | Provider retains operational responsibilities | Customer can establish its own privileged-access model |
| Incident response | Shared and coordinated with the provider | Customer can directly control more of the environment |
| Source-code security review | Generally unavailable for a proprietary platform | Possible with qualifying source-code licensing |
| Change control | Provider controls the core release process | Customer can establish internal change approval |
| Vendor dependency | Continued service depends on the provider | Perpetual rights can reduce software-vendor dependency |
| Operational responsibility | Lower infrastructure burden on the customer | Higher customer responsibility |
Typical SaaS
Provider-managed
SAMFCore deployment
Customer-selected or controlled according to deployment
Typical SaaS
Provider responsible for platform tenant isolation
SAMFCore deployment
Customer can use dedicated deployment boundaries
Typical SaaS
Usually not available to the customer
SAMFCore deployment
Available under a qualifying source-code licence
Typical SaaS
Provider managed
SAMFCore deployment
Customer controlled, or managed under the selected support arrangement
Typical SaaS
Provider controlled
SAMFCore deployment
Customer-controlled deployment schedule
Typical SaaS
Primarily provider controlled
SAMFCore deployment
Customer-designed around the deployment
Typical SaaS
Provider controls plus customer-accessible tools
SAMFCore deployment
Customer can integrate its security stack around the environment
Typical SaaS
Visibility depends partly on provider exposure
SAMFCore deployment
Customer can design logging around the environment
Typical SaaS
Provider service and region options
SAMFCore deployment
Customer selects location subject to the agreed architecture
Typical SaaS
Subject to provider policies
SAMFCore deployment
Customer controls testing of its deployment, subject to third-party rules
Typical SaaS
Provider retains operational responsibilities
SAMFCore deployment
Customer can establish its own privileged-access model
Typical SaaS
Shared and coordinated with the provider
SAMFCore deployment
Customer can directly control more of the environment
Typical SaaS
Generally unavailable for a proprietary platform
SAMFCore deployment
Possible with qualifying source-code licensing
Typical SaaS
Provider controls the core release process
SAMFCore deployment
Customer can establish internal change approval
Typical SaaS
Continued service depends on the provider
SAMFCore deployment
Perpetual rights can reduce software-vendor dependency
Typical SaaS
Lower infrastructure burden on the customer
SAMFCore deployment
Higher customer responsibility
A well-run SaaS platform can be the better security choice for organisations that do not have mature infrastructure and security operations.
Moving security responsibility in-house only improves the security model if the organisation has the capability to manage it well.
SAMFCore customer-controlled deployment may be relevant where the organisation:
Vendor evaluation
Use these questions to test responsibility boundaries, evidence availability, operational independence and the practical security model—not just the deployment label.
FAQ
Not automatically. Customer-controlled deployment gives the institution more direct control, but it also makes the institution responsible for securing and operating more of the environment. SaaS may be preferable for organisations without the resources to operate secure infrastructure themselves.
It can be. Multi-tenant platforms rely on effective isolation between customers and strong provider security controls. The difference is that the customer depends more heavily on the provider to design and maintain those controls.
SAMFCore supports customer-controlled deployment arrangements, including an on-premises deployment where agreed and technically appropriate. An organisation seeking an on-premise core banking or financial platform can deploy within infrastructure controlled by the organisation or its appointed infrastructure provider, depending on the agreed deployment.
Full source code is available under qualifying SAMFCore perpetual licensing. The licensed customer may use its own or appointed third-party developers within the agreed licence scope.
A customer-controlled deployment can be designed around customer-selected infrastructure, SOC processes, SIEM and other security tooling, subject to the technical deployment. These surrounding tools are selected and operated by the customer or its appointed provider; they are not represented as built-in SAMFCore products.
Depending on the agreed deployment, the customer can select infrastructure and location appropriate to its requirements, including a jurisdiction, data centre or cloud region. This can support data-residency objectives but does not itself guarantee regulatory compliance.
Customer-controlled deployment gives the customer greater control over security testing of its own environment. Testing remains subject to the rules of any cloud, hosting, network or other third-party infrastructure involved.
Responsibility depends on the deployment and support arrangement. A customer-controlled model lets the customer establish its release, validation and maintenance process, while Swiss AMF or appointed support providers may have agreed responsibilities where support has been purchased.
No. Perpetual licensing itself does not create security. Its security significance is that it can support greater operational independence and, together with source code and customer-controlled deployment, greater technical control.
It can improve transparency and allow deeper review, but source-code access does not automatically make an application secure. Security still depends on secure development, review, patching, configuration and operational discipline.
Technical scope
Last reviewed: September 2026
This guide discusses software architecture and security-control models. It does not mean that either SaaS or customer-controlled infrastructure is inherently secure or compliant. Security depends on implementation, configuration, operations, personnel and governance.
General cloud-security principles are supported by authoritative guidance on shared responsibility, multi-tenancy, monitoring and incident-response responsibilities. SAMFCore-specific statements reflect current product and licensing documentation.
Review the deployment model, source-code options, infrastructure boundaries and integration architecture with SAMFCore before making a platform decision.
