The responded to the different questions in the consultation paper* bearing a number of general principles in mind.
To allow evolving market solutions and innovation, the is of the opinion that the should be robust, but technology neutral. This means that they should be, as much as is possible, principle-based, and not define specific technical standards or include exhaustive lists of examples.
The must be open for all business, technical, legal and operational models and must facilitate the creation of an environment that is fair, with clear delineation of risk and liability.
Strong customer authentication ( ) and the interoperability specifications for communications should be based on internationally recognised and open standards. The various scenarios created by mean that Payment Service Users ( ) need to grant authorisation to third parties in order to access their information, or to act on their behalf. It is, therefore, fundamental that the do not impose restrictions on the ability of European Payment Service Providers ( ) to develop homogeneous services at a European or even global level.
Strong customer authentication
The proposed changes and requested clarifications on some issues. These were mainly related to card-based transactions, while also catering for sufficient flexibility with respect to adapting the measures to a changing fraud and technology landscape.
In particular, it commented on Art.1.1 which does not seem to include non-chip card transactions, such as those that are magnetic stripe based. As these cards are still in use in Europe, carried mainly by customers coming from outside Europe, the should take this fact into account.
The supports the dynamic linking of the authentication code to the specific transaction amount and the specific payee agreed to by the payer when initiating the transaction, and the flexibility offered on how and where the dynamic linking is done for electronic remote transactions in Art. 2 of the draft in support of Art 97.2 of . However, it sought clarification on what is meant by independence and segregation of the channel, mobile application, or device where the information about the amount and the payee are displayed, and the channel, application, or device used for initiating the payment. The understands that a logical separation would meet the requirements as stated in this Article. In addition, the provided examples of other techniques (such as secure element, application-separation, sandboxing, white box cryptography, device binding, etc) beyond the ones mentioned in the Rationale 26. These are available to create an adequately secure and protected environment to display the amount and the account number of the payee, whilst assuring the integrity towards the , on a single smartphone with a single online banking application.
Moreover, the requested a more clear definition and a distinction between authentication codes derived from the personalised security credentials to identify a given , and the authentication code dynamically linked to a transaction.
The further understands from Art. 8.1 and Rationale 19.b that all payees will have to apply from October 2018 at the earliest. However, the fails to perceive the legal basis for the to state that Art. 74.2 of the would only apply during a transitional period. On the contrary, Art. 74.2 clearly allows (and payees) not to require , provided any “financial damage” is refunded to the payer unless the payer, has acted fraudulently. This liability shift has been applied for more than 25 years for chip card transactions based on the EMV standard and has allowed merchants to adopt their own – quite effective - risk management processes.
Exemptions from strong customer authentication
The regrets that the draft do not propose exemptions based on a transaction-risk analysis performed by the . This is contrary to the risk-based approach of all recent security and supervisory rules. Moreover, it appears to go against the wording of . Art. 98.3(a): exemptions based on “the level of risk involved in the service provided”. The has proposed a number of criteria that could be considered for the specification of a transaction-risk based parameter.
Moreover, the exemptions criteria should not be an exhaustive list, so as to leave the concerned the ability to apply exemptions based on its own transaction risk analysis. A limited list of possible exemptions or criteria to be considered by for the transaction risk analysis may not be future proof and could omit future innovations that are to be expected in this dynamic and changing environment.
The further raised concerns with respect to the exemptions related to contactless electronic payments. The does not understand why the same exemptions do not apply for contact electronic payments.
Moreover, from a consumer friendliness perspective, it would be advisable that the limits for the transaction amount, or cumulative amount for the transactions not requiring , would be the same for all exemptions. Currently different values are applied for contactless electronic payments versus remote electronic transactions which, moreover, are not aligned with Art.42 of defining low-value payments.
Finally, the is of the opinion that the exemptions must remain optional for the Account Servicing Payment Service Providers ( ). Mandating the exemptions would be beyond the mandate given by . Furthermore, mandating the exemptions would not be technology neutral and would not provide flexibility to the (which are liable) in case of suspected payment fraud or other abuses (Art. 97.1(c) of ).
Protection of personalised security credentials
The welcomes the interpretation provided by the in the background section of its consultation paper. It provides a sensible way for to ensure their responsibilities, namely by either keeping full competence over self-issued authentication procedures; or by entering into a contractual agreement with a third-party, should the ASPSP-issued authentication procedures be substituted by personalised security credentials issued by Payment Initiation Service Providers ( ). The also interprets, that as a consequence of the above, the PISP or the Account Information Service Provider (AISP) is not allowed to store the credentials issued by an ASPSP without a contract, since the use of these credentials must be secured with a credential mechanism issued by the PISP / AISP. However, the does not find this adequately reflected in the draft themselves.
Common and secure open standards of communication
The requested clarification on the usage of the term “secure bilateral communication”. Indeed, if Art 17.1 required secure bilateral identification when communicating between the payer’s device and the payee’s acceptance device this would create incompatibility with EMV card based payments where there is no terminal authentication required.
Concerning the use of ISO 20022 elements, components, or approved message definitions to ensure the interoperability of different technological communication solutions implemented between for the provision of , or for the confirmation on the availability of funds, the responded that the should remain agnostic vis-à-vis any particular standard to ensure that they remain future proof.
The further commented that qualified certificates assure the quality of identification by the Certification Authority for the issuing of such a certificate. However they do not assure the quality of the technology used to keep the associated private key credentials used for authentication (proof of identity) under sole usage control by its respective owner (a ). In order to ensure sole usage control by the respective , the proposes specifying the adequate protection (e.g. crypto smart cards, USB dongles, hardware security modules) for the associated private key credentials, preferably referring to international standards. Based on such an enhanced specification, qualified certificates and associated private key credentials are a common and standard solution for authentication in automated server-server communications. The agrees that a Qualified Trust Service Provider (QTSP) could provide the certificates to be used for the identification between , and for website authentication, subject to sufficient availability of the appropriate certification authorities on the market. However, in the case of software components installed on any common type of device (e.g., tablet, mobile phone), owned by the payer, there is no way to enforce sole usage control over private key credentials by the owning . This renders the certificate based approach completely unsuitable for authentication in such a scenario since there is no mitigation against impersonation attacks.
With regard to the frequency with which AISPs can request information from designated payment accounts when the is not actively requesting such information, the welcomes the attempt to safeguard the availability of the ASPSP communication by limiting the frequency to no more than two times a day as specified in Art.22.5.(b) but noted that sometimes it is difficult to distinguish between a real user and a robot. Moreover it advised the to also take into account that problems with the communication interface are related not only to the number of times the AISP requests information regarding the customer, but also the amount of information/data that could be processed in a single request and the number of requests in a certain time window (possibly from different AISPs).
*The Consultation Paper requested input from the payment community by 12 October 2016 on the draft through responses to specific questions on the following four topics: “strong customer authentication”, “exemptions from strong customer authentication”, “protection of the confidentiality and integrity of the payment service users personalised security credentials” and “common and secure open standards of communication”.
If you would like to comment on this article, please identify yourself with your first and last name. Your name will appear next to your comment. Email addresses will not be published. Please note that by accessing or contributing to the discussion you agree to abide by the EPC website conditions of use.