The European Commission's final RTS: some issues remain unclear

The European Commission's final RTS: some issues remain unclear

Interview with Scott McInnes, Partner at Bird & Bird LLP

06 December 17

Share This

The European Commission published the long awaited final Regulatory Technical Standards () on strong customer authentication () and common and secure open standards of communication, on 27 November 2017. These , initially drafted by the European Banking Authority (), are instrumental in the application of the revised Payment Services Directive ().

Among other things, they explain how third party payment service providers () can access customers’ payment accounts to facilitate their payments, and further describe the rules of . If you need a reminder of the objectives and vocabulary of , do not miss our infographic  deciphering this complex directive.

As a next step, the European Parliament and the European Council have three months to scrutinise the final , which will then be published in the Official Journal of the European Union. The are expected to become applicable around September 2019.

A lot of diverging opinions emerged during the creation of the , and uncertainties remain. To shed some light on the blur areas of the , we asked Scott McInnes from the law firm Bird & Bird LLP to outline the key aspects of the final and what may happen regarding the unclarities of the text.

The views expressed in this article are solely those of the author and should not be attributed to the European Payments Council.

Q. What are the main changes between the version of the on and common and secure open standards of communication published by the Commission in November 2017, and the final draft released by the in February 2017?

As regards the topics of getting access to payment accounts, one of the main changes introduced by the Commission is the fact that will still be able to use ‘screen scraping’ as a fallback option – which was not foreseen in the 's draft. Indeed, the Commission decided in favour of the following regime for access: 

  • Principle: if an Account Servicing Payment Service Provider (‘ASPSP’ – we refer to it as a ‘bank(s)’ in this article) makes a dedicated interface (aka an Application Programming Interface - ) available to , have to use it1.
     
  • Fallback/contingency mechanism: if the does not offer at all times the same level of availability and performance as the interfaces made available by the bank to the payment service user (), that there is unplanned unavailability of the and that there is a systems breakdown (presumed to have arisen when five consecutive requests are not replied to within 30 seconds), the can screen scrape (with a procedure for the bank to identify the – i.e. no impersonification).
     
  • Exemption: if the has been successfully tested and widely used by , the national regulator may exempt the bank from the fallback requirement (however this exemption may be revoked in case of technical issues arising with the if they remain unresolved for two consecutive weeks).

As regards the topic of , the main change is the addition of an exemption for "secure corporate payment processes and protocols" (Article 17 of the final ), which is available when (1) the payment is initiated by a legal person (i.e. not a consumer), (2) the payment goes though "dedicated payment processes or protocols", and (3) the national regulator is satisfied that those processes or protocols guarantee at least equivalent levels of security as . In addition, the Commission clarified that the requirements do not apply to anonymous payment instruments

Q. Do you still see some uncertainties and unclarities in the latest text of the as published by the European Commission in November?

Yes, there remain a lot of uncertainty/unclarity in the – both in relation to the topic of access to payments accounts as well as . As regards access, for example:

  • Some of the currently being built to give access to were based on a ‘redirect model’, i.e. the consumer first gives its explicit consent to the in the domain, then is redirected to the banking domain to perform , before being taken back to the 's domain. However, Article 32(3) of the states that "[Banks] that have put in place a dedicated interface shall ensure that this interface does not create obstacles to the provision of [] services. Such obstacles, may include, among others […] imposing redirection to the [bank]'s authentication or other functions […]". Does this mean that the redirecting model will be illegal under the ? Or should the use of the word ‘may’ (rather than ‘shall’) be interpreted as meaning that redirecting could be illegal in some circumstances, but legal in other circumstances – and that therefore a case-by-case assessment is needed?2 In addition, if the redirecting model is illegal, how should the take place: should the share his banking credentials with the , which seems to be permitted by 3?
     
  • Will national regulators really be in a position to perform the technical quality assessment of the in order to validate them and therefore exempt banks from the fallback requirement?
     

Also, isn't there a risk that different national regulators will apply different standards of review to validate the

