MT202 COV defunct thanks to court decision

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

iPagoo’s insolvency puts question mark against NPA

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”),...

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

[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 i...

Pay.UK governance and ongoing indications of a fiasco

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

Pay.UK Board ditches main benefit of ISO20022 adoption

Pay.UK was set up to deliver a New Payments Architecture (“NPA”) for the UK, implementing the blueprint that was passed to them by the Payment Strategy Forum. NPA would be based on the usage of the IS...

Crummy CReM code Part VIII and the low standards for firms to meet

This is the eighth and final blog in our series on the Contingent Reimbursement Model code (“CReM”) that purports to offer customers strong protection against certain types of Authorised Push Payment ...

Transaction Banking

Crummy CReM code Part VII and customers’ added responsibilities

This is the seventh blog out of eight in our series on the Contingent Reimbursement Model code (“CReM”) that purports to offer customers strong protection against certain types of Authorised Push Paym...

Transaction Banking

Crummy CReM code Part VI as customers’ baseline rights are overridden

This is the sixth blog out of eight in our series on the Contingent Reimbursement Model code (“CReM”) that purports to offer customers strong protection against certain types of Authorised Push Payme...

Transaction Banking

Crummy CReM code Part V few customers covered, voluntary for firms, and dependent upon CoP

This is the fifth blog out of eight in our series on the Contingent Reimbursement Model code (“CReM”) that purports to offer customers strong protection against certain types of Authorised Push Paymen...

Transaction Banking

Crummy CReM code Part IV, and ensuring validation of mandatory data at the beneficiary firm

This is the fourth blog out of eight in our series on the Contingent Reimbursement Model code (“CReM”) that purports to offer customers strong protection against certain types of Authorised Push Payme...

Transaction Banking

Crummy CReM code Part III, cause of 'wrong name' APPF and customer’s current legal protection

This is the third blog out of eight in our series on the Contingent Reimbursement Model code (“CReM”) that purports to offer customers strong protection against certain types of Authorised Push Paymen...

Transaction Banking

Crummy CReM code Part II bizarre choice of types of fraud covered by it

This is the second blog out of eight in our series on the Contingent Reimbursement Model code (“CReM”) that purports to offer customers (also known as Payment Service Users or “PSUs”) strong protectio...

Transaction Banking