SWIFT Connectivity to Enhance Asian SSC Operational Efficiency
However automated and efficient the technology solutions in a shared service centre (SSC), much of the value of these solutions is lost if an SSC’s communication with its banking partners is not equally efficient. Every SSC has slightly different connectivity requirements, according to their complexity, geographic reach, transaction volumes, internal system infrastructure and the banks with which they work. Consequently, there are various ways for our clients to connect to the bank and access or transmit information reflecting each company’s diversity.
The Society for Worldwide Interbank Financial Telecommunications (SWIFT) is a co-operative founded in 1973 by 239 banks in 15 countries, which aimed to establish a set of standards for communicating information on financial transactions. It has now evolved into a financial messaging network, with almost 8,000 members across more than 200 countries. Its members include banks, broker/dealers and investment managers. Partners exchange a wide variety of financial messages across a common, reliable, secure infrastructure called SWIFTNet. Although SWIFTNet is the network traditionally used by the banks to communicate financial information, corporates now have the opportunity to connect to their banks via SWIFTNet for exchanging a range of financial messages. This has the potential to fundamentally change the way corporates connect with their banks. Corporates in Asia-Pacific are increasingly benefiting from the opportunities that SWIFTNet provides. At the end of 2008, 11% of corporates connecting to their banks through SWIFTNet were based in Asia-Pacific, compared with 20% in North America and 69% in Europe (SWIFT, 31 December 2008).
SWIFTNet is an internet protocol network with encrypted transactions and public key infrastructure security, and is renowned for its security, reliability and availability. Improving efficiency and control are the cornerstones of any connectivity solution: to avoid the risk of error or fraud, reduce costs, and increase processing speed and reliability. Although banking solutions and those of third-party vendors provide very high levels of security and processing efficiency, SWIFT is the global standard used by banks with a guarantee of delivery (including indemnities for direct losses in the event of a lost payment – which has never occurred) and non-repudiation.
There are a wide range of messages that can be exchanged through SWIFTNet. The key messaging services for corporates are the following:
FIN is the primary messaging mechanism used on SWIFTNet, and is generally the first service implemented by corporates connecting to SWIFT. FIN messages include the following, of which the first two are most frequently implemented by corporates as an alternative to the functionality available through a banking system:
SWIFTNet FIN works on a ‘store and forward’ basis. This means although most SWIFT users are connected to SWIFTNet on a permanent basis, in the event that a counterparty bank to which you are sending a message is offline, the message will be stored to a central node and transmitted as soon as the counterparty is back online. This prevents messages failing in the event of access interruptions.
SWIFTNet FileAct is a secure file transfer system for batched messages or large reports and is typically used to send mass payments (such as invoice payments, salaries, etc.), collections and reporting. Messages are exchanged in real time and a range of formats are supported. FileAct is generally best suited to payment factories and shared service centres.
SWIFTNet InterAct is a service for queries and responses based on XML standards.
Reduced costs: The cost of maintaining multiple interfaces can be substantial in organisations with many banks and/or many internal systems that generate payments. SWIFT provides a single channel to connect with financial partners.
The first major step towards widespread acceptance of corporate access to SWIFT was the launch of the member-administered closed user group (MA-CUG) model in 2001, which was quickly supported by major cash management banks. MA-CUGs enable corporates to connect with 588 banks worldwide (as of July 2008). A corporate (either financial or non-financial) wishing to access SWIFTNet can join one or more MA-CUG. By joining a particular bank’s MA-CUG, a corporate can access multiple branches of that bank, which are connected to SWIFT, both for FileAct and FIN messages. Companies with multiple banking relationships need to join each of their relationship banks’ MA-CUGs. This can be done directly or indirectly, via a service bureau or member/concentrator (see below).
Standardised CORporate Environment (SCORE) was launched in 2007 to provide a more versatile means for corporations to connect to their banking partners, particularly for those with more than one banking relationship. Corporate participants that are registered with SWIFT are able to exchange a range of financial messages with any bank which has registered for SCORE without having to join a MA-CUG for each bank. Around 20,000 corporates that satisfy certain eligibility requirements are entitled to subscribe to SCORE. Participating companies must be listed on the stock exchange of a Financial Action Task Force (FATF) member country. These are essentially countries based in Europe, North America, some parts of Asia-Pacific, Mexico and Brazil. All private companies and companies listed in non-FATF countries (such as parts of the Middle East, South America, Asia-Pacific and most African states) are excluded. However, companies ineligible for SCORE can still access the SWIFT network through a MA-CUG. While the original ’sign up’ process is slightly different, the functionality and day-to-day experience of companies connecting to SWIFT via SCORE or a MA-CUG is the same.
As companies have differing levels of resource and appetite for maintaining technology infrastructure, there are various alternatives for connecting to SWIFT.
When connecting to SWIFT directly, the company itself maintains the infrastructure for connectivity, typically SWIFT gateway software from SWIFT or a third-party supplier. These gateway or middleware applications channel messages to or from SWIFT but the data validation, approval, change control, etc needs to take place before the message reaches the gateway. As the systems from which payments originate have different security and approval mechanisms, many companies that connect to SWIFT prefer to use a payments factory system, including a SWIFT gateway to provide consistent approval, data validation and change control procedures over all payments, irrespective of the payment origin. This also means that payment origination systems need to be interfaced to a single system, which then translates the files into a common format for transmission via SWIFT.
Maintaining the technical infrastructure for SWIFT connectivity requires resources and specialist knowledge in the same way as any other business-critical function, so many corporates prefer to outsource the technical hosting to an expert third party. In fact, SWIFT have estimated that around 80% of corporations connecting to SWIFT now do so indirectly, either through a service bureau or member/concentrator.
A service bureau hosts and maintains the technical infrastructure for SWIFT connection and may also convert the files from a company’s internal systems for transmission via SWIFT. A service bureau provides companies with a convenient and cost-effective solution for SWIFT connectivity without the need to maintain specialist resource internally.
The newest offering for indirect access to SWIFT is the member/concentrator, which has been available since 2005. A member/concentrator provides the hosting and maintenance functions of a service bureau but supplements these with additional business services, such as the administration of the SWIFT onboarding agreement and invoicing.
A simplified option for SWIFT connectivity, known as Alliance Lite, was launched in late 2008 and is available to both MA-CUG and SCORE participants. This is a secure, Internet-based service with simplified connection and cost of communicating with SWIFT, designed for corporates and small financial institutions with fewer than 200 messages and/or files per day.
Connecting systems to achieve STP, visibility of information and consistent processes and controls is one of the greatest challenges facing SSCs today. While this is less of an issue for companies working with one or two relationship banks, problems can be compounded when the number of partner banks is multiplied. Among the most important trends in the cash management industry is the development of a standardised approach to integration between disparate systems, leading to greater automation and control over information throughout the financial transaction lifecycle. Industry players are becoming more united in their support of a single set of formats for structuring financial messages, namely ISO 20022.
We have already referred to some of the problems which companies experience on a daily basis with multiple ways of connecting different systems. But how bad is the problem and is there really a panacea?
According to one study, undertaken by Killen & Associates in 2002, the cost of working capital inefficiencies can amount to US$27m per US$1bn in sales for a typical company. Both banks and corporates recognised that the fragmentation of business processes and integration could not continue. This has resulted in the development of a new XML standard referred to as ISO 20022. All industry groups seeking integration standards are united in their support of XML as the syntax for the new standards.
XML is an acronym for extensible markup language. It is not a programming language itself but rather a set of rules (known as a metalanguage) for building new languages or allowing information held in different systems to be understood – a type of ’dictionary’.
ISO 20022 UNIversal Financial Industry (UNFI) message scheme is the platform that the various industry bodies, including SWIFT, have agreed upon for developing financial messages, based on XML. It includes a development methodology, a registration process and a central repository, including a data dictionary and business process catalogue, so that different organisations and standards bodies maintain consistency when developing financial messages.
Part of the remit of ISO 20022 is payments-related activities (as well as securities, FX and trade services), both corporate-to-bank and bank-to-bank, and it is the basis for the single euro payments area (SEPA) payments in Europe. As well as corporate-to-bank messages (and vice versa), there is also opportunity to standardise both bank-to-bank and corporate-to-corporate messages, such as purchase orders, remittance advices, etc which can be extremely valuable in automating the financial supply chain and has particular applicability for SSCs. The ISO 20022 standard is available today, although it is undergoing continuing refinement and expansion.
Bearing in mind the difficulties that can arise communicating between systems, there are a variety of benefits to a standardised approach:
Efficient, automated bank connectivity models have the opportunity to enhance internal efficiencies created within a SSC by improving the timeliness, quality and scope of information provided, as well as how data can be used, with seamless integration to internal systems. In addition to communication channels, standardisation initiatives such as ISO 20022 are simplifying the way in which corporates, and their banks, with multiple systems and multiple data formats, are able to exchange and use data more effectively.
To learn more about HSBC, please visit their gtnews microsite.