As regards , a lot of questions remain open there too. Here are a few examples:

  • For contactless transactions and in particular the 150 euros or five transactions cumulative limits: if the consumer regularly taps his plastic card as well as his mobile phone in order to make contactless payments, should there be only one counter counting all the taps with the card and the phone – or should there be two separate counters?
     
  • How will the white-listing/trusted beneficiary exemption work in practice? For example, could a merchant suggest to a consumer who is about to purchase an item on its website to white-list it, and if the consumer agrees that merchant would work directly with the consumer's bank (perhaps via an ) in order to perform the white-listing? Can a merchant be white-listed in a face-to-face environment (e.g. my favourite supermarket, my favourite bakery, my favourite restaurant)? Could a consumer white-list his favourite e-wallet service provider and never again perform when paying via this service (which, if possible, would appear to be an extremely wide-ranging exemption…)? 
     
  • Low-value remote transactions: how can an acquirer track that the cumulative value of 100 euros or five remote transactions without is not reached if the previous merchants at which remote transactions have taken place are not served by that same acquirer? 
     
  • How will the Transaction Risk Analysis (TRA) exemption work? In particular could acquirers segregate their merchant in e.g. two groups, and have lower fraud rates for one group of merchants and give them the benefit of TRA up to the maximum possible transaction amount, whereas in relation to the other group of merchants the acquirer will have higher fraud rates and therefore those merchants will not benefit from the TRA exemption (or at least not up to the same transaction amount)? If so, could one or more such merchants groups be composed of only one merchant (de facto amounting to calculating the fraud levels at the level of the individual merchant, rather than at the level of the acquirer)4 ?
     
  • If an acquirer believes that it can benefit from an exemption and therefore requests the issuer to allow the transaction to go through without , but the issuer believes that the transaction should be subject to , what will happen? In the February 2017 version of the , the had indicated that the issuer should have "the final say"5: does this mean that the card issuer is allowed to deprive the acquirer (and ultimately the merchant) of an exemption that the acquirer (and ultimately the merchant) would like to benefit from? And if so, if the acquirer did not request the issuer to perform , apparently technically the issuer is not able to perform and therefore the issuer will have to decline the transaction, therefore forcing the acquirer to re-submit the transaction with a request for the issuer to perform ? What will be the impact of this ‘ping pong’ on the consumer's checkout process?

Q. will enter into force on 13 January 2018. However, the entry into force of the is foreseen around September 2019. They are instrumental in the implementation by all stakeholders. What are the regime applicable and the challenges during this transitory period?

All provisions of (including the requirement for banks to give access to payment accounts to ) become applicable in a given European Economic Area () country when the national law implementing becomes applicable – with essentially two exceptions:

  1. The provisions on will only become applicable when the will become applicable, i.e. approximately September 2019.
     
  2. The technical aspects of how banks should give access to payment accounts to will only become applicable when the will become applicable, i.e. approximately September 2019. Before that, banks should give access to , but without knowing exactly how to do so technically. Three periods should be distinguished in relation to the issue of access:
  • Between 13 January 2018 and when the national law implementing becoming applicable in a given country: can get access to payment accounts on an unregulated basis, i.e. like they were doing under PSD1.
     
  • Between the national law implementing becoming applicable and the becoming applicable (e.g. September 2019), i.e. ‘the transitional period’’ or ‘grey period’: arguably can get access to payments accounts by using screen scraping, even if the bank makes an available to . Indeed, during that grey period, since the is not yet applicable, there is no legal requirement forcing to use the made available by the bank (unless national law would anticipate the date of the becoming applicable, e.g. Hungary that intends to make the applicable in Hungary as from January 2019). This seems to be in particular the case in relation to that were already active before January 20166. Although a counter-argument could be made that a , by using screen scraping rather than the API made available by the bank, would be in breach of its legal obligations by having access to data/information that it should not legally have access to7. The is working on a document that will seek to clarify the situation during this grey period.
     
  • As from when the will be applicable (approx. September 2019): see the regime described under question 2 above.

1: If a bank decides not to provide an to , then can continue to access payments accounts through screen scraping. 

2: Some intelligence coming from the Commission seems to suggest that it is not the Commission's intention to impose an outright ban on an working on the basis of a re-direct, but that a case-by-case assessment is required to determine if the bank has put in place ‘obstacles’ for the . To be continued… 

3: Article 66(3)(b) states that "The [PISP] shall […] ensure that the personalised security credentials of the payment service user are […] transmitted by the [PISP] through safe and efficient channels". Article 67(2)(b) states that "The [AISP] shall […] ensure that […] when [the personalised security credentials] are transmitted by the [AISP], this is done through safe and efficient channels".

4: A letter sent by Commissioner Dombrovskis to the E-Commerce Europe on 25 October 2017 would seem to support the possibility for acquirer to separate their merchants in various groups: "From the contacts that the Commission had with the banking industry, it appeared that the acquiring banks would – certainly for major merchants – assess fraud risks for individual merchants rather than on a portfolio basis. This would allow merchants to continue to carry out transaction risk analysis". Should the fact that the Commissioner does not raise any issues with such practice be interpreted as consent that this practice is acceptable under the ?

5: Paragraph 24, page 10: "The concurs with the views expressed by these respondents and has made it clearer in the that both payees’ and payers’ could trigger such an exemption under their own and exclusive responsibility but with the payer’s having the final say".

6: Article 115(5) provides that "Member States shall not forbid legal persons that have performed in their territories, before 12 January 2016, activities of [PISP] and [AISP] within the meaning of this Directive, to continue to perform the same activities in their territories during the transitional period … in accordance with the currently applicable regulatory framework."

7: Through screen scraping, the PISP would be having access to "data other than those necessary to provide the []" (Article 66(3)(f)), and the AISP would potentially have access to information that is related to accounts that do not qualify as payment accounts (Article 67(2)(d)).

 



Your reactions

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.