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
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
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.
yes
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)
yes
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 transactions
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)
We have no preference between the two options
This number may be linked to the number of daily clearing and settlement of ACH and Card
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)