Frequently Asked Questions
Table of contents
Purpose
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.
Intended Audience
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 Centers located?
Currently, Swift has operating centers (OPCs) in the Netherlands, Switzerland and the United States (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.
The European messaging Zone relies on Swift OPCs based in the Netherlands and Switzerland and the Trans-Atlantic messaging Zone relies on Swift OPCs based in the US and Switzerland.
In each messaging zone, 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:
- Customers located in countries in the EEA, the United Kingdom, Switzerland and other territories and dependencies considered to be part of the EU or associated with EU countries are assigned to the European messaging Zone and their intra-zone message data remain in the European messaging Zone.
- Customers located in the US and its territories are assigned to the Trans-Atlantic messaging Zone and their intra-zone message data remain in the Trans-Atlantic messaging Zone.
- Customers located in all other countries are allocated either to the Trans-Atlantic messaging Zone or to the European messaging Zone, according to their preference andin 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 EEA 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 (i.e. messages exchanged between customers from the same messaging zone) are only processed and stored in the relevant zone while inter-zone messages (i.e. messages exchanged between customers from different messaging zones) are, by their nature, processed and stored in both zones. As a result, message data exchanged between Swift customers located in different zones are stored in all three Swift OPCs.
More detailed information on Distributed Architecture can be found in the FIN and SwiftNet Service Descriptions.
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 services 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 collected in the context of the Swift transaction processing services.
- the EU standard contractual clauses executed by Swift entities provide an adequate level of protection for Swift's transfer of message data to its US OPC.
- other relevant Service Documentation provide specific information on how the different Swift 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, FINCopy, FINInform, InterAct, FileAct, Swift WebAccess, 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?
In some countries (such as EEA countries), the transfer of personal data to countries that are not recognized as offering an “adequate level of data protection” is subject to certain conditions, as set out in applicable data protection laws.
Swift has executed the EU standard contractual clauses published by the European Commission, which have been signed between the Swift group entities in Belgium and in the US, in order to ensure an adequate level of data protection for the transfer of inter-zone messages, sent by its European zone customers to its Trans-Atlantic zone customers. These clauses therefore cover personal data contained in messages sent by customers located in the EEA Member States, the United Kingdom or Switzerland and provide contractual safeguards regarding their transfer to the Swift US OPC.
Swift has conducted a Transfer Impact Assessment (TIA) and implemented specific technical, contractual and organizational measures to ensure an adequate level of protection for the personal data contained in message data transferred from the European to the Trans-Atlantic Swift messaging Zone, and processed in the Swift US OPC. These measures include, in particular:
- Data minimization. The Personal Data that customers reference in financial messages may include identification data (e.g., name, address), financial data (e.g., account number of an instructing or beneficiary party in a payment transaction, when the later involves individuals) or transaction identifier(s). As a result of Swift Distributed Architecture however, messages exchanged between customers from the European messaging Zone remain stored and processed in Europe. The messages sent by a customer from the European messaging Zone will only be processed and stored in the Swift US OPC if the recipient customer is from the Trans-Atlantic messaging Zone.
- Limited recipients, retention periods and purpose. When sent to the Trans-Atlantic Zone, the messages are stored at the Swift US OPC. They are kept for a strictly limited period of time, and solely for the purpose of enabling receiving customers to access and retrieve their messages during that limited period.
- Strong confidentiality protection measures. Cryptographic methods, including encryption in transit and at rest, are used to protect the confidentiality of customers’ messages. In addition, logical access to the messaging services infrastructure and physical access to premises, computer equipment and resources are strictly protected.
- Measures to ensure the integrity of the personal data. Swift has put in place controls to ensure that (i) only authorised customers can access messaging services; and (ii) messages are delivered to the authorised recipients only. In addition, Swift implements mechanisms to protect against unauthorised changes to the messaging service infrastructure and to detect corruption of messages.
- Audits. Messages stored at all three Swift OPCs are subject to the same strict security and data protection standards, no matter where the OPCs are located. Swift’s messaging services are annually audited by Swift external auditors and ISAE 3000 Type 2 reports are made available to customers upon request.
3. Security
3.1 What are Swift’s security policies?
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 Measures document.
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.
