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.