Ripple accused of making false claims about Swift error rates

Ripple has been taken to task for erroneously claiming that six percent of all financial transactions sent over the Swift network fail and require human intervention.

  4 17 comments

Ripple accused of making false claims about Swift error rates

Editorial

This content has been selected, created and edited by the Finextra editorial team based upon its relevance and interest to our community.

Ripple is not averse to a bit of Swift bashing, positioning its own blockchain-based funds transfer model as a more modern and effective alternative to the messaging network operated by the Brussels-based banking co-operative.

In a paper produced for the London School of Economics, banking consultant Martin Walker questions the repeated claims by Ripple executives of a six percent failure rate for Swift messages.

Ripple bases its allegation on a paper published in 2014 by the Swift Institute but authored by two independent payments experts, Kimmo Soramäki and Samantha Cook. However the error rate projected in the model created by the authors referred to the accuracy of the model not the rate of errors in messages.

"In other words, the 'six per cent error rate' was totally irrelevant," points out Walker. "All of Ripple’s commentary on the error rate and what it meant was also, as a consequence, completely erroneous."

While there is 100 per cent guaranteed delivery of messages on the Swift network, Swift's gpi Tracker, which collects data about delays and errors across the interbank network, suggests that delays in payments are typically caused by incorrect data inputs at the bank back-end, and external regulations relating to sanctions screening and foreign exchange controls.

As Walker observes: "Simply changing the mechanism by which banks exchange instructions does nothing to fix any of these problems."

Walker concludes with a poke about the paucity of corresponding information from Ripple about its own performance rates.

"The transparency Swift provides about its network in general is a marked contrast to many fintechs," he writes. "It is probably worth noting that Ripple Labs had never released basic data about their business and network. There is no clarity regarding the number of active, paying customers, nor whether they make a profit from providing payments software. There is not even any public data about the total number or value of transactions processed for banks, the volumes they process using the XRP cryptocurrency or even the number of errors."

Sponsored New Event Report – Natural Capital Finance

Comments: (17)

Ketharaman Swaminathan

Ketharaman Swaminathan Founder and CEO at GTM360 Marketing Solutions

I recently told my customer in the USA to transfer the payment to my company, GTM360 MARKETING SOLUTIONS PRIVATE LIMITED. His bank's cross-border fund transfer system didn't support such a long payee name, presumably because SWIFT, the underlying messaging platform, didn't. He thought PRIVATE LIMITED  was the US equivalent of INC and changed the payee name to GTM360 MARKETING SOLUTIONS INC. The money came to my bank in India, where it was rejected because of mismatch in payee name.

I say this was a failure in SWIFT system. I'm sure SWIFT would claim it was caused by "incorrect data inputs". 

How to settle this debate?

Bob Lyddon

Bob Lyddon Consultant at Lyddon Consulting Services

A 42-character name including spaces should not impose completely insuperable difficulties, using 59F Beneficiary Customer with either No letter option or F. Under No letter option the name can run over the first line of 35 characters and just have LIMITED on the second line; I believe you can then leave a space and start the address, for which you have the balance of the 35 characters on that line and two more lines of 35 characters, and there are no network validated rules for No letter option aside from that Account must be present, and any BIC and IBAN must be valid ones. The data is unstructured in that case. Under F - the structured option - both the first and second lines would have to start with 1/ and you could have the first 33 characters on the first one, with the final word being PRIVAT. The next line would be 1/E LIMITED. You could not start the Address Line until the following line, and you must have 3/Country and Town if you have 2/Address Line, or it will fail a network validated rule. So actually you only have one line for the address, of up to 33 characters. Shortening to Pte Ltd would not get it onto one line and free up another line for 2/Address Line, because you would still have 34 characters with the spaces. Can't you cut out the s at the end of Solutions as well, or run GTM360Marketing together as one word? See, that was easy, wasn't it? I would not see this as a "failure in the SWIFT system" but rather a lack of capacity in the field lengths, which leads to the discrepancy at the beneficiary bank. That should all be remedied by the usage of ISO20022 XML (in our dreams, I suspect) :)

Ketharaman Swaminathan

Ketharaman Swaminathan Founder and CEO at GTM360 Marketing Solutions

Thanks a ton but I strongly suspect the bankers concerned, at either or both ends, don't know half of all these details of SWIFT! Yes, as I too mentioned, it's a problem with field length but bank attributes to SWIFT, so who knows. I've been hearing about ISO20022 for ~15 years. High time I added it to my Fintech Waiting for Godot list:) 

A Finextra member 

@Ketharaman Swaminathan  what an odd remark. ISO20022 will completely take over from FIN by 20126, but all larger banks need to be ISO fully compliant by 20121 /just a little over a year away.  If you bank with a smaller bank that doesn't know how to create international payments, may I suggest to change and look further? Probably they are not working in your best interest. 

Ketharaman Swaminathan

Ketharaman Swaminathan Founder and CEO at GTM360 Marketing Solutions

@FinextraMember @ 11:12:

20121 20126 just a little over a year away - LOL how odd is that?

Reminds me of 15 years ago, when my team had told me, ISO20022 was "a year away" and we needed to urgently rewrite one of our company's software for the new standard. Thankfully, I didn't take it at face value, otherwise, I'd have added one more finserv tech solution looking for a problem. 

Had you read my comment more fully, you'd have realized that the international payment was initiated by my customer's bank in the USA. Me changing my bank is not going to solve the problem. 

A Finextra member 

Great discussion on how we can get the right data, and right the first time in bank payment instructions. 

@Bob Lyddon is right - option F in field 59 for Beneficiary Customer would give you 4 lines of 33 characters to fit the company name @Ketharaman is referring to. Here's an example:

