A business case for SWIFT

Hi Gary - how would you view ISO20022 in that case? SWIFT are the registrar and proposer, all the ISO messages are SWIFT MX messages, SWIFT does the annual release, but you can use ISO messages without sending them over SWIFT, the reciprocal of using FileAct without the contents having to be MT or MX. The ISO messages are getting a lock over European payments thanks to their being afforded a de facto monopoly under the SEPA Migration End Date Regulation... ???

In my opinion, a financial services world without SWIFT would be like the internet without ICANN, or a country without a Central Bank.

SWIFT is essential to the financial services world, albeit it could try harder to innovate.

First i think that SWIFT is the ISO authority is wrong the clearly have a confliction of interests. ISO20022 can be carried over any network but the Banks have little motivation to change as they also own SWIFT. They can control the pace of change and focus to their own interests

The point about the value of SWIFT and its glue potential holding the industry together is one of the reasons why after twenty plys years the FS industry is still laden with legacy technology and legacy thinking

Other industry have welcomed change and innovation and have benefits consumers but in FS we still have this rather odd and old idea that private networks and centralisation will solve our problems. After so long down this road its about time we all woke up to the fact that the existing system does not work. Certainly not for the world we live in today and the future

So why be defensive lets have an open mind and challenge convention and look for a better way of servicing investors,consumers and society

As Bob and Gary know I am somewhat pedantic so I should point out that not all ISO 20022 messages are SWIFT MX or indeed vice versa. Other organizations other than SWIFT have submitted messages which are not represented in the MX message set. Also the version and variant numbers often differ between messages present in both. Just to confuse things SWIFT also have Solutions such as Clearing, Funds, etc that also sometimes have ISO 20022 compliant messages which are neither published as an ISO 20022 standard nor are the present in the SWIFT UHB MX specifications. 

So as at Q1 this year there were two hundred and something messages published on ISO 20022 website but over 500 different messages and or schema versions/variants published between ISO 20022, SWIFT MX and SWIFT Solutions. For those of you with insomnia I can provide you with the detailed comparison spreadsheet if you contact me!

As a message standard it is becoming anything but; a victim of its own built in extensibility. But then we often forget that ISO 20022 is a methodology and data dictionary; for an actual message to be compliant they don't even have to be XML structures. So perhaps the issue of over which network messages get transmitted and in SWIFT's case validated in certain services, is less of an issue than it would seem if there isn't agreement on the standards themselves.

Thanks Gary and Fiona: what would you recommend to organisations that have built their offerings around SWIFT MT and have reached the terminus of the potential of those messages, for whom SWIFT MX does not seem to offer much more, but whose members are, as you say, anchored in technology that can only deal with MT (or MX translated back into MT), but whose thinking may not be legacy?

Bob,

I know it sounds very traditional, but good old fashioned Business Analysis, tied to a sound vision of what the organization wants to achieve in the way of improved services/SLAs, differentiation against competitors, cost reduction and increased bottom line, is the basic answer. Once you have decided on those things then the Business Analyst, provided you have one or more with the requisite broad knowledge of the standards and delivery landscape, should be able to provide recommendations on the most appropriate way forward. As I said it is good old fashioned gap analysis driven from business requirements/desires. I really don't think corporate planning should be dictated by the standards that are out there or the networks that can transport or validate them.

In the end as my previous post stated, one of the advantages from a selfish point of view is that if there isn't an ISO 20022 compliant message out there that fits your purpose you can always create your own message or variant of one that exists and still claim to be supporting the standard (which technically you are)!

The key to this approach is having an appropriate environment that enables this choice of appropriate data structure per function and delivery channel. There may be differences in real time vs non time critical, totally secure vs secure as it needs to be; adoption of a global standard vs leveraging extensions to create commercial differentiation. Whatever you do don't let your internal infrastructure limit your choices. You might say "of course she would say that" but just because I work for a vendor that has particular interest in this area doesn't necessarily mean that it isn't so. :-)

@GaryW:

Very thought-provoking article.

There's a lot of scope of improvement with SWIFT but, having worked with both SWIFT and BT, BT is hardly the epitome of a nimble, fleet-footed company. Like AT&T, BT too might excel in lab and patent level innovation, but SWIFT is far more customer-centric than the telecom behemoths on either side of the Atlantic. 

