Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
The resultant provisions on prevention, detection, blocking fraudulent payment transaction shall defined the addresses (ASPSP, PISP, AISP, TPP,…). (1.3.e)
We believe that time out requirements may not be possible with card payments (1.3.a).
We recommend that SCA shall be waived with financial inclusion due to technology or ability to use new technologies.
Risk Base Approach is first very appealing taking the low risk people to have easier payment experience, however it implies enormous collection of data and limit to authentication for card and does not allow other services that could be provided by SCA. We therefore support the reasoning for SCA
The RTS does not explicitly define what identifies the payee (PSD 2 definition: (9) ‘payee’ means a natural or legal person who is the intended recipient of funds which have been the subject of a payment transaction;). The understanding for Credit transfer is using the amount and IBAN bank account. What about card, P2P payments using phone number as alias of a card, wallets, wearables,…?
Article 2.2.b imposes independent or segregated display of the authentication code from the original channel, device or mobile application use for initiating the electronic payment transaction. We can hardly understand how SCA applies on a mobile device with independent or segregated display without ruining the customer payment experience if separate devices are required
Finally strict and strong requirements on inherence may not be suitable as it will be almost impossible to comply with them (5.2) and could jeopardize the development of biometric verification methods.
Hard limits such as cumulative contactless amounts may create issues in case a POI does not support PIN entry (eg public transport) (2. 1.b.ii)
• High value and same day value credit transfer are often initiated using Swift formats. Other swift format are also used (documentary credit, …) for the clearing and settlement of electronic transactions (Money market, FX transactions,...)
• Bank statements and reporting using either MT9xx or domestic format instead of CAMT ISO 20022 messages.
• For card acceptance, the usage of technical specification is just at the beginning and we foresee no large usage without an end date and a long migration period. A common implementation guideline (rulebook) with scheme rules for their governance would be required. For card acquisition and clearing and settlement there is currently no finalised standard (ATICA)
We would recommend 3 times a day.
reasoning:
Last clearing and settlement happens after the End of the say. retailer will first collect their cash position end of day , early in the next morning. A second request may happen mid of the day and the last one at cut off time.(between 15h00 and 17h00)
Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
It is important to clarify that verification factors for SCA (Strong Customer Authentication) rely on ASPSP, PISP, AISP, TPP or Issuer and issuer agents but not on retailer. Therefore, Retailer shall not verify the SCA two factors authentications but ensure that they are transmitted to the authenticator. For example if signature is used as CVM on a mobile, it shall be verified by the PISP, ASPSP and not by the retailer. This means that manual Signature as CVM for physical contact and contactless card shall not be considered as suitable strong authentication factor..The resultant provisions on prevention, detection, blocking fraudulent payment transaction shall defined the addresses (ASPSP, PISP, AISP, TPP,…). (1.3.e)
We believe that time out requirements may not be possible with card payments (1.3.a).
We recommend that SCA shall be waived with financial inclusion due to technology or ability to use new technologies.
Risk Base Approach is first very appealing taking the low risk people to have easier payment experience, however it implies enormous collection of data and limit to authentication for card and does not allow other services that could be provided by SCA. We therefore support the reasoning for SCA
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.
We agree with EBA’s reasoning that the requirement should remain neutral as to when the dynamic linking should take place.The RTS does not explicitly define what identifies the payee (PSD 2 definition: (9) ‘payee’ means a natural or legal person who is the intended recipient of funds which have been the subject of a payment transaction;). The understanding for Credit transfer is using the amount and IBAN bank account. What about card, P2P payments using phone number as alias of a card, wallets, wearables,…?
Article 2.2.b imposes independent or segregated display of the authentication code from the original channel, device or mobile application use for initiating the electronic payment transaction. We can hardly understand how SCA applies on a mobile device with independent or segregated display without ruining the customer payment experience if separate devices are required
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?
This definition does not allow card PIN complying the requirements nor allow specific solution for person with disabilities, which for some of them may not cope with such complexity (3.1 knowledge). Specific waivers for persons with disabilities may be suitable (ERPB may launch a working group on payment for persons with disability).Finally strict and strong requirements on inherence may not be suitable as it will be almost impossible to comply with them (5.2) and could jeopardize the development of biometric verification methods.
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?
yesQuestion 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?
Beside maximal amount limits for contactless electronic payment (50 €) and remote payment (10€), risk parameters shall be aligned ensuring a level playing field. eg. risk in UK some scheme have different contactless floor limits. Some countries have implemented offline or online contactless card which creates different user experiences and risks.Hard limits such as cumulative contactless amounts may create issues in case a POI does not support PIN entry (eg public transport) (2. 1.b.ii)
Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?
yesQuestion 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?
we agree with the reasoning, however card transaction may not be able to cope with the bilateral identification nor to the traceability like the logging of all relevant transactionsQuestion 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?
IKEA support the usage of ISO 20022 business modelling. The usage for credit transfer, direct debit electronic payment is largely used and accepted. There are still 3 areas where specifications using ISO 20022 specification are not commonly used:• High value and same day value credit transfer are often initiated using Swift formats. Other swift format are also used (documentary credit, …) for the clearing and settlement of electronic transactions (Money market, FX transactions,...)
• Bank statements and reporting using either MT9xx or domestic format instead of CAMT ISO 20022 messages.
• For card acceptance, the usage of technical specification is just at the beginning and we foresee no large usage without an end date and a long migration period. A common implementation guideline (rulebook) with scheme rules for their governance would be required. For card acquisition and clearing and settlement there is currently no finalised standard (ATICA)
Question 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?
We have no preference between the two optionsQuestion 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.
This number may be linked to the number of daily clearing and settlement of ACH and CardWe would recommend 3 times a day.
reasoning:
Last clearing and settlement happens after the End of the say. retailer will first collect their cash position end of day , early in the next morning. A second request may happen mid of the day and the last one at cut off time.(between 15h00 and 17h00)