Swift for corporates

This is now set to change as direct connectivity to SWIFT becomes a real option for corporates trying to reduce the cost and risk of making an increasing volume of international payments. In this article, Jonathan Williams, Principal Market Strategist for Eiger Systems, explores the issues that need to be considered.

Introduction

Corporate awareness of SWIFT ranges from almost complete ignorance to concern over the cost and upheaval involved in migrating to a SWIFTNet -based environment.

This does not sound like a ringing endorsement for the success of SWIFT’s recent SCORE initiative, which promotes the benefits of SWIFTNet . Such a conclusion, however, is too harsh. Corporate treasury and finance departments continue to be weighed down by a plethora of changes across their activities. It is understandable, perhaps, that consideration of an optional change, such as migration to SWIFTNet, might not get the full attention of senior finance and treasury executives.

However, in this article I will suggest that SWIFTNet can play a useful role in reducing the cost of payments and, perhaps just as important, reduce the risk inherent in the payments process. One outcome of this for companies based in or trading with Europe is that SWIFT could make an important contribution towards the introduction of SEPA in 2008. By choosing SWIFTNet as a single communications channel to their bank(s), corporates can simply and effectively take advantage of new payment services such as the SEPA schemes and new standards, including UNIFI/ISO20022.

Is change justified?

There are several reasons, essentially related to flexibility and efficiency, as to why corporates might wish to consider migrating their financial messaging to SWIFT.

Firstly, the evolution is underway to implement centralised payment factories within companies or groups of companies. A single global implementation of SWIFTNet would facilitate optimum efficiency within a payment factory model, regardless of geographical boundaries or the number of banks involved. Consolidating internal banking messaging requirements on SWIFTNet offers organisations significant efficiency gains .

Secondly, by introducing a standard banking interface, it would become much easier and quicker for corporate users to switch banks or manage multi-bank relationships. This would inevitably help to create a more competitive worldwide banking industry and drive the banks to offer additional value-added services over standard channels to the benefit of their customers

Thirdly, a single payments channel would significantly reduce the total cost of ownership of the current interfaces, specifically internal training, management and administration costs. In a merger or acquisition scenario, this could potentially help bring forward the benefits of such an infrastructure change by removing the need to consider the consolidation of banking arrangements as part of the M&A implementation programme.

Pain threshold

As with any technology-related change, users’ receptiveness to an idea will vary in proportion to the level of pain their current configuration is causing them. Identifying the location of the pain and translating it into a cost that can be reduced or eliminated is, therefore, critical. This is made all the more important, given that migrating to SWIFT is not a legislative or regulatory requirement, in the absence of which, the motivation to explore the opportunity at all may be minimal.

The SWIFT opportunity is focused on the consolidation of multiple, typically proprietary communications channels into a single infrastructure called SWIFTNet. The cost benefit of migrating to SWIFT is rooted in the level of complexity existing, or anticipated to exist, in the future within current communications channels.

Corporate Treasurers typically have a number of systems to interchange data with their bank or banks. Each of these connections – and there may be more than one per bank, depending on the data required and the business system connected – places demands on the user. These demands are diverse and often costly. Where proprietary software is involved, there is always the issue of the cost and availability of technical and development support. Multiple communication links frequently generate management issues, especially with regard to security.

In some cases, with the advent of corporate Internet banking, the incompatibility of security measures introduced to authenticate users has meant that a single terminal needs to be dedicated to an individual bank link. Organisations are, therefore, looking to reduce their total cost of ownership by moving to a single connection with a single service level agreement and single maintenance contract.

BACSTEL-IP vis-à-vis SWIFTNet

In the same context as corporates’ use of SWIFTNet, several technology renewal programmes have recently affected financial services. These include the NewCHAPS project and the forthcoming migration of French clearing from the SIT clearing house to the new STET company. However, many of these have primarily involved banks and hardly touched the wider corporate world.

However, one of the most relevant programmes to impact widely on the corporate community is the migration to BACS’ new communications platform (BACSTEL-IP), mainly for Direct Debit and Direct Credit payment submissions.

This new communications service that, like SWIFT, relies on PKI to secure communications over IP, required the installation of new software to connect internal business applications to payment submission and reporting systems.

This connection of corporate systems to payment systems is, to a large extent, what SWIFTNet can deliver immediately to SCORE or MA-CUG users.

Although there are significant differences between the two technologies, it can be seen from this table that whilst the SWIFTNet proposition for corporates has a broader function, there are also many similarities. This suggests that some lessons have been learnt in the last four years.

	BACSTEL-IP	SWIFTNet for Corporates