While you've talked about "commercial networks" with naming anyone in specific, SWIFT offers corporates something very specific, namely, C2B connectivity to enable corporates to connect to multiple banks, and not to one another. I'm not sure if any of the commercial networks you'd in mind even offers a similar product / service as SWIFT because, as far as I know, corporates connect to multiple banks via (a) their respective bank's Internet Banking portal, or (b) SWIFT bureau services or (c) SWIFT. The admittedly low penetration of SWIFT in C2B is better explained by the resistance of corporates to change from their incumbent connectivity method, which is (a), than to the widespread use of third-party networks supporting C2B, if any. 

Comparing financial services with other industries, proprietary networks are still prevalent in automotive, defence and healthcare sectors, if not others. A wave of Independent Trading Exchanges targeting these industries came and went during the dot com era of the late '90s, dragging the leading marketplace technology providers into virtual extinction along with them. A second wave of such platforms has cropped in the last 2-3 years. The jury's still out whether they're going to be any more successful in ousting the incumbent proprietary players this time around than the last.

To paraphrase Bill Gates words about banking: "SWIFT the format, i.e. ISO, is essential, SWIFT the carrier is not"

We do not need SWIFT to move messages from A to B. Others can and do offer services for that. To its credit, SWIFT has done a good job of moving away from charging only per message, with its bulk pricing. We do though as a banking community need channels and forums for dealing with one another and SWIFT is moving, albeit slowly and arguably late, to improves its post-trade services. The success of ventures like CLS that provide a forum for banks to settle trades and even of the various LCH services show that banks need these forums or platforms to manage settle their business.

To stay relevant, SWIFT needs to provide more than just a message carrying service. 

Agree that SWIFT are now doing the sort of things it should have done years ago. However is the finance industry best served with the existing structure? I have for so many years that SWIFT needs to be more commercial and that is what they are now doing now to a degree. Would the FS industry be better served if SWIFT was commercial and competed on a level playing field?

Agree with you. They want to avoid mistakes, which is great, but over time have become too hidebound. Experiement, fail faster. 

Wow!  SWIFT is way-more than message formats and a network.  It is contracts and standards.

Is every bank in the world going to maintain the metadata and contracts to connect to every other bank in the world?

For that matter, what is a bank?  SWIFT knows and vets them.

Who journals payments and handles disputes, w/o SWIFT?

Then there is SIBOS - who will organize that?

Finally there is the work of SWIFT's Innotribe (@Innotribe), led by Peter Van Auwera (@PeterVan).  They are linking together banking innovators all over the world.  They have proposed the Digital Asset Grid (DAG), a powerful new network concept to deal with the exploding world of APIs.  See the videos of Heather Schlegel (@Heathervescent) to get an idea of their vision of the future world of payments.  You can find them on YouTube by searching for innotribefilms.  I think you will find the four videos there very exciting.

Ketharaman Swaminathan of GTM360 Marketing Solutions commented on how nimble or fleet-footed BT may be, and as someone who works for BT I feel that I should respond – partly because I am often amazed by the way that folks try to compare apples with pears and aren’t up-to-date. 

BT supports the largest secure networked financial community in the world, in terms of the number of customer locations, the geographical reach and the volume of data that that community moves over the BT infrastructure.  It has managed that more nimbly and light-footedly than other organisations – otherwise it would not be in the lead!  BT also offers C2B connectivity and secure messaging services to enable corporates to connect to multiple banks – we’ve been doing that for a dozen years now.  We’ve also been in the secure non-repudiable messaging sector of financial services for the last 16 years. 

And we carry ISO messages, FIX messages, proprietary formats – millions of financial messages per second per customer location, not just millions per day.  Standards are initiated by market participants and vendors, not by a standards registration authority (unless it is acting as a vendor). 

Rather than thinking that the world is still the way it was 40 years ago when banks first set up a private cross-border inter-bank payments messaging system, perhaps it’s time for more people in the Payments and Post-Trade sector to catch up a bit with what’s really happening out there - ?  As Gary Wright of BISS Research has said - times have changed!

Needless to say your way off beam on just about everything but it is interesting the perception you have and the degree of indoctrination that me has been achieved.You did make me laugh about the SIBOS comment though. I assume that was a joke. Thanks for the comments and for brightening my day 

Before someone charges me with providing the trigger for turning this into a BT product and services bulletin, my only comment about BT v. SWIFT pertained to nimbleness / customer-centricity, and that was based on my experience as a customer of both companies. I'm sure there are enough BT and SWIFT customers in Finextra Community and they're free to post their unbiased views about their experiences with them. My questions about the range of overlap of products and services with SWIFT's pertained to the hitherto - and still - unnamed "commercial networks", not BT.