SWIFT for Corporates: Is it the Right Solution for Me?

While corporate access to SWIFT actually commenced back in
1997, with the treasury counterparty model supporting the Message Type (MT)
three digit series messages covering foreign exchange (FX) confirmations, Citi
was a leading supporter for the introduction of a new corporate access model
back in 2001.

The birth of the member-administered closed user group
(MA-CUG) effectively paved the way for corporates to simplify and standardise
their connectivity to their banking partners, not just across cash management
but also across their core financial services covering FX, securities and trade.
Given that MA-CUG required corporates to join each banking partner’s own closed
user group, with the associated challenges around proprietary documentation, it
is no surprise that a new and improved model – Standardised CORporate
Environment (SCORE) was introduced in 2007.

Citi was a proactive
member of the SWIFT corporate access group (CAG), which focused on providing a
more standardised corporate access model, underpinned by a SCORE agreement that
the banks would use as a core basis for their own client-facing documentation
with additional clauses typically linked to services and liability. Once a
corporate had joined SCORE, they had the potential to access all banks that had
also joined SCORE. Although the MA-CUG model is still in existence, the reality
is that virtually all new SWIFT for corporate implementations are based on the
SCORE model.

Industry Trends

Moving onto the specific
point around suitability of SWIFT, it is important to firstly consider the
challenges that currently exist in your own corporate banking environment. Where
corporates operate in a multi-banking environment, typically there is
complexity, inefficiency and cost associated with the proprietary banking
technology and a plethora of different formats – and even interpretations of
formats. There are very clear industry trends around the following areas, as
corporates seek to achieve financial and operational efficiencies through
greater centralisation and automation:

  • Consolidation of
    Connectivity Channels: 
    Simplify technical and solution architecture and reduce
    potential failure points by replacing various bank-proprietary connectivity
    channels with single secure, robust and scalable bank-neutral connectivity.
  • Harmonisation of File Formats: Achieve efficiency by building the process
    around strategic file format. Depending on the business requirements, this can
    be a combination of existing core formats, SWIFT industry standard messaging or
    new industry standards, such as ISO 20022 XML.
  • Rationalisation of Banking
    Relationships:
      Reduce the integration effort and achieve greater consistency of
    services by consolidating treasury and shared service centre (SSC) activity
    around fewer banking partners offering wide geographical and functional
    footprint.

The Benefits of SWIFT

Focusing purely on the cash
management space, the Figure 1 highlights the potential migration from
complexity to simplicity with a more standardised and simplified destination
architecture.

Figure 1: Potential Migration from Complexity to
Simplicity for Cash Management.

Citi SWIFT Migration diagram
Source: Citi.

From the
above it can be seen that SWIFT clearly provides a possible answer to the first
two areas covering both the connectivity and underlying file transmission
security. We can now focus on the underlying benefits that can be achieved
through adoption of SWIFT.

Architecture: SWIFT is now connected to
around 9,000 banks in over 200 countries. While not all banks have joined the
SCORE model, SWIFT is acknowledged as providing a secure, resilient, scalable,
reliable bank agnostic interface to the banks already connected. The opportunity
for a single strategic banking interface, across not only cash management, but
FX, securities and trade is recognised as a major benefit and with 99.99%
availability this can be a compelling argument from a technology standpoint.

A further consideration around the architecture is the time, cost and
risk associated with using bank proprietary applications. This really considers
the underlying manual processes, the requirement for data re-keying, the
on-going maintenance of user profiles and the associated requirement for
separate security devices and passwords for each separate banking application.
All of these factors effectively limit the full benefits of the investment in
the enterprise resource planning (ERP) and/or treasury management system (TMS)
technology as a more fully automated process simply cannot be achieved.

Visibility and Control: One of the very real challenges today is for
corporates to achieve full visibility and control of the cash at an enterprise
level. Different proprietary systems and interfaces combined with different
reporting formats add to the complexity around optimising the use of cash. SWIFT
provides an opportunity to receive both timely and more standardised balance and
transaction reporting in terms of the actual file format, which offers very real
benefits in terms of improving the overall liquidity management. Whilst Treasury
will be able to leverage the MT942 intraday statement, the SSC or payment
factory will be able to use the end of day MT940 statement for the account
payables (A/P) and receivables (A/R) reconciliation process. 

