Frequently Asked Questions
Table of contents
This document has been prepared to answer Frequently Asked Questions from Swift customers about Swift's compliance with data protection laws, in relation to the provision of Swift messaging services.
Although these FAQs are based on data protection standards applicable in the European Economic Area (EEA), the information contained herein reflects broadly-accepted data protection principles, and may therefore be relevant to all Swift customers.
1 Swift data processing operations
1.1 Where are the Swift Operating Centres located?
Currently, Swift has operating centres (OPCs) in the Netherlands, Switzerland and the US, where message data is stored.
Our OPCs are highly secure, and access to them is strictly controlled. Our security measures are designed to prevent unauthorised physical and logical access, and include physical measures that protect premises as well as logical measures that prevent unauthorised access to data.
Swift maintains three OPCs in two different zones (European and Trans-Atlantic) to ensure full site redundancy.
Customers located in countries inside the European Economic Area (EEA), Switzerland and other territories and dependencies considered to be part of the European Union or associated with EU countries, are assigned to the European Zone (OPCs based in the Netherlands and Switzerland) and their intra-zone message data remain in the European messaging Zone.
Customers located in the United States and its territories are assigned to the Trans-Atlantic Zone (OPCs based in the US and Switzerland) and their intra-zone message data remain in the Trans-Atlantic Zone.
Customers in all other countries are allocated either to the Trans-Atlantic or to the European messaging zone according with their preference, and in line with operational and technical criteria, such as load balancing.
Messages exchanged between Swift customers in different zones are stored both in the Netherlands OPC and in the US OPC, as well as in the Switzerland global OPC.
Data is held in two OPCs so that there is always a back-up in the case of disruption to an OPC.
1.2 How does Distributed Architecture work?
Swift global messaging architecture relies on a distributed data processing and storage model. It is intended to provide strong messaging capacity and network resilience, bringing considerable benefits to the Swift community as a whole. It also improves Swift's commercial positioning and is in line with our overall goal of reducing operational costs and prices. Finally, it allows for intra-zone traffic to be processed and stored only in the relevant messaging zone.
The Distributed Architecture partitions the processing and storage of message data into two zones, the European messaging zone and the Trans-Atlantic messaging zone:
- Countries in the European Economic Area (EEA), Switzerland and other territories and dependencies considered to be part of the European Union or associated with EU countries are assigned to the European messaging zone and remain in the European messaging zone.
- The United States and its territories are assigned to the Trans-Atlantic messaging zone and remain in the Trans-Atlantic messaging zone.
- All other countries are allocated to either the Trans-Atlantic or the European messaging zone in line with operational and technical criteria such as load balancing.
Apart from the countries that have been assigned to a zone by default, such as the US to the Trans-Atlantic messaging zone, or European Economic Area countries to the European messaging zone, all other countries may request to change zones.
The current country to zone allocation list is available here.
The Distributed Architecture was designed to ensure that intra-zone messages are only processed and stored in the relevant zone while inter-zone messages are, by their nature, processed and stored in both zones.
1.3 Why does Swift mirror data in different OPCs?
Because its messaging infrastructure is critical to the smooth operation of the financial markets worldwide, Swift is required to protect its network from disruption and against the loss of data.
The Swift messaging services are designed to be available 24 hours a day, 365 days a year, with some planned downtime. Customers are given advance notice of planned downtime per the Maintenance Windows.
Swift maintains operating centres (OPCs) on separate geographic locations to provide full site redundancy. In addition, within each OPC, the central systems are designed to eliminate single points of failure.
Swift has 2 OPCs for a given zone or zone-less service and each OPC can completely host the services by itself.
Data is replicated between the two OPCs to avoid data loss in case of controlled actions or minimize data loss in case of disaster scenarios.
2 Data protection
2.1 How does Swift document its compliance with data protection laws?
Swift's compliance with data protection laws is documented in its customer documentation. Swift has enhanced transparency of both its data processing operations and its compliance with data protection laws in the following documents:
- the Swift General Terms and Conditions set out Swift's confidentiality obligations.
- the Swift Data Retrieval Policy sets out Swift's policy on the retrieval, use, and disclosure of message and traffic data.
- the Swift Personal Data Protection Policy sets out the roles and responsibilities of Swift and its customers with regard to the processing of personal data.
- the Swift Ad Hoc Clauses provide an adequate level of protection for Swift's transfer of message data to its US OPC.
- other relevant Service Documentation provides more information on how the different Swift messaging services work and on the security measures used by Swift to protect data.
2.2 How long does Swift keep data?
Swift offers different financial messaging services, including but not limited to FIN, FINplus, FIN Copy, FIN Inform, InterAct, FileAct, Swift Web Access, MI Channel, SwiftNet Instant and SwiftNet Copy.
Some services offer archival of messages, others do not. The archival periods, if any, for the different services are set forth in the Service Documentation. For example, in the SwiftNet FIN service, customers can retrieve messages up to 124 days.
2.3 How does Swift ensure adequate data protection in its US OPC?
Swift has put in place Ad Hoc Clauses, signed by the Swift group entities in Belgium and in the US, in order to ensure an adequate level of data protection for transfers of messages sent by its European zone customers to its Trans-Atlantic zone customers. These clauses specifically cover personal data contained in message data that relate to individuals resident of the European Economic Area (“EEA”) Member States or from Switzerland, or that are sent by Swift customers established in one of the EEA Member States or Switzerland.
The Belgian Data Protection Authority issued a positive opinion on these Ad Hoc Clauses, considering that they offer adequate safeguards, and the Ad Hoc Clauses were subsequently formally confirmed by Belgian Royal Decree. Organizational and technical measures related to security and data minimisation also add an additional layer of protection for the data transferred.
In many countries (such as in the EEA countries), data protection laws prohibit the transfer of personal data to countries that do not offer an "adequate level of data protection", except under certain conditions.
In Europe, the Court of Justice of the European Union in a decision from July 16, 2020, invalidated the EU-US Privacy Shield, but confirmed the validity of the European Commission’s standard contractual clauses as a legal mechanism to protect personal data transferred from the European Union.
Swift never joined the EU-US Privacy Shield, for none of its products or services. Following the invalidation of the previous data transfer mechanism, the EU-US Safe Harbour program, in 2015, Swift decided to rely on the Ad Hoc Clauses, specifically tailored to its specific role and mission as de facto delegate of the Swift Community.
Read more on the Swift Ad Hoc Clauses and associated safeguards.
3.1 Does Swift have security policies?
Yes - Swift is known for having robust security policies, especially with regard to the protection of message data.
The Swift Personal Data Protection Policy explains which security measures protect message data, and how customers can verify Swift's compliance with these measures.
For the SwiftNet and SwiftNet FIN messaging services, key security commitments are summarised in the Swift Security Control Policy.
3.2 Does Swift encrypt data on its network?
Yes - Swift messages and data flows are encrypted, and both logical and physical security measures are implemented and monitored for continued effectiveness. Encryption and customer-to-customer authentication prevent unauthorised access by, or malicious injection of data from, internal or external sources. We constantly monitor the Swift messaging services for suspicious activity
Some of Swift's services offer value-added processing features based on message data (for example message validation in the SwiftNet FIN service). Message data is decrypted in Swift's central systems, thus allowing the value-added processing to be performed. Message data is then re-encrypted before further transmission to the beneficiary Swift customer.
As set forth in the Swift Data Retrieval Policy, 'message data' refers to the internal content of the message or file transfer.
Please refer to the relevant Service Documentation for more information on encryption and value-added processing.
3.3 Does Swift audit these security measures?
Yes - We are directing you to the Swift ISAE 3000 Type 2 reports. The assurance provided within the ISAE 3000 Type 2 report includes Swift’s External Security Auditor’s independent opinion on the adequacy and effectiveness of our control activities in the area of Risk Management, Security Management, Technology Management, Resilience and User Communication for the SwiftNet and FIN Messaging services.
To request copies of the report, please see instructions on swift.com. You may also send a request to AssuranceQuestions.Generic@swift.com with the full name, and email address of the intended recipients of these reports.