:59F:/12345678

1/DEPT OF PROMOTION OF SPICY FISH

1/CENTER FOR INTERNATIONALISATION

1/OF COMMERCE AND BUSINESS

Likely the issue @Ketharaman had is because an intermeidary bank payment system could not accomdoate the 42 characters and some payment operations staff decided to truncate the name to "INC".

No network will solve this problem, and this is why we need to do the heard work to educate and support banks in improving their data practices.

 

Also, ISO 20022 is around the corner! With adoption window starting Nov 2021, and ending Nov 2025. Find out more at www.swift.com/iso20022programme

Ketharaman Swaminathan

Ketharaman Swaminathan Founder and CEO at GTM360 Marketing Solutions

@SakibSheikh: 

TY for your detailed response. Obviously Sender and Receiver of the payment can't "educate and support banks in improving their data practices". I leave that to your firm's able hands. BTW, the way I understand the specific incident referenced in my above comment, it was the Originating Bank (not Intermediary) who told the Sender (my Customer) that the full name of my company won't fit, so some truncation is required, and it was the Sender who replaced PRIVATE LIMITED with INC. Said education of banks needs to be done ASAP since the originating bank in this case squarely blamed SWIFT for the field length limitation. 

A Finextra member 

@Ketharaman, not sure what you mean about "2021 2026 just over a year away, how odd is that" ? The  2021 first deadline IS just a year away and, as mentioned, the larger banks have no choice just to get their systems ready. My own bank is already organizing testing in future mode. It's not a choice but it's mandatory. 

Ketharaman Swaminathan

Ketharaman Swaminathan Founder and CEO at GTM360 Marketing Solutions

@FinextraMember @ 14:26:

Had somebody asked me when I was lead for FPS implementation at a Top 5 UK Bank in Sep 2007 when FPS would go live, I'd've said confidently Nov 2007 (Memory serves the date was 7th). But we all know what happened and when FPS actually went live.

It's not just then. We recently learned that SCA deadline has been pushed back by ~18 months. And we don't even hear much anymore about once-upon-a-time hot topics in payments like Enhanced Remittance, Confirmation of Payee, etc. So you'll kindly excuse me if I'm a bit skeptical about deadines of payment projects.

I said "20121 20126, ... " - not 2021 2026. That's how your comment appeared / still appears to me, as you can see from the screengrab I've posted here

Bob Lyddon

Bob Lyddon Consultant at Lyddon Consulting Services

@ketharaman I have really enjoyed your comments in this thread. ISO20022 is ‘Global’ because it is used here and there around the globe. The UK is adopting it because the USA looks as if they are adopting it and vice versa: no-one appears to be adopting it because they think it is good. The issue for me is not when the migration starts but when MT messages get taken down and FIN ceases to be available. SEPA saw slow take-up until it was made mandatory by law: the SEPA Migration End Date Regulation. There cannot be an equivalent mandated on every SWIFT member, so I can imagine the migration continuing into the 2030s.

A Finextra member 

@BobLyddon, its happening. FIN MT 1, 2 and 9 messages for FI to FI payments and reporting will sunset and be decommissioned on FIN in Nov 2025. It will not be without investment and hard work, and the ISO 20022 adoption needs to be managed closely, but we do have a deadline we are working towards. You can find out more at www.swift.com/iso20022programme

Ketharaman Swaminathan

Ketharaman Swaminathan Founder and CEO at GTM360 Marketing Solutions

@BobLyddon: 

:) 2030s is almost sci fi!

Ketharaman Swaminathan

Ketharaman Swaminathan Founder and CEO at GTM360 Marketing Solutions

@SakibSheikh:

Maybe I've drunk too much Fintech Kool Aid or whatever but by 2025, even the very notion of money, cross border and transfer might get dismantled by Bitcoin, et al. I've a great regard for what SWIFT has accomplished in the past but, in this era of agile, sprint, iterate, disruption, move fast and break everything etc., I find it very hard to take any project beyond one year deadline too seriously.

Ketharaman Swaminathan

Ketharaman Swaminathan Founder and CEO at GTM360 Marketing Solutions

My "Waiting for Godot" feeling about ISO 20022 just got stronger.

Swift delays ISO 20022 cross-border payments migration

Bob Lyddon

Bob Lyddon Consultant at Lyddon Consulting Services

They have shifted the start date but not, so far, the end date. Such an announcement is never promising, and there are knock-on impacts into the related programmes for TARGET2, EBA EURO1, UK RTGS Renewal, UK NPA (which cannot go live before RTGS Renewal has been proven to be in stable production)...

A Finextra member 

This is just for the CBPR. T2 is business as usual and as I wrote, large banks WILL need to be ready, and they will. The strategies are now completely dufferent and underlying projects have changed. But do you seriously think that Bit coin is taking over the world..? I trust you did not invest all your savings in Bitcoin when you wrote that message?  Good luck..

Ketharaman Swaminathan

Ketharaman Swaminathan Founder and CEO at GTM360 Marketing Solutions

@Bob Lyddon:

Yes, I noticed that. But, having seen the program delay announcement playbook at work several times - and having helped write it on occasion, I must confess - that's not surprising. Even 3-4 months ago, SWIFT maintained that start date would be 2021. It's only as the date has approached that the postponement to 2022 has been announced. End date of 2025 is too far away. If we wait until 2024, we'll hear about the postponement of the end date.

[Webinar] Trusted Transactions: The Future of Risk-Based AuthenticationFinextra Promoted[Webinar] Trusted Transactions: The Future of Risk-Based Authentication