Re. Ripple accused of making false claims about Swift error rates
Ketharaman Swaminathan – GTM360 Marketing Solutions – Pune 05 November, 2019, 17:58 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.
Bob Lyddon – Lyddon Consulting Services – Thames Ditton 05 November, 2019, 19:25 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 – GTM360 Marketing Solutions – Pune 06 November, 2019, 10:47 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 member06 November, 2019, 11:12 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 – GTM360 Marketing Solutions – Pune 06 November, 2019, 11:53 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 to meet the new standard. I was skeptical about the news and decided to do nothing to the software. Good decision. 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.
*: Background for “15 years ago” is explained in the following paragraph of this Finextra article entitled ECB responds to Swift’s blueprint for ISO 20022:
Swift’s last big push to move from MT to ISO 20022 was in 2006, which was scuppered when the 2008 banking crisis deterred the major banks that use Swift from agreeing to this expensive move.
It’s now 2020. “15 years ago”, 2006 was “next year”.
Saqib Sheikh – SWIFT – New York City06 November, 2019, 20:02 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 – GTM360 Marketing Solutions – Pune07 November, 2019, 14:14 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 member07 November, 2019, 14:26 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 – GTM360 Marketing Solutions – Pune07 November, 2019, 17:06 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 – Lyddon Consulting Services – Thames Ditton 07 November, 2019, 18:27 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 – SWIFT – New York City 07 November, 2019, 19:20 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 – GTM360 Marketing Solutions – Pune08 November, 2019, 14:38 0 likes
@BobLyddon:
:) 2030s is almost sci fi!
Ketharaman Swaminathan – GTM360 Marketing Solutions – Pune 08 November, 2019, 14:48 1 like
@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 – GTM360 Marketing Solutions – Pune 17 March, 2020, 12:39 1 like
My “Waiting for Godot” feeling about ISO 20022 just got stronger.
Bob Lyddon – Lyddon Consulting Services – Thames Ditton 17 March, 2020, 13:34 0 likes
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 17 March, 2020, 14:16 0 likes
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 – GTM360 Marketing Solutions – Pune 17 March, 2020, 15:45 0 likes
@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.
—–
Waiting for Godot:
Transformations – the hidden fly in the payment hub implementation ointment
https://www.finextra.com/blogs/fullblog.aspx?blogid=10901
In 2009, TowerGroup published a report titled “Waiting for the (Payments) Hub: A Play in Three Acts”. Here’s a tragicomic passage from this report:
“TowerGroup believes life imitates art when it comes to payments hubs. In Samuel Beckett’s play Waiting for Godot, the main characters, Estragon and Vladimir, wait expectantly, yet unsuccessfully, for a person named Godot to arrive. Although both men claim to know Godot, they admit that they would not recognize him if they saw him. Further, when discussing Godot and what he can do for the men, Vladimir states, “Oh … nothing very definite.” As the play progresses, the men discuss a variety of actions they can take to pass the time until Godot arrives. Unable to decide on a course of action, they ultimately choose to do nothing because “It’s safer,” so they continue to wait, presumably indefinitely.”
This paragraph rang so true in 2009. Six years later, it still rings quite true!
—
Federal Reserve delays ISO 20022 cutover by two years https://t.co/Ffg0O3mxnX via @Finextra .
The Wait(ing) for Godot got even longer.— Ketharaman Swaminathan (@s_ketharaman) July 1, 2022
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?
Report abuse