Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
There are two types of pre- authenticated Payee that banks store on their online systems for their customers.
The first is a friend, or family member, a supplier, or other general contact. For such payees, the payment reference is irrelevant and purely information giving and will change each time a payment is made.
So a payment reference might be ‘Birthday Present’ or ‘Invoice 47584’ etc.
Customers must not be made to have to provide SCA (secure customer authentication) to change the payment reference for these payees.
Whilst the majority of banks do not currently require SCA to change a payment reference, a minority do. These banks cause customer mayhem when the customer wishes to make payment to a pre-authorised payee but with a different payment reference.
The amount of work for the customer to perform to achieve SCA, just to change the payment reference which makes no difference and is purely informational, leads to intense customer dissatisfaction and is not reasonable.
On the other hand, when making payment to, say, a credit card company or a tax authority, the payment reference is all important as it uniquely identifies the account of the payer, and is really part of the payee information, since changing the payment reference will mean that the payment made is allocated by the payee to someone else.
For the majority of banks who do not require SCA to amend a payment reference, this is not suitable security.
The draft RTS mentions Payee details, but does not seem to understand that for the majority of payees their payee details consist only of the IBAN, whereas for a minority of payees the payee details consist of both the IBAN and the Payment Reference. (Article 2(2) and Article 8(2)).
Banks themselves do not understand this, and the result is either mass–customer dissatisfaction, or lack of security.
The resolution is simple – each payee should have a yes/no field added as well as the IBAN field, settable by the customer, to indicate whether the Payment Reference is part of the customer information.
If the customer sets the yes/no field for a particular payee to ‘Yes, Require confirmation’, then the payment reference can only be changed under SCA.
But if the customer sets the field for a particular payee to ‘No, Does not require Confirmation’, then the customer can make payment to the pre-authorised payee (who was originally authorised under SCA) with a different payment reference without SCA.
If the above is not specified in the RTS, then banks will go their own way, and there will be huge dissatisfaction or insecurity. This really needs to be specified in the RTS.
All a malicious actor would have to do, is ensure that a low value payment to themselves is included within the batch of payments.
Their presence is the batch would be genuinely authenticated by SCA.
They could then change without detection the apportionment of the batch, so they received nearly all the payment, and the others hardly anything.
Batch payment security needs to link each amount with each payee.
Our experience is that whilst many customers are comfortable with SCA, even more are not.
Customer will use SCA to make a payment (under protest), but forcing customers once a month to use SCA just to access their account just to obtain access to information is going to cause a huge level of resentment, and is not reasonable for read-only access. Many customers will not accept this step, and this will cause huge resentment against the EU by ordinary people.
At this level, smurfing (many small payments) fraudulently sent could go on for some time leading to significant loss, and bank systems would have no way to detect or identify such loss.
The €10 limit must be lowered to €1 at most, if not lower.
Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.
IMPORTANT: We have significant experience in this area.There are two types of pre- authenticated Payee that banks store on their online systems for their customers.
The first is a friend, or family member, a supplier, or other general contact. For such payees, the payment reference is irrelevant and purely information giving and will change each time a payment is made.
So a payment reference might be ‘Birthday Present’ or ‘Invoice 47584’ etc.
Customers must not be made to have to provide SCA (secure customer authentication) to change the payment reference for these payees.
Whilst the majority of banks do not currently require SCA to change a payment reference, a minority do. These banks cause customer mayhem when the customer wishes to make payment to a pre-authorised payee but with a different payment reference.
The amount of work for the customer to perform to achieve SCA, just to change the payment reference which makes no difference and is purely informational, leads to intense customer dissatisfaction and is not reasonable.
On the other hand, when making payment to, say, a credit card company or a tax authority, the payment reference is all important as it uniquely identifies the account of the payer, and is really part of the payee information, since changing the payment reference will mean that the payment made is allocated by the payee to someone else.
For the majority of banks who do not require SCA to amend a payment reference, this is not suitable security.
The draft RTS mentions Payee details, but does not seem to understand that for the majority of payees their payee details consist only of the IBAN, whereas for a minority of payees the payee details consist of both the IBAN and the Payment Reference. (Article 2(2) and Article 8(2)).
Banks themselves do not understand this, and the result is either mass–customer dissatisfaction, or lack of security.
The resolution is simple – each payee should have a yes/no field added as well as the IBAN field, settable by the customer, to indicate whether the Payment Reference is part of the customer information.
If the customer sets the yes/no field for a particular payee to ‘Yes, Require confirmation’, then the payment reference can only be changed under SCA.
But if the customer sets the field for a particular payee to ‘No, Does not require Confirmation’, then the customer can make payment to the pre-authorised payee (who was originally authorised under SCA) with a different payment reference without SCA.
If the above is not specified in the RTS, then banks will go their own way, and there will be huge dissatisfaction or insecurity. This really needs to be specified in the RTS.
Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?
The batched payment solution proposed is flawed.All a malicious actor would have to do, is ensure that a low value payment to themselves is included within the batch of payments.
Their presence is the batch would be genuinely authenticated by SCA.
They could then change without detection the apportionment of the batch, so they received nearly all the payment, and the others hardly anything.
Batch payment security needs to link each amount with each payee.
Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?
Making customers perform SCA (strong customer authentication) to have non-payment-making access to their account (as set out in Article 8(1)) will lead to mayhem.Our experience is that whilst many customers are comfortable with SCA, even more are not.
Customer will use SCA to make a payment (under protest), but forcing customers once a month to use SCA just to access their account just to obtain access to information is going to cause a huge level of resentment, and is not reasonable for read-only access. Many customers will not accept this step, and this will cause huge resentment against the EU by ordinary people.
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
Setting a level of €10 for payments (as per Article 8(2)(d) ) not requiring SCA is much too high.At this level, smurfing (many small payments) fraudulently sent could go on for some time leading to significant loss, and bank systems would have no way to detect or identify such loss.
The €10 limit must be lowered to €1 at most, if not lower.