At this
point, it is also important to emphasise that SWIFT does not in itself provide
the implementation of a harmonised bank agnostic file format. For example,
whilst the MT940 end of day statement is clearly defined in terms of the field
definition, the underlying data content may be different across banking
partners. Additional content differences will also apply, based on the payment
or collection instruments within each country. While these differences are
allowed under the SWIFT definition, it does create additional development effort
on the corporate side that needs to be clearly scoped in order to achieve
maximised operational and financial efficiencies.

Improved
Straight-Through Processing (STP): 
This benefit is really based on the
automation of the payment process and the associated removal of manual
processing and keying of payments data. Clearly this also works on the basis
that the information contained in the ERP and/or TMS applications is correct so
the transactions are processed by the bank without rejection.
  
Counterparty Risk/Compliance: SWIFT provides a simplified and standardised
architecture which provides easy and quick banking integration. This in turn
provides portability of banking partners as it is easy to on-board new banking
partners. Furthermore, from a compliance perspective, using a single
multi-banking interface simplifies and indeed reduces the administration work
required to document and maintain around the banking process.

FIN or
FileAct?

The next point to consider in the possible path to adoption
is around which SWIFT service(s) are actually used. From a corporate
perspective, a common trend is emerging where the treasury operations use the
FIN service to support real time SWIFT messaging. This would typically embrace
the MT101 for the real time payment instructions and the MT942 for intraday
updates. However, the SSC or payment factory has responsibility for processing
the A/Ps and A/Rs transactions in addition to completing the cash application
process. As this generally requires the processing of bulk transactions, the
FileAct service is used to deliver transaction files and receive associated
acknowledgement and transaction reporting files. 

The blended
approach ensures both business areas operate efficiently and effectively. This
explains why, in Citi’s experience, 40% of corporates have chosen to use both
services. However, it is also clear that some corporates have taken the decision
to only use the FileAct service across both treasury and the SSC/payment
factory. The key consideration with this approach is that FileAct is designed to
support a file based process, whereas FIN supports real-time message processing.
While this is a point that corporates may need to discuss with their respective
banking partners, the general view is that using FileAct to deliver a batch of
MT101 treasury payment instructions will generally be slower but, given the
number of corporates that have already implemented this model, this delay is not
believed to be significant. 

A final consideration on whether it is
better to leverage FIN or FileAct to initiate MT101 treasury payments is around
one of the key benefits of using FIN messaging – the real time validation of
messages to ensure SWIFT compliance. By using FIN, the corporate will have
immediate visibility of any messages that are rejected as part of the SWIFT
network validation rules. This real time response will help with a more timely
and efficient exception handling process. A further benefit, depending on the
underlying capabilities of the core banking partners is the additional bank
generated real time automated response – the MT199 message which confirms the
validation status at a bank level and provides opportunity to further improve
the exception handling process where a payment instruction is rejected by the
receiving bank. It is evident that an increasing number of corporates are
including the MT199 as part of their overall solution architecture as the
alternative approach is typically based on the receipt of the intraday MT942,
MT940 end of day statement or a phone call/fax from the bank’s customer service
team to advise of the rejection. Each of these represents a much slower
alternative, which could result in the beneficiary being paid late. 

The blended approach is also being used for the delivery of MT940 bank
statements. There appear to be two primary considerations for this approach.
Firstly, some service bureaux operate an itemised charging structure, which
includes the receipt of MT940 bank statements via FIN or the receipt of a
FileAct envelope. By consolidating the MT940 statements into a regional file for
example, this may offer a significant saving on the overall charges applied by
the service bureau. The second consideration is from an IT perspective and
whether it is more technically efficient to receive a single FileAct envelope
containing the MT940 statements or a plethora of individual MT940 bank
statements. This is a question that will need to be considered as part of the
initial technical analysis.

Final Considerations

This
final section focuses on some of the core principles around the charging model
and the associated total cost of ownership of a SWIFT-based solution. While some
of the charges associated with a SWIFT based solution will depend on the actual
integration model, SWIFT charges are based on the model of sender pays.

While this core principle is probably widely appreciated and understood,
SWIFT also has a concept of domestic and international fees associated with the
delivery of messages or files across the SWIFT network. From a FIN perspective
and based on the latest published tariff, there is a significant difference in
charges between a domestic and internal SWIFT network fee. Bearing in mind an
MT101 payment message normally represents two chargeable units; a corporate
would be charged 11 eurocents for a domestic network fee and 37 eurocents for an
international network fee.

As SWIFT determine the domestic and
international network fees based on the location (country code) of the sender
and receiver bank identifier code (BIC), this could have a bearing as to where a
corporate registers their BIC code. It means that an MT101 message sent from a
UK registered BIC to a banking partner with a UK registered BIC would attract a
domestic network fee (effectively a postage charge in simple terms), whilst a UK
registered BIC to a non-UK registered BIC would attract an international network
fee.

Another important aspect is around whether the company’s core
banking partners have the architecture and flexibility to be able to mirror the
country code location of the corporate BIC as this ‘matching’ of sender/receiver
BIC locations will help reduce the overall cost of SWIFT charges. This may
therefore be a question that any corporate considering SWIFT wants to ask their
core banking partners in order to have greater visibility on the total cost of
ownership.

In terms of the potential savings that can be achieved
through this concept of a consolidated BIC architecture, a multinational oil
company that sends around 11,500 MT101 messages per month, of which
approximately 65% are classed as international, has saved an estimated €23,000
annually.  Another global company that generates 5,000 MT101 messages per month
that are all classed as international has saved over €15,000 per year. Given the
constant pressure to reduce overall costs, this is one area that corporates need
to consider as part of their SWIFT solution analysis as not all banks are the
same.

The second aspect of charging that needs to be considered is
really to ensure there is full clarity around the various charging points. For
example, under a pure file based host-to-host (H2H) connection, there would not
typically be any network charges associated with the delivery of the file –
either domestic or international. Charges may therefore just relate to the
receiving banks file processing costs. However, where a service bureau is used
to connect to SWIFT, charges may be applied in respect of:

  1. The service
    bureau processing the file through SWIFT.
  2. SWIFT network charges.
  3. Receiving banks file processing fees.

It is therefore important
that a clear understanding of the entire component charges are fully understood,
in order to ensure that any final cost/benefit analysis is both detailed and
accurate to support the required internal business case.

The final
point on this section is really just to emphasise that leveraging the services
of a service bureau to access SWIFT effectively means you are outsourcing to a
third party. Bearing in mind this will be an integral part of your cash
management/banking architecture, the SLA will become a very important document
to help underpin the relationship. 

Conclusion

Whilst
SWIFT is clearly not the answer in every case, for the multi-banked corporate
there are very real benefits around adoption. Clearly a detailed evaluation of
both the commercial benefits and the service proposition of your banking
partners will help provide a foundation to the decision-making process, but some
corporates have taken the decision to adopt SWIFT based on a more strategic
perspective rather than a pure cost-based analysis. The benefits of a highly
secure, scalable, resilient solution that provides great portability and good
risk management can outweigh the simple cost benefit analysis approach.

There is also added consideration around the number of banking partners
in both the payables and receivables space as a blended approach might be more
appropriate. There is no hard and fast rule in terms of the minimum number of
banking partners before it becomes worthwhile considering SWIFT as a solution,
given the different connectivity models available today.

From a Citi
perspective, the group recognises the importance of client choice around
corporate access and has been a leading supporter since 2001. As the payments
landscape has changed, with an increasing number of corporates looking to adopt
open standards, It is very clear the SWIFT model has clear benefits and we
firmly believe more corporates will join the path to adoption. 

331 views

Related reading