Part of our complete guide to negative news screening for Swiss banks. This post is the deep dive on vendor due diligence for Swiss banks; the guide covers the end-to-end picture.
Most software-vendor due diligence questionnaires sent by Swiss banks look the same as the ones sent by US fintechs and German insurers: SIG Lite, the CAIQ, a SOC 2 attachment, an ISO 27001 certificate, a penetration test summary. That is the floor. The Swiss-specific asks, which are the ones that actually make or break the deal, sit in a smaller set of obligations spread across two FINMA circulars, the Banking Act, and the SBA self-regulation.
This post is a procurement-side checklist mapped to the regulations that justify each line. It is written from the perspective of a bank evaluating an outside vendor, which means it is also the list of questions a vendor should expect to answer.
The ground floor: is this outsourcing?
FINMA Circular 2018/3 Outsourcing: banks and insurers governs the relationship between a regulated financial intermediary and any third party performing a function the bank would otherwise perform itself. The circular has been in force since 1 April 2018; the transition for existing arrangements ended 1 April 2023, so all arrangements are now subject to it.
Two threshold questions matter:
- Is the function "outsourced" at all? The test is qualitative: does the third party perform a function that is part of the bank's regular business activity, on a recurring basis, in a way that would otherwise require the bank to perform it in-house? A managed sanctions-screening service almost always meets this test. A one-off consulting project usually does not.
- Is the outsourcing "significant"? The bank performs its own case-by-case analysis based on the function's importance to the business and the risk it carries. The circular deliberately removed the prior "essential function" categorical list in favour of this risk-based judgement. AML and sanctions screening, when the vendor materially influences whether a client can be onboarded or a transaction can settle, is significant by any reasonable reading.
Both judgements are the bank's, not the vendor's. But the vendor should expect them, and the questionnaire should ask the questions whose answers the bank needs to make them: what data the vendor processes, how often, how the function fits into the bank's operational flow, and what the bank loses if the vendor disappears overnight.
Inventory, audit rights, and the contract
For any outsourcing arrangement that is significant, FINMA 2018/3 imposes a small set of contractual requirements that the bank's counsel will check line by line. The vendor's answer should be yes to each, with the relevant clause referenced.
- Inventory. The bank must keep an up-to-date inventory of all outsourced functions, the providers, the location of the data, and the criticality. The vendor's job is to provide accurate, current information to feed it.
- Right to audit. The bank, its external auditors, and FINMA itself must have the contractual right to inspect and audit the outsourced function at any time, without restriction. This is the clause that surprises vendors who have only sold to US buyers. It is more expansive than SOC 2 attestations alone satisfy.
- Sub-outsourcing transparency. The vendor must inform the bank in advance of involving subcontractors for essential parts of the function, and the bank must be able to terminate the arrangement in an orderly fashion if it does not approve. Hidden sub-processors are a contractual breach.
- Exit and in-sourcing. The vendor must support an orderly exit: data returned in a usable format, knowledge transferred, and the bank able to in-source the function in an emergency. "We can give you a CSV export" is not enough; the bank's contingency plan has to be executable, and the vendor's contract has to support it.
- Cross-border accessibility. Where data is stored or processed outside Switzerland, the bank must remain able to access it from Switzerland for purposes of recovery and resolution. This is a resolution-planning concern, not a data-protection concern; it is satisfied by contractual access guarantees, not by data-residency alone.
The circular leaves data protection itself out of scope (that lives in the revised FADP) and explicitly says that data protection and banking secrecy are governed separately. The procurement checklist still has to cover them; they just don't sit in the FINMA outsourcing circular.
Banking secrecy and the cloud question
Article 47 of the Banking Act (BankG, SR 952.0) is the criminal provision that protects client information. Wilful disclosure of a banking secret is punishable by up to three years of imprisonment or a monetary penalty; for-profit disclosure extends to five years.
The interesting part for vendor procurement is whether handing client data to a third-party processor counts as a "disclosure" under Art. 47. The 2019 SBA legal opinion on bank secrecy and cloud gave the working answer: the vendor can be treated as an agent of the bank under Art. 47 para. 1 lit. a, in which case migration of data to the vendor's infrastructure is not a "disclosure" and no criminal liability arises, provided the bank has imposed sufficient technical, organisational, and contractual protections.
For the vendor, the practical implication is that the contract has to do real work. It has to:
- bind the vendor and its personnel to a confidentiality regime equivalent to the bank's own;
- restrict access to client data to named individuals;
- require encryption at rest and in transit;
- prohibit use of client data for any purpose other than performing the contracted function;
- include a right of audit and the cooperation duties FINMA 2018/3 requires.
A vendor that cannot redline these clauses cleanly is going to fail the legal review regardless of how strong its security posture is.
Operational resilience: FINMA 2023/1
FINMA Circular 2023/1 Operational Risks and Resilience: Banks came into force on 1 January 2024 with a two-year transition ending 1 January 2026, so as of this writing, full compliance is now expected. Among other things, it raises the bar on third-party risk management and on the bank's ability to continue critical functions during a disruption.
For the vendor, this surfaces as concrete asks in the questionnaire:
- Recovery time and recovery point objectives for the vendor-provided service, mapped to the bank's tolerance for the function it supports.
- Concentration risk disclosure, where the vendor itself depends on a small number of upstream providers (a cloud region, a single CDN, an SaaS dependency), the bank needs to know.
- Critical-data security controls specific to the categories of data the vendor handles, including key management, access logging, and data classification.
- Cyber-incident notification with a defined timeline and a named contact at the vendor.
The circular is principle-based rather than prescriptive; the expected outcome is that the bank can demonstrate a coherent third- party risk programme, not that any specific control exists at the vendor. But the vendor's answers are the input.
Certifications: ISO 27001 over SOC 2 for Swiss buyers
Both ISO 27001 and SOC 2 Type II are useful, and they overlap on roughly half their controls. They are not interchangeable for Swiss buyers, for two reasons.
Format. ISO 27001 produces a certification by an accredited body, valid for three years with annual surveillance audits. The certificate can be displayed and verified independently. SOC 2 produces an attestation report by a CPA firm: an auditor's opinion that runs to dozens of pages, which the vendor controls and typically delivers under NDA. For a Swiss bank's procurement file, the certificate is the cleaner artefact.
Scope of obligation. ISO 27001 anchors security in a documented information security management system (ISMS) with management accountability and continuous improvement. SOC 2 demonstrates that controls were designed and operated effectively over a period. Both matter; for a bank's regulator-facing inventory, the ISMS framing is closer to what FINMA 2023/1 expects to see.
A vendor that has both is a vendor that has thought about both audiences. A vendor that has only SOC 2 is selling primarily to US buyers. A vendor that has neither is, for a Swiss bank's purposes, not yet ready.
For on-prem deployments specifically, the operational test is whether the stack actually runs without internet egress; we cover what tends to break in Air-gapped deployment: what actually breaks.
Source code escrow and exit
Source code escrow is overrated for SaaS and underrated for on-prem software. For a SaaS vendor, the escrow rarely matters in practice. The operational dependency is on the running service, not on the source code, and a bank that suddenly receives a tarball of the codebase has no realistic path to running it. For an on-prem vendor, escrow is a contingency that can actually be exercised: the bank already runs the software in its environment, and a release of the source unlocks the right to keep maintaining it if the vendor disappears.
The procurement question is therefore deployment-shape-dependent. For SaaS, the meaningful exit asset is data: exportable in standard formats, with documented schemas, on a documented schedule. For on-prem, the meaningful exit asset is source-plus-build: the escrow has to release not just code but the toolchain and documentation needed to build and run it.
A vendor's contract should match its deployment shape. SaaS vendors who offer escrow are usually offering theatre. On-prem vendors who refuse escrow are usually betting that the bank will not push.
Data localisation and cross-border
The FINMA outsourcing circular does not require Swiss data residency. It requires accessibility from Switzerland for resolution purposes and a defensible chain of contractual protections. The revised FADP adds the cross-border transfer regime. Countries on the Federal Council's adequacy list require nothing extra; everywhere else needs SCCs, BCRs, or derogations.
The procurement question is therefore not "where is the data?" alone but "what is the legal pathway?" and "is the bank's evidence file sufficient to satisfy FINMA, the FDPIC, and the bank's own auditors?" A vendor that hosts in Frankfurt under EEA adequacy and SCC fallback is fine; a vendor that hosts in São Paulo without any of those is going to fail the cross-border review even if its security is excellent.
The actual checklist
The questions worth asking, mapped to the regulation that justifies them:
| # | Question | Regulatory hook | |---|----------|-----------------| | 1 | Provide your ISO 27001 certificate (and SOC 2 Type II if available) | FINMA 2023/1 ICT governance; common practice | | 2 | List all subcontractors / sub-processors with access to bank data, and the contractual notification mechanism for changes | FINMA 2018/3 sub-outsourcing | | 3 | Confirm the contract grants the bank, its auditors, and FINMA the right to audit at any time, without restriction | FINMA 2018/3 audit rights | | 4 | Describe the exit plan: data export format, schema documentation, knowledge transfer, source escrow (on-prem only) | FINMA 2018/3 exit; FINMA 2023/1 resilience | | 5 | Where is data stored and processed? What is the legal transfer mechanism for any non-adequate jurisdiction? | nFADP Art. 16-17; FINMA 2018/3 cross-border | | 6 | Confirm contractual protections that allow the vendor to be treated as an Art. 47 BankG agent (confidentiality regime, access restrictions, encryption, purpose limitation) | BankG Art. 47; SBA 2019 cloud opinion | | 7 | Provide RTO/RPO commitments mapped to the function provided | FINMA 2023/1 resilience | | 8 | Provide a cyber-incident notification SLA and a named technical contact | FINMA 2023/1 cyber-risk | | 9 | List concentration risks (cloud region, single upstream provider, single key custodian) | FINMA 2023/1 ICT | | 10 | Confirm a written DPIA exists for the processing relevant to this engagement | nFADP Art. 22 |
Anything beyond this list is institution-specific. Anything missing from this list is a gap in the procurement file that the bank's auditor or FINMA inspector will eventually find.
Bottom line
A Swiss bank evaluating a software vendor is doing two things at once: a normal commercial procurement, and an exercise that has to hold up to FINMA. The two are not separable. A vendor selling into the Swiss market should answer the FINMA-grounded questions proactively, with the relevant circular cited next to the answer. That alone separates the vendors who have done the work from the ones who haven't.