Service
Purpose	ACH and Card Payments	Unrestricted, including Payments, Securities, Trade
Data
Input data	Restricted, defined formats only	Unrestricted, including defined formats
Output data	Restricted, XML-based	Unrestricted
Validation	Structure and content validation	For defined formats only
Security
PKI	Multiple, bank-specific	Single SWIFT-provided
Key management responsibility	Corporate	SWIFT
Secure token technologies	Multiple incompatible	Single
Terms and conditions
Service terms and conditions	Multiple, bank-specific	Multiple, bank-specific
Communications terms and conditions	Multiple, technology-specific	Single
PKI terms and conditions	Multiple, bank-specific	Single
Risk	Bank managed
Operational guidelines
Service	Single	Single
PKI	Multiple, bank-specific	Single
Communications
Communications technology	Dial-in, leased-line or Internet	Dial-in or leased line to secure IP Network
Communications link vendors	Single vendor	Single vendor
Communications software vendors	Multiple competitive	Single SWIFT-provided
Business application integration vendors	Multiple competitive	Multiple competitive
To-from	From corporate to ACH	From corporate to any of corporate’s banks

Experience gained

The key lessons learnt from BACSTEL-IP are threefold.First, as a result of poor initial communication, many corporates discovered the need to make infrastructure changes over and above their anticipated budgets. It is, therefore, critical to the success of SWIFTNet that the options available and their implications for internal change are communicated clearly and in good time to those corporates who might be able to benefit.

Secondly, in hindsight, allowing each bank to provide its own PKI to its customers, rather than using an industry-owned PKI system, introduced confusion and delay into the BACSTEL-IP implementation process. Using an industry-owned PKI system would have reduced complexity in the terms and conditions of the service and would have removed the support burden caused by the incompatibility of different PKI technologies.

Thirdly, the key message for corporates is that the issue of whether BACSTEL-IP delivered its return on investment depends on the cost and benefit of integrating legacy systems. Many corporates were content with the systems they had built and evolved, sometimes over many years. The business case for change was, therefore, based on a least-cost proposition. Some organisations gained more benefits by reviewing their systems and considering whether legacy systems could be modified cost-effectively to take advantage of additional data such as exception reports. For all of these organisations, the key was to minimise the change in legacy systems and it was essential to evaluate all of the potential software providers to maximise the return on investment.

Almost all of these systems are mission-critical and during migration to the new service, it is essential to maintain business as usual. Solutions that can support both the old and new service can serve as an effective bridge between the legacy services and the new world.

Conclusion

This article has explored the potential of SWIFT to provide a single messaging infrastructure for both internal treasury communications and as a corporate to bank(s) payment mechanism for UK corporate organisations.

In summary, its primary conclusions are:

1. Whilst there are strong technological and commercial reasons for corporate users to consider SWIFT, the lack of a pressing regulatory or legislative requirement to use SWIFT will undoubtedly impact the speed with which corporate users consider it for payment messaging.
2. Complex organisations, particularly those with legacy infrastructures, or organisations with high volumes of payment messages, have most to gain from consolidating onto a single payments infrastructure. This is one of the enduring lessons to be learnt from the BACSTEL-IP migration project in the UK.

In Europe, corporates should investigate the new and existing services provided by their banks, evaluate the savings to be made by consolidating their communications and plan to take advantage of efficiency gains through standardisation. Corporates should also challenge their payment solutions providers to offer a single gateway that delivers the benefits of a single view, and homogeneous management, across all their payments data.

Jonathan Williams
Principal Market Strategist
Eiger Systems Limited

Biography

Jonathan is responsible for market liaison and new product strategies, also representing Eiger Systems at industry events and conferences. Originally from a technical background, Jonathan joined Eiger Systems in 2002 from a position as European Business Development Manager for Fujitsu Telecom. He has held engineering and IT roles at British Aerospace, Cambridge University and Advanced Telecommunications Modules Ltd as well as senior marketing roles at Virata and Baltimore Technologies.

In addition to strong commercial and customer-handling skills (including sales and support experience), he brings his extensive systems and networking expertise to bear to create solutions for the benefit of customers and partners.

Jonathan holds an MA in Theoretical Physics and a postgraduate qualification in Computer Science from the University of Cambridge and is the Eiger Systems representative to the Euro Banking Association (EBA), APACS Affiliates, Australian Payments Clearing Association (APCA) and BACS Affiliates Interest Group.

Speaking engagements

Payment Opportunities in Agency Banking, London, November 2006
The Single Euro Payments Area, London, November 2006
European Payments, World Online Gambling Law Report e-Payments Intensive, London, July 2006
Embracing the opportunities of European payments, Payment Strategies 2006, May 2006
Bureau Processing, BACSTEL-IP 2004, May 2004
Future of MAILsweeper, MIMEsweeper User Forum, January 2001
ATM and ADSL – a technical overview, ATM Year 98, September 1998

Published articles

2006
Keeping the SEPA timetable on track, GT News
Setting SEPA straight, Finextra

2005
Evolving payments landscape in Europe, Banking Technology
The changing payments landscape in Europe, GT News
Closing the loop in the payments process, Back Office Focus and GT News

2004
Migrating to BACSTEL-IP: How did it go? Payroll World Review
BACSTEL-IP: The corporate opportunity, Financial Computing
All set for BACSTEL-IP? Inside Billing

2003
Where next for eBilling in Europe? GT News
Electronic Bill Payment and data validation, Eiger Systems White Paper
IBANs: a giant leap or a first step? GT News