Architecting SWIFT Connectivity on Amazon Web Services (AWS)
AWS Architecture BlogArchitecting SWIFT Connectivity on Amazon Web Services (AWS)by Jack Iu, Henry Su, and Gloria Vargas | on20 APR 2021| inAdvanced (300),Amazon MQ,Amazon RDS,Architecture,AWS Direct Connect,Financial Services|Permalink|ShareThe adoption of the ISO 20022 messaging standard by the financial industry will benefit all participants across the payments chain: banks, market infrastructures, corporate, and consumers. By moving the SWIFT messaging and communications infrastructure stack onto AWS, customers can speed their adoption of ISO 20022. At the same time, they can reduce costs, and improve security and resiliency of their critical payments channel. AWS Cloud adoption will also enable banks to be more agile and innovate using the rich data model of ISO 20022. They will be able to provide their own customers with an improved payments experience.SWIFT Connectivity Architecture TypesCustomers have several options to connect to SWIFT, each with varying architectures. There are three common architecture patterns:Use CaseMessaging InterfaceCommunication Interface + SecurityFull StackGlobal corporatesHigh volumes~Millions of transactions per yearCustomer fully owns and operates:Alliance Message Hub (AMH) or SWIFT Alliance Access (SAA)Customer owns and operates:SWIFT Alliance Gateway (SAG) and SWIFTNet Link (SNL)SWIFT Hardware Security Module (HSM), and Alliance Connect VPN (VPN)Partial StackVery Large corporates~Hundreds of thousands of transactions per yearCustomer owns and operates:AMH or SAACustomer outsources to a Service Bureau to host:SAG and SNLHSM and VPNLite2Medium to Large corporates~Hundreds of transactions per dayCustomer owns and operates:SWIFT Integration Layer (SIL)Customer owns and operates:DirectLink/AutoClientVPNWhile this blog post provides a migration approach from a Full Stack on-premises SWIFT infrastructure to AWS, the architecture principles also apply to the other two types of SWIFT architecture patterns.Reference ArchitectureFull Stack SWIFT implementation on AWSThe reference architecture shown preceding represents an example pattern for the Full Stack SWIFT implementation on AWS. SWIFT connectivity is considered a critical infrastructure for financial institutions, which must achieve high availability to facilitate cross-border and high value payments. The top priorities for consideration areresiliencyandsecurity. Therefore, the primary SWIFT connectivity stack should be deployed in multiple Availability Zones (AZ) for high availability and in multiple AWS Regions for disaster recovery (DR). Availability Zones give customers the ability to operate production applications and databases that have several benefits. They are more highly available, fault tolerant, and scalable than would be possible from a single on-premises data center. For DR, the same topology is also deployed to a different Region. The primary and secondary Regions should be carefully chosen to minimize the latency for cross-site replication while also satisfying regulatory requirements.From a security perspective, customers are required to comply with SWIFT’s Customer Security Controls Framework (CSCF) and attest against SWIFT’s mandatory security controls. You can find the CSCF guidance for a deployment on AWS and infrastructure as code deployment template in ourAWS QuickStart for SWIFT Client Connectivity.Secure Communication: SWIFT HSM and Alliance Connect VPNBesides software components, SWIFT requires two hardware devices to secure the communication with the SWIFT network in the Full Stack option: SWIFT provided HSM and VPN.TheSWIFT HSMserves two main purposes: signing SWIFT messages for non-repudiation and storing private key and associated certificate information. SWIFT currently offers the HSM as a hardware appliance. You can use an AWS Partner colocation facility to host this component. This ensures the latency between the SNL and HSM is minimized as that connection is latency sensitive.SWIFT Alliance Connect VPNis responsible for establishing IPsec VPN tunnels to SWIFT Multi-Vendor Secure IP Network (MV-SIPN), and is currently also offered as a hardware appliance. The VPN component can be deployed in the same location as the HSM but they must be segregated and isolated from a networking perspective.For connectivity to SWIFT Points of Presence (POP), customers can consult with SWIFT Network Partners to establish either a private leased line, or internet connectivity from the colocation facility to SWIFT. For cloud connectivity, colocation partners typically offer Cloud Connect fabric. This can establish network connectivity between AWS and the SWIFT HSM/VPN throughAWS Direct Connect.Deploying HSM and VPN in an HA configuration is out of scope for this blog. For the SWIFT-provided resiliency guidance on this topic seeResilience Guide.Communication Interface: SWIFT Alliance Gateway, SWIFTNet Link, and SWIFT Web PlatformSWIFTNet Link (SNL)provides functionality to access SWIFTNet messaging services over the SWIFT MVSIPN network.SWIFT Alliance Gateway (SAG)is a software package that is installed on top of SWIFTNet Link. SAG enables application-to-application communication and facilitates connectivity to the SWIFT MVSIPN network. Alliance Web Platform (SWP) is a web interface for managing and configuring the SWIFT Alliance Gateway.SWIFT offers SAG and SNL as a licensed software package on Red Hat Enterprise Linux (RHEL) or Windows Server operating systems. It can be installed on anAmazon EC2instance with a static IP assigned. The static IP is mandatory and required for the VPN component to reach back to it. Customers should deploy multiple active-active SAG/SNLs across AZs to ensure high availability of the system. In the event of a host failure, the system operator would take action to recover.SWIFT Web Platform, a component required for administration tasks, should be installed on a different EC2 as SAG/SNL.  Since it is an administrative portal, the recommendation is to isolate it from the main messaging transaction flow.With SAG and SNL deployed on EC2, customers can leverage a variety of AWS services. They can includeAWS Systems Manager,EC2 Image Builder, andAWS CodePipelineto automate patching, software installation and software deployment. AWS Systems Manager can prepare and execute runbooks to remediate and recover from system failure. EC2 Image Builder would alleviate the need for SWIFT administrators to follow tedious installation and configuration steps to install SWIFT software. Finally, AWS CodePipeline can be used for the host deployment to accomplish immutable infrastructure.Messaging Interface: Alliance Message Hub and SWIFT Alliance AccessAlliance Messaging Hub (AMH)is a flexible, customizable, and scalable multi-network, high-volume financial messaging solution designed to help ensure high availability.Alliance Access (SAA)is also a SWIFT messaging interface designed to connect customers’ business applications to SWIFT messaging services.Customers typically decide which messaging interface based on the transaction volumes, messaging functionality, and resiliency requirements. Both solutions depend on Oracle database as the data store for storing the application and messaging state.Amazon RDS for Oracleis recommended for deploying AMH or SAA on AWS asAmazon Relational Database Service (RDS)greatly simplifies database maintenance tasks. An Amazon RDS Multi-AZ deployment ensures zero transaction loss in the event of an Oracle instance failure.Most customers deploying AMH or SAA rely on a message broker and both messaging solutions support a JMS Connector.Amazon MQis a managed message broker service forApache ActiveMQthat streamlines set up and operates message brokers on AWS. Amazon MQ – Active MQ provides all the standard JMS features including point-to-point (message queues), publish-subscribe (topics), request/reply, persistent and non-persistent modes, JMS transactions, and distributed (XA) transactions.SWIFT AMH team has published ahigh availability reference architecturefor running AMH on AWS.ConclusionThe upcoming industry-wide standards change is due to take effect starting November 2022, and will impact the entire cross-border payments value chain. For customers currently evaluating migration options to meet SWIFT’s new Cross-Border Payment and Reporting (CBPR+) message formats, we hope this blog provides you an approach for migrating your SWIFT connectivity stack to AWS. You will begin to realize the agility, reliability, resiliency, and security benefits inherent to the cloud.TAGS:Architecture,CBPR,Cloud Security,CSCF,CSP,IS020022,Payments,QuickStart,Resiliency,SWIFTJack IuJack is a Global Solutions Architect at AWS Financial Services. Jack is based in New York City, where he works with Financial Services customers to help them design, deploy, and scale applications to achieve their business goals. In his spare time, he enjoys badminton and loves to spend time with his wife and Shiba Inu.Henry SuHenry is a Customer Solutions Manager at AWS Financial Services where he works with large and complex enterprises to enable their multi-year journey to the cloud. Outside of work, he enjoys playing with his twins and teaching them golf and tennis.Gloria VargasGloria is a Global Account Manager at AWS Financial Services supporting SWIFT in their cloud journey. She has over 20 years of experience in technology and financial services and enjoys photography and travel in her spare time.
The adoption of the ISO 20022 messaging standard by the financial industry will benefit all participants across the payments chain: banks, market infrastructures, corporate, and consumers. By moving the SWIFT messaging and communications infrastructure stack onto AWS, customers can speed their adoption of ISO 20022. At the same time, they can reduce costs, and improve […]
Jack Iu
Advanced (300) Amazon MQ Amazon RDS Architecture AWS Direct Connect Financial Services