Ripple accused of making false claims about Swift error rates

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.

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."

Comments: (13)

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 05 November, 2019, 17:582 likes 2 likes

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 - Lyddon Consulting Services - Thames Ditton 05 November, 2019, 19:252 likes 2 likes

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 - GTM360 Marketing Solutions - Pune 06 November, 2019, 10:471 like 1 like

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
A Finextra member 06 November, 2019, 11:121 like 1 like

@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 - GTM360 Marketing Solutions - Pune 06 November, 2019, 11:531 like 1 like

@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. 

Saqib Sheikh
Saqib Sheikh - SWIFT - New York City 06 November, 2019, 20:02Be the first to give this comment the thumbs up 0 likes

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 - GTM360 Marketing Solutions - Pune 07 November, 2019, 14:14Be the first to give this comment the thumbs up 0 likes

@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
A Finextra member 07 November, 2019, 14:26Be the first to give this comment the thumbs up 0 likes

@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 - GTM360 Marketing Solutions - Pune 07 November, 2019, 17:06Be the first to give this comment the thumbs up 0 likes

@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 - Lyddon Consulting Services - Thames Ditton 07 November, 2019, 18:27Be the first to give this comment the thumbs up 0 likes @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.
Saqib Sheikh
Saqib Sheikh - SWIFT - New York City 07 November, 2019, 19:20Be the first to give this comment the thumbs up 0 likes

@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 - GTM360 Marketing Solutions - Pune 08 November, 2019, 14:38Be the first to give this comment the thumbs up 0 likes

@BobLyddon: 

:) 2030s is almost sci fi!

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 08 November, 2019, 14:48Be the first to give this comment the thumbs up 0 likes

@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.

sponsored

Dorsum white paper - Building your future wealth management solution vol. 2

Trending Stories