PSD2 compliance for leg-out payments difficilitated by the virtual elimination of Cover payments

Banks in the EU/EEA will be obliged – as from January 2018 – to quote all-in prices to their customers for:

1. payments going to or coming from outside the EU/EEA, in any currency; and
2. payments with both endpoints in the EU/EEA but where the currency is a non-EU/EEA one like USD or JPY, and where correspondents in the respective currency centres will be needed to settle the payment.

“All-in prices” means, on the sending side, all of the sending bank’s charges and those of the correspondent it uses to get the money to the beneficiary’s bank or its correspondent: these charges are levied on the ordering customer. On the receiving side, it means all of the beneficiary bank’s charges and those of its correspondents: these charges are levied on the beneficiary.

The default method of making these customer payments is by SWIFT MT103 and the SWIFT charging code that corresponds to the terms of PSD2 is SHA – as opposed to:

• OUR – all charges are for the ordering customer
• BEN – all charges are for the beneficiary

The issue is interlinked with the intention of PSD2 to ensure that the entire principal amount reaches the beneficiary bank (direct through a clearing system or indirectly on its correspondent account), and is not subject to one or more deductions reflecting a BEN code:

• This cannot be enforced on beneficiary banks outside the EU/EEA who are not bound by PSD2, but at least the full principal can be put into their hands;
• This can be enforced on beneficiary banks inside the EU/EEA where the other endpoint is also in the EU/EEA but where the payment is in a non-EU/EEA currency.

The minimum that an EU/EEA bank should be aiming to achieve is:

1. Regarding outgoing payments, to ensure that the full amount reaches any beneficiary bank or its agent, inside or outside the EU/EEA, and whether the payment is in an EU/EEA currency or not;
2. Regarding incoming payments, to receive the same amount through a clearing system or at a correspondent that the beneficiary bank delivered there, and credit it to the beneficiary, without making a deduction itself or having its correspondent make a deduction;
3. To be able to quote a single, all-in charge for any payment, for making it and for receiving it, including any correspondent charges.

The key problem is that most MT103s are now made via the Serial method and not by the Cover method. The Serial method eliminates settlement risk, because each bank in the chain only sees the payment once it has been settled. As a result, prudential regulators prefer it.

The banks involved in a Serial payment chain handle the SWIFT messages used as Account Servicing Institutions for one another, and the SWIFT messages flow between the banks under the SWIFT Customer RMA that they have mutually authorised.

The Cover payment method requires, in addition, a SWIFT Non-customer RMA to be in place between the sending bank and the beneficiary bank.

In general banks have recently undertaken special programmes to cancel SWIFT Non-customer RMA becaise of the Wolfsberg Group's SWIFT RMA guidance, and the way in which this issue was addressed in SWIFT's Customer Security Programme.

The result is that the Serial method ends up being the default way of sending international payments, and the Cover method is possible only where the sending and receiving banks coincidentally have a SWIFT Customer RMA in place for other reasons.

The key PSD2 problem is that, when correspondent banks outside the EU/EEA are involved in relaying an MT103 customer payment under the Serial method that originated inside the EU/EEA (and whether the endpoint is outside or inside the EU/EEA or not), they may well not honour the code SHA in the MT103 they receive from the sending bank, and they may apply a US$10-40 Beneficiary Deduct charge as if the payment were marked BEN, before moving the money on to the beneficiary bank's correspondent.

This precludes the full compliance with PSD2 of sending and beneficiary banks inside the EU/EEA both with ensuring the full principal passes and with being able to accurately state the all-in charges. Banks also run a risk if they quote an all-in price and then their correspondent charges turn out to be higher than anticipated.

The Cover method, however, can sidestep these issues.

The Cover method would be superior to Serial for achieving PSD2 compliance with regard to payments with legs outside the EU/EEA because:

1. the correspondent bank does not handle a 103 but a 202 COV, which has neither the SHA, BEN nor OUR charge code in it
2. 202 COV messages are settled in full i.e. there is no mechanism for deductions from the principal
3. the correspondent's price for processing a 202 COV is likely to be a flat charge in all cases, regardless of the payment's final destination or amount, and to be low – a low single-digit amount in USD
4. this charge is put through the client bank's monthly Account Analysis and is not taken at the time the payment is made
5. the amount of the charge is predictable for the client bank and can be factored into the client bank's all-in price to end-users for payments in that currency
6. the timing of the charge (monthly, in arrears, and separate from the payment) likewise serves the client bank better in terms of managing its responsibilities under PSD2

So, the Cover method would have served EU/EEA banks better than Serial as a way of complying with their legal obligations under PSD2 from January 2018 for the so-called 'leg-out' payments. If Serial is the only available method - and particularly with USD payments where US correspondents will flip the SHA code in a 103 to BEN and take the deduction - the banks will have a major headache and the customers will be disadvantaged.

But unfortunately this recognition comes far too late because of the regulators’ preference for the Serial method and Wolfsberg Group’s guidance on SWIFT Non-customer RMAs.