EPCA PAYMENT SUMMIT Arno Voerman (Van Doorne N.V.) Edwin Jacobs (Time.Lex)

Transcription

1 EPCA PAYMENT SUMMIT 2015 Arno Voerman (Van Doorne N.V.) Edwin Jacobs (Time.Lex)

2 Topics Legal perspective on: Strong customer authentication (regulatory and civil law) Verification of (digital) identity Background: PSD 2 ECB Recommendations and EBA Guidelines security internet payments eidas AMLD4 General Data Protection Regulation

3 Article 87 PSD2 (presidency compromise text 1 December 2014) Authentication 1. Member States shall ensure that a PSP applies strong customer authentication when the payer: (a) (b) (c) accesses his payment account on-line; initiates an electronic remote payment transaction; carries out any action, through a remote channel, which may imply a risk of payment fraud or other abuses. 1.a In the case of paragraph 1 (b), Member States shall ensure that PSPs apply SCA that shall include elements dynamically linking the transaction to a specific amount and a specific payee. QUESTION: Always full liability of PSP in case of an disputed payment transaction if PSP did not apply SCA? Or is PSP nevertheless allowed to deliver proof that transaction was authenticated?

4 Article 57 PSD2 Consent and withdrawal of consent 1. Member States shall ensure that a payment transaction is considered to be authorised only if the payer has given consent to execute the payment transaction. ( ) 2. Consent to execute a payment transaction or a series of payment transactions shall be given in the form agreed between the payer and the PSP. Consent to execute a payment transaction may also be given via the payee or the PISP. In the absence of consent, a payment transaction shall be considered to be unauthorised. 3. ( ) 4. The procedure for giving consent shall be agreed between the payer and the relevant PSP.

5 Article 64 PSD2 Evidence on authentication and execution of payment transactions 1. Member States shall require that, where a payment service user denies having authorised an executed payment transaction ( ), it is for the PSP to prove that the payment transaction was authenticated, ( ). If the payment service user initiates the payment transaction through a PISP, the burden shall be on the latter to prove that within its sphere of competence, the payment transaction was authenticated, ( ). 2. Where a payment service user denies having authorised an executed payment transaction, the use of a payment instrument recorded by the ASPSP shall in itself not necessarily be sufficient to prove either that the payment transaction was authorised by the payer or that the payer acted fraudulently or failed with intent or gross negligence to fulfil one or more of the obligations under Article 61.

6 Article 65 PSD2 Payment service provider's liability for unauthorised payment transactions 1. Member States shall ensure that, ( ), in the case of an unauthorised payment transaction, the payer's PSP refunds to the payer immediately the amount of the unauthorised payment transaction and, ( ). 2. [ ] Where the payment transaction is initiated through a PISP, the ASPSP shall refund immediately the amount of the unauthorised payment transaction and, ( ) If the PISP is liable for the unauthorised payment transaction, it shall immediately compensate the ASPSP ( ). In accordance with Article 64, paragraph 1, the burden shall be on the PISP to prove that, within its sphere of competence, the payment transaction was authenticated ( ).

7 Article 82 PSD2 Right of recourse 1. Where the liability of a PSP under Articles 65 and 80 is attributable to another PSP or to an intermediary, that PSP or intermediary shall compensate the first PSP for any losses incurred or sums paid under Articles 65 and 80. This shall include compensation where any of the PSPs fail to use SCA. 2. Further financial compensation may be determined in accordance with agreements between PSPs and/or intermediaries and the law applicable to the agreement concluded between them.

8 Article 66 PSD2 Payer's liability for unauthorised payment transactions b. [Maximum liability payer EUR 50, unless fraud] 1c. Where the payer's payment service provider does not require strong customer authentication, the payer shall only bear any financial consequences where having acted fraudulently. Should the payee or the PSP of the payee fail to accept SCA, they shall refund the financial damage caused to the payer s PSP. AGAIN: Does this prevent PSP from delivering proof that transaction was uthenticated? Or is 1c always applicable if a PSP did not require or accept SCA?

