Moving to SWIFTNet

One of the most difficult hurdles corporate treasuries must overcome when planning a move to SWIFTNet is developing a solid business case, particularly in the current environment when infrastructure budgets are tight

When creating a business case, a SWIFT project should be part of an overall drive towards treasury centralisation. According to Elie Lasker, head of corporate market, SWIFT, the hardest part of the project is what comes before, for example centralising enterprise resource planning (ERP) systems or treasury management systems (TMS), or re-engineering treasury processes.

The ‘icing on the cake’ is then to be able to connect efficiently and easily to the different banks via SWIFT. “A treasurer doesn’t wake up one day and say ‘I want to connect to SWIFT’. There is no significant benefit for a corporate if there isn’t a project aimed at streamlining behind it,” says Lasker.

But once a centralisation project is in the pipeline, where does a treasurer start
when putting together a business case for SWIFT connectivity that stands up to budget pressures?

Developing the SWIFTNet Business Case

A business case should answer the following questions:

1. Which SWIFTNet schemes are available? Which is the most suitable for your business?

2. Will SWIFTNet meet the objectives of increased reliability, control and cash visibility?

3. What are the costs and benefits of the SWIFTNet schemes?

4. How do the SWIFTNet schemes (plus required middleware) fit in the contemplated treasury technology ecosystem, particularly in terms of integration?

5. What are the main risk factors of any SWIFTNet scheme?

6. What does a SWIFTNet scheme implementation plan contain: steps, duration and legal documents?

Let’s explore each question in more detail.

1. Connectivity options: SWIFTNet schemes

- Private infrastructure: a SWIFTNet connectivity infrastructure which is established, owned, operated and managed by a company’s own technical team.

- Shared infrastructure: a SWIFTNet connectivity infrastructure which is established by outsourcing to a third party vendor, commonly called a service bureau, who owns, operates and manages it on behalf of the company.

- Alliance Lite: a simplified, internet-based secure connectivity to SWIFTNet. It is a low-cost, low-volume solution but may not be optimum for central treasury but might be useful if a company wishes to give direct access to SWIFT to its smaller subsidiaries.

It is more usual for corporates to go down the shared infrastructure route, which has a number of advantages including:

- Technical interfacing issues are handled by the service bureau.

- Removes the complexity of managing SWIFTNet environment in-house, while saving costs on IT and SWIFT specific personnel.

- Future-proof access to SWIFTNet services.

Some companies will see disadvantages as well, including the fact that an additional external party adds an element of risk, particularly around the area of storing sensitive data. Reassurance from the service bureau around the handling of this data will be required.

2. Reliability, control and increased cash visibility

Many companies express concerns about the reliability of current electronic banking (ebanking) systems and the possibility of disruption in delivery of information. The SWIFTNet schemes are reliable and form a negligible risk: SWIFT publicly states its availability goal is 99.995%. In addition, SWIFT offers a guaranteed delivery mechanism for payments for messages once the sender has received an acknowledgement (known as an ACK) from SWIFT. They are also financially liable for non-delivered messages.

When using a service bureau, a company will be dependent on the middleware of the service bureau, which might also be seen as adding an element of risk. One of the major benefits of SWIFTNet is that central treasury can gain better control through having all banks report through SWIFTNet, thereby gaining global visibility of bank statements and information. In addition, payment authorisation can be left at a local level, with the possibility of adding a regional signature as required.

SWIFT enables corporate treasurers to achieve greater cash visibility by:

- Enabling them to collect balance and transaction data daily (and intraday) in a standardised form from a corporate’s various banks around the world.

- There is no need to log-on to separate e-banking portals.

- Central treasury receives this information directly from the banks in the regions rather than relying on the subsidiaries to report.

- Standardised data formats means cash balances can more easily be integrated into a TMS or ERP system to create a consolidated view.

- Adding or deleting banks from the list is made easier due to the bankindependent nature of SWIFTNet.

3. Cost/benefit analysis

Many companies are using SWIFTNet as part of a programme to centralise their treasury operations into one location. The main cost benefits will come from a reduction in staff numbers. They also want to improve reliability, gain greater cash visibility and introduce greater control within the treasury structure, which is more difficult to quantify.

4. System fit

