Direct Connectivity to SWIFT

by Bob Dashner, Project Manager, Chevron Corporation

While more than 80% of companies now choosing to connect to SWIFT through an indirect method, such as a service bureau or member/concentrator, this was not an option for early adopters, and some companies still choose to implement direct connectivity. Helen Sanders talks to Bob Dashner, Project Manager for Chevron Corporation’s SWIFT implementation about the company’s experiences of direct connectivity to SWIFT.

What encouraged Chevron to consider SWIFT connectivity?

Like many companies, we were and are faced with the challenge of maintaining multiple secure connections between our treasury management system (TMS) and ERP systems (SAP and JDE), and many different methods of communicating with our various banks and financial institutions. This meant that it was often difficult to create a consolidated cash position in the TWS, and setting up multiple, bank-proprietary, security and control requirements, and interface methods for making payments.

We therefore undertook a treasury technology study with the aim of rationalising our bank connectivity, and the opportunity for corporates to connect to SWIFT appeared at about this time using the SCORE model. We recognised that this method of communicating with our banks would address many of the challenges we were experiencing, so we formulated a business case and started the project in late 2007.

How did you go about the implementation?

We appointed a project manager, and engaged both IT and business resource to help. Our aim was to replace all our existing bank connections through SWIFT. We decided to start by routing information through our TMS, which gave better control and meant that there were a limited number of individuals and business partners involved in the initial process. Once that had been implemented, we would then be able to roll out bank communication via SWIFT to the wider business, primarily the various ERPs A/P interfaces.

We determined that the initial scope of the project was to import bank statements from our banking partners (using the BAI2 format) via SWIFT’s FileAct, and in the second phase, to transmit MT101 messages to five key banks.

Did you choose to connect to SWIFT directly or indirectly (e.g. through a service bureau)?

One of the challenges when embarking on a SWIFT project is the multitude of connectivity issues that arise. Corporates initially will lack the SWIFT connectivity infrastructure that banks have, so establishing direct connectivity can be initially expensive and resource-intensive. While SWIFT has recognised this, as evidenced by the launch of Alliance Lite and Integrator products, the capabilities need to be extended in order that it becomes a viable model for larger corporates or those with more sophisticated connectivity needs. Some of the options include partnering with SWIFT middleware solution partners (for internal-SWIFT message/file interfaces) and SWIFT service bureaus (for establishing the SWIFTNet servers/lines, etc.)

Communication through a single portal, as opposed to using multiple point-to-point connections, will undoubtedly achieve our goals as we roll out the project to more banks.

We weighed the potential advantages and disadvantages of direct versus indirect connectivity. On the one hand, we thought that although more convenient by utilising their experience and economies of scale, a SWIFT service bureau had the potential drawback that another third party would be introduced into the project with an additional level of interfaces. Furthermore, although the initial set-up would be more resource-intensive by connecting directly, once it was established, we believed the maintenance would not be excessive.

Ultimately, we decided that as statements and payments are mission critical business processes, we would keep control over the infrastructure and therefore connect to SWIFT directly. A service bureau cannot warrant performance, unless run by a bank, but the benefit of bank-independence is then lost. We also have an Information Technology (IT) group within treasury, which made it easier for us to consider direct connectivity. This group works closely with central IT to make sure that IT strategy and implementation is consistent architecturally across Chevron, and middleware software is procured using IT procurement resources.

What was your experience of direct connectivity to SWIFT?

Establishing the connection to SWIFT requires a great deal of time and effort and is not for the faint-hearted! We engaged in extensive discussions, with SWIFT and several middleware providers, including RFPs and legal negotiations, which would have been lessened had we worked with a service bureau. We also used the SWIFTNet kit, implementing in both our primary site and disaster recovery site in Houston. SWIFTNet kit options allow bundled pricing on much of the SWIFT software, hardware and initial lines. The IT network infrastructure is highly complex, particularly when integrating it into the internal environment, such as integrating our internal firewalls, switches, routers, etc., so support from IT network security and others is essential when needed. In addition, we were not able to use our existing AT&T business services using the kit, since the kit mandates using a different SWIFT Network Partner. While we could have used a single server, we decided on a multi-server environment to add resilience to our SWIFT infrastructure, although it added somewhat greater complexity and costs. [[[PAGE]]]

What about the other elements of the project?

We started our initial project with multiple banks, and in some cases, it can take a long time to get each bank on board, particularly as the documentation requirement is not yet aligned in standard ways. For example, the SCORE agreement does not cover connectivity for both the parent company (since the SWIFT SCORE agreement is between the parent, i.e., Chevron Corporation, BEI (BIC) Code=CVRNUS6S, and SWIFT) and all its subsidiaries (affiliates); and, in addition, the master electronic banking agreement with each bank usually does not incorporate SWIFT connectivity provisions; even though there may be existing electronic banking agreements in place. As a result, in some cases, we additionally had to complete separate documentation for each country, within a single banking relationship, including local language requirements. Consequently, the documentation effort can take a long time, although it can take place in parallel with other activities.

What is the current status of the project and what benefits have you gained so far?

We decided to use FileAct so that we could continue to use our BAI2 formatted files, as well as taking advantage of SWIFT lower network traffic costs for bulk files, vs. FIN messaging, using MT940s, MT942s. We have completed work with five banks for BAI2 statement reporting, and will be adding more banks, as about four are in process now, with more to be added in the future; this will enhance our global cash visibility, which is one of the primary objectives of the project.

Communication through a single portal, as opposed to using multiple point-to-point connections, will undoubtedly achieve our goals as we roll out the project to more banks. Most banks support FileAct, although there have been some small difficulties in specifying what data is needed in the FileAct wrapper, e.g., file name, request type, etc.

At this stage, we have decided that MT 101 messages have so many variations between banks that the business case is not yet strong enough, but we will revisit this area in the future. Although using XML formats would likely address this issue, this is not currently supported by all banks, and does not include enhanced tags to allow more detailed information. In the future, as part of new projects, such as an ERP or TMS upgrades, and/or a change in banking partner(s), we may consider implementing XML; and, in addition, we are considering using InterAct for real-time processing.

What advice would you give to other companies considering SWIFT?

The direct versus indirect connectivity question is an important one. Based on our experiences, we would suggest serious consideration of a service bureau. There is enough new technology in the SWIFT environment that is different from the typical treasury IT infrastructure to require specialist skills to be engaged. There are independent service bureaus, and those operated by banks; in the case of the latter, while there is a potential loss of bank independence as companies are potentially locked into their banks’ system environments, the reality is that companies rarely change their banks. If a corporate is satisfied with the bank’s service levels and costs, it then may be held more accountable for substandard performance if and when it occurs.

We would also suggest allowing plenty of time for documentation – in reality this means scheduling in what seems an appropriate amount of time, and then doubling or even tripling it!

Overall, while the project has been complex, particularly due to our decision to connect to SWIFT directly, it has been very worthwhile in achieving our treasury objectives, and these benefits will continue to increase over time.