Bob Lyddon

Bob Lyddon

Consultant at Lyddon Consulting Services
Message Message me Posts: 69 Comments: 68
Bio Consultant in payments, electronic banking, banking regulation and international banking services. Career History IBOS 2003-2016; PwC 1997-2000; BankBoston 1994-1997; ManTrust/Chemical 1985-1994; Sanwa Bank 1994-1995; Lloyds Bank International 1980-1984.



MT202 COV defunct thanks to court decision

24 Sep 2019

It is surprising to find nothing on the agenda of SIBOS conference or the SWIFT Payments Market Practice Group about the recent court decision that negates vital content of the SWIFT Message Reference Guide and BIS and PMPG documents on the subject of MT202 COV. The issue is the extent of the MT103 sending bank’s obligation to the MT103 receiving ...


iPagoo’s insolvency puts question mark against NPA

29 Aug 2019

We have recently blogged about NPA and Pay.UK’s loose governance procedures generally, but we need to focus in on the case of iPagoo/Orwell, and its implications for New Payments Architecture (“NPA”), and whether it is soundly based. NPA is essentially the brainchild of Orwell’s CEO and CTO. Orwell’s CEO was a full member of the Payment Strategy Fo...


Netting and pooling, not the same: unless you are the ECB

27 Aug 2019

[First published by AccountingCPD] Many multinational corporates have a pooling arrangement for the cash balances owned by their various subsidiaries. For example this could be with Bank Mendes Gans in Amsterdam, under Dutch law, with every subsidiary holding as many currency accounts as it needs and periodically transferring surplus balances into...


Pay.UK governance and ongoing indications of a fiasco

13 Aug 2019

Having taken a break from following the governance of Pay.UK for a while, a quick skim underlines the prevailing chaos. We have already written about the ditching of a key feature of ISO20022 XML and the broken governance arrangements that have permitted this. There is a claim to openness about Pay.UK’s affairs, but this is belied by both the styl...


Bob is Commenting on

Ripple accused of making false claims about Swift error rates

  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) :)