For many companies, their TMS will become the gateway into SWIFT. Most or all data and associated security profiles will be stored in the TMS. The main issue is to ensure that there is an interface between both the TMS and SWIFT with flows both outbound for payments and inbound for balance and transactions statements.

Another issue that will need to be decided relates to payment processing. A company may wish to leave local payment processing in the local countries. However, central treasury may want to retain some control over the authorisation of local payments. There are many ways this can be achieved.

One way involves making the TMS the central conduit for all flows but this will require a link between the TMS and the local subsidiaries. This could be achieved by giving the subsidiaries limited access to the TMS payment input module.

Another approach would be to provide the local subsidiaries with SWIFTNet access through a product called Alliance Access. This is a view into SWIFT and allows users to input, verify and authorise payment instructions. These different processes can be physically performed in any location. This means, for example, that a subsidiary could input and verify a payment instruction and then central treasury could authorise it. One of the problems with this approach is that it is outside the TMS and so issues such as bank reconciliation need to be addressed differently.

5. Risks

When a company stops using its bank’s ebanking system, this may impact its relationship with that bank. It is advisable for companies considering a SWIFTNet approach to involve their main cash management banks in the process.

Although the method of receiving information the bank will change, the actual number of transactions being processed by the bank will not. Therefore, the risk is negligible. Many banks already have clients using SWIFTNet and are used to this approach.

6. A SWIFTNet implementation plan

There are then five main stages in planning and implementation:

1. Define the scope

- What services are needed - payments,balance and transaction reporting?

- What banks will be involved and are they SWIFTNet-compliant?

- What type of connectivity is required? Formats and messaging - FIN, FileAct, etc (see Message file formats box).

2. Contact the banks

- The company will need to let the banks know that it intends to use SWIFTNet. New bilateral agreements may need to be put in place with the banks involved.

- Agree service conditions.

- Get copies of legal template if available.

3. Software and connectivity

- Contact SWIFT and/or service bureau.

- Define schemes required.

4. Pilot period

- Join SWIFT.

- Install software and connect to SWIFT.

- Run test pilot.

5. Roll out - per bank

- Kick-off meeting.

- Setup and test live environment.

- Go live.

- Revisit and ensure that objectives have been met.

SWIFT estimates that a project of this size should take between three and six months to complete if a service bureau is used and six to nine months if a direct connection approach is chosen (see Implementing SWIFT box).

Box 1 Message file formats

FIN (individual messages)
● Typically used for single transactions, e.g. high-value payments, deal confirmations and reporting.
● Store and forward delivery of highly structured messages in strict SWIFT FIN (MT) format.
● Messages are validated by SWIFT on transmission.

FileAct (file transfer)
● Typically used for bulk payments (e.g. salaries, commercial payments, direct debits, etc) and reporting.
● Secure file transfer over SWIFTNet.
● Delivered in real time or store and forward mode.
● Files can be in any format - payments files, iDOC, ISO 20022 XML, domestic ACH formats, BAI, etc.
● Not validated by SWIFT.

Box 2 MA-CUG versus SCORE

A ‘very large’ UK corporate currently has more than 300 bank accounts with more than 20 banks. It currently uses in excess of 15 local electronic banking systems. Treasury has approximately 200 payments per day. This results in approximately 4000 payments per month. The number of payments done by the local entities is approximately double that per month.

Presently, payments are sent to the banks by the local entity. The company is currently centralising its payments into a payments factory. With such a large number of banks SWIFTNet is an ideal consideration. The company plans to use its TMS and ERP system in conjunction with SWIFTNet to create and transmit the payment files to its banks and then collect the bank information.

When comparing MA-CUG and SCORE, SCORE is seen as the preferred route for a company who is looking to perform payments and reporting through SWIFT. Given the multiple banks involved, the MA-CUG route would necessitate the establishment of connections with each of these banks separately. This in itself would be a time-consuming and onerous task. The SCORE approach on the other hand provides a single channel to multiple banks allowing the company to operate accounts payable (A/P), accounts receivable (A/R) and treasury-related activities (if required) through the SWIFT network. In this case the corporate used SCORE and a local SWIFT service bureau to connect because it did not feel it had sufficient in-house expertise to build the connection.

First published on www.gtnews.com