9 ECB Recommendations for the security of Internet Payments As a general principle, the initiation of internet payments as well as access to sensitive payment should be protected by SCA From the Forum's perspective, PSPs with no or only weak authentication procedures cannot, in the event of a disputed transaction, provide proof that the customer has authorised the transaction. All payment schemes should promote the implementation of SCA by introducing a liability regime for the participating PSPs in and across all European markets. The liability regime should provide that a PSP must refund other PSPs for any fraud resulting from weak customer authentication.

10 EBA Guidelines The core recommendation is that the initiation of internet payments as well as access to sensitive payment should be protected by SCA to ensure that it is a rightful user and not a fraudster, initiating a payment BUT no comments on the legal consequences if PSP fails to use SCA SO what is the legal situation as per 1 August 2015? ALSO scope of Guidelines? See article 2 PSD1.

11 1 August 2015 PSD1 implemented in national law (no reference to SCA) Consent to payment transaction is civil (contract) law matter ECB Recommendations do not change this BUT regulatory impact?

12 Regulatory status ECB Recommendations and EBA Guidelines? ECB Recommendations: o not directly applicable to PSPs and payment schemes o enforcement via national supervisory and oversight authorities EBA Guidelines: o addressed to (i) banks and (ii) national competent authorities o must make every effort to comply o for banks direct application o national authorities may opt for non-compliance o banks also? (see next slide) o for other PSPs indirect application via national authorities REGULATORY IMPACT for other PSPs than banks thus mainly depends on position individual national authorities

13 Comply or explain? ECB Recommendations: o Comply or explain for all addressees EBA Guidelines: o o Comply or explain only for competent authorities: EBA Feedback: Article 16 of Regulation (EU) No 1093/2010 provides a comply or explain mechanism for competent authorities. Competent authorities in the 28 Member States of the European Union should ensure the application of these guidelines by PSPs as defined in Article 1 of the PSD under their supervision. All addresses shall make every effort to comply with the guidelines. In addition, competent authorities may require PSPs to report that they are complying with the guidelines. All addresses shall make every effort to comply with the guidelines.

14 Strong Customer Authentication Guideline 7: should be protected by SCA PSPs should have a SCA procedure CT/e-mandate/e-money: PSPs should perform SCA Cards: PSPs offering acquiring services: - should support technologies allowing the issuer - should require their e-merchant to support solutions allowing the issuer Providers of wallet solutions should require SA by the issuer when the legitimate holder first registers the card data QUESTION: SCA for cards mandatory from regulatory perspective? Or does it remain a (civil) liability issue?

15 Authentication - definitions EBA: PSD2: a procedure that allows the PSP to verify a customer's identity Commission: Council: EP: a procedure which allows the payment service provider to verify the identity of a user of a specific payment instrument including the use of its personalised security features or the checking of personalised identity documents. procedures which allow the payment service provider to verify the identity of a payment service user or the validity of the use of a specific payment instrument. procedures which allow the payment service provider to verify the validity of the use of a specific payment instrument.

16 EBA: Authentication = verification of identity Three questions: What forms the identity? What is digital identity? How to verify identity?

17 Digital identity Who are you? = identification How can you prove it? = identity credentials & authentication of identity by relying party What can you do / access? = authentication in context / for which purpose? (federated) identity systems/ management for online transactions - payments media e-government e-health eidas AML PSD2 EBA guidelines Data Privacy

18 EU eidas Regulation - Focus on id sys credentials for public sector goal = cross border public sector mutual recognition notification to Eur. Comm. - Two important remarks: - Not necessarily governed operated - May be private sector owned/operated ID provider technical standards assurance levels : low, substantial, high - Closed user groups - Challenge? - Develop rules/rule book trust - Technical, operational, legal (liability shift) - Law - Contracts scheme

19 eidas - Liability : - For M.S. - For ID credentials issuers/ authentication procedures - From a consumer (payer PSD) point of view : - Fraud - Unauthorised transaction

20 Contact Arno Voerman Counsel t +31 (0) Voerman@vandoorne.com Edwin Jacobs Partner Congresstraat 35 Rue du Congres B-1000 Brussels (t) +32 (0) edwin.jacobs@timelex.eu Van Doorne N.V. Amsterdam