Predicting the Success of SWIFT Initiatives

SWIFT has over 10,000 users worldwide and the question of
whether a SWIFT initiative will succeed or fail is a very practical one. Users
want to know whether they should be prepared for a development such as eBAM or
ISO 20022 extensible markup language (XML) messaging. Users also spend a
considerable amount of time, both internally and externally, discussing these
initiatives with a view to understanding them, determining if they are relevant
to their needs, and deciding whether to invest in them. Understanding the
factors that determine the success or failure of a SWIFT initiative will improve
the quality of the decision making process and also be of significant short and
long-term value to SWIFT users.

So what are the factors that
determine the success or failure of a SWIFT initiative (the words ‘initiative’,
‘product’, ‘service’ and ‘solution’ are used interchangeably below)?

We’ll start with some of the more obvious ones.

Is it Mandated by

Every few years, SWIFT mandates change. Good examples of this
are the migration from the X.25 to the IP network in 2002-03 and the upgrade to
version 7.0 of the SWIFT systems in 2011-12. Clearly these changes were
successful as the entire community made the migrations – albeit not without cost
and technical challenges in many cases.

However, the success of
these mandated changes is less obvious than it might appear because sometimes
even SWIFT is not successful in mandating such changes. The financial messaging
provider did attempt to make the migration from financial information (FIN)
messages to ISO 20022 mandatory and then withdrew in the face of user
resistance. So, while SWIFT-mandated changes are usually successful, a degree of
caution is advisable even in cases where SWIFT requires its user community to
abide by such mandates.

Does the Product fit the Market

SWIFT undertakes much research before launching any new
initiative, including extensive consultations with users and the global
financial services industry. So it’s usually the case that SWIFT initiatives
address a genuine need in the market and the resultant products and/or services
are designed to provide a solution to that need. There are failures such as
SWIFT’s Financial Information eXchange (FIX) solution, but they are generally
the exception rather than the rule.

Viewing a SWIFT Initiative in

This section will focus on SWIFT initiatives that are not
mandated by SWIFT and make the assumption that they meet a genuine need in the
market. The key point to emphasise is the importance of looking at the context
in which a SWIFT solution is implemented.

The first step in the
implementation is that SWIFT makes the changes to its network and internal
applications, defines the interface and provides documentation that describes
the functionality of the new service and how it is to be used. It is only after
completion of this step that users actively consider using the service.

However, this is only a first step. Business processes and applications must
be adapted to meet the requirements of the new solution not only at the SWIFT
user, but also at the user’s correspondent or messaging counterparty. This point
is so important that it deserves emphasis.

First, SWIFT provides the
solution. Then the SWIFT user has to examine how much their internal business
processes and applications have to adapt in order to implement this solution.
Then the SWIFT user must determine whether their correspondents have the ability
and willingness to adapt their business processes and applications to implement
this solution.

While much attention is paid to the functionality of
the SWIFT solution, it is important to remember that for the solution to work,
business processes and applications at both the user and the correspondent must
align with the solution in order for it to be successful.

specific examples of how this works in practice are available from SWIFT’s
traffic over the last few years for the two relatively new messaging services,
FileAct and InterAct (all figures are from

FileAct is a messaging service where SWIFT does not require that the users
meet any underlying messaging standard. Standards are agreed bilaterally between
correspondents and so are usually chosen to have minimal impact on existing
business processes and applications.

The total kilo characters
transmitted via FileAct grew by 30% in 2010, 40% in 2011, 36% in 2012 and to
date this year is growing at 38%.

InterAct is a SWIFT service where
messages must conform to standards defined by SWIFT (in this sense, it is
similar to SWIFTNet FIN and one of the objectives in its design was to be a
replacement to FIN). To this end, SWIFT has defined hundreds of ISO 20022
messages using the XML syntax that can all be transmitted through InterAct.

In contrast to FileAct, the InterAct messaging service in terms of
number of messages grew 16% in 2010, 6% in 2011, 9% in 2012 and to date this
year is growing at 14%. Note that relationship management application (RMA)
traffic, which is mandated by SWIFT as the only method to authenticate
correspondent relationships over SWIFT, is all InterAct traffic. In addition,
SWIFT has mandated that investment funds move to InterAct and so two significant
components of InterAct traffic are in fact, mandated by SWIFT. If these two
mandatory components are removed, it appears that the growth for InterAct would
be even lower.

When viewed in context of business process and
applications, the reasons for this discrepancy between the growth of FileAct and
InterAct are not hard to see. FileAct requires no change to business process or
application. FileAct does not dictate that any specific standard be followed so
applications at both the user and the correspondent can continue processing data
in the same way that they currently do (but delivered and received through a
different, usually proprietary, messaging channel).

On the other
hand, InterAct requires that the messaging follow the standard specified by
SWIFT so applications have to adapt to cater to these changes. This makes the
implementation more expensive and more time consuming, leading to barriers in
increasing the adoption rate. An interesting point about InterAct was that the
demand and drive for it came from the SWIFT customer base. Many customers who
needed to do development preferred XML, since it is more flexible than FIN and
so there is an XML messaging standards adoption motivation that drove this

Interestingly, these so-called MX-based standards tend to be
used more through the FileAct messaging service rather the InterAct messaging
service because FileAct is usually already operational and so it requires less
effort to put the ISO 20022 XML messages in a FileAct envelope than it does to
implement a robust InterAct-based implementation of the XML standards. Also,
FileAct is less expensive than InterAct from a messaging standpoint, but this
may be a secondary consideration, as is the fact that InterAct messages are
validated by SWIFT, whereas FileAct messages are not.

The single euro
payments area (SEPA) is interesting because the change requires adaptations to
both business processes and applications so one would predict slow adoption. On
the other hand, SEPA is mandated by European Union (EU) regulation.  1 February
2014 is the mandated deadline for SEPA implementation in the Eurozone and
it is as yet unclear what the situation will be on that date

One may argue from this that messaging standards changes underpinned by
regulatory requirements will have a better, if not guaranteed, chance of success
than those changes that are driven purely by technology imperatives.


When reviewing SWIFT initiatives with a view to making a
decision on whether to adopt them, much of the focus is on the functionality of
the initiative and the problem it is designed to solve. While this is necessary,
one must also consider the impact of the initiative on the business processes
and applications at both the SWIFT user and their correspondents. The greater
this impact, the less likely the initiative will be to succeed. 

However, where such initiatives are driven either by regulatory requirements,
such as SEPA, or by industry preferences, such as with the SWIFTNet Funds
initiative, the chances for success are much higher. Nevertheless, they will not
come without cost or the need for devoting significant resource requirements to
their adoption, not only for the users who embrace them, but also for SWIFT and
the various service providers, such as service bureaux and application vendors
that operate within the global SWIFT ecosystem and are often the key to
successfully implementing these new solutions within the SWIFT user


Related reading