A view from EU and out of EU E-Payment & SEPA Adviser PSD2 - Banks and TPP A view from EU and out of EU 2017.06.05 Ugo Bechis E-Payment & SEPA Adviser Meeting © 2010 Colt Telecom Group Limited. All rights reserved.

PSD2 - Banks and TPPs The e-Commerce and payments ecosystem Customer ownership and Regulation PSD2 and RTS - Highlights PSD2 impacts on customer relationship PSD2 - a view from out of the EU Ugo Bechis

Customer ownership : the access gateway Online Bank Seller Buyer Online platform App Pay app PSP Pay platform Various SPs Pay app Ugo Bechis

The (e-)Commerce hybridization: in-store + in-app . Ugo Bechis © 2010 Colt Telecom Group Limited. All rights reserved.

Payments fit within an ecosystem Ugo Bechis

No-friction purchase process : intuitive , easy , quick The goal of e-Commerce players : to sell (2016 vs 2015) No-friction purchase process : intuitive , easy , quick Conversion rate: 59% (ex 62%) (paying buyers vs e-cart check-out) Types of paym accepted: 6 (avg no. of payment instruments) Checkout time: 143” (ex 134”) (avg seconds from cart checkout to paym) “click” time: 8.5” (ex 2014 : 12”) (avg seconds from one click to next one) every - 10” lower checkout time = + 2% conversion rate > sales Ugo Bechis source : 2016.12.16_Checkout Conversion Index_December_2016_v07_Pymnts © 2010 Colt Telecom Group Limited. All rights reserved.

Key factors for customer ownership & use of payments Customer identification at the entry point Info: beavioral, financial, loyalty schemes, commercial Choice of instrument at entry point/wallet > Use of the chosen payment instrument © 2010 Colt Telecom Group Limited. All rights reserved. Ugo Bechis

Customer ownership : Key steps - EU Regulation Work flow steps & roles EU Regulatory Acts Entry step device authentication ECB-EBA e-Payment Security ( PC , Tablet , Phone / Mobile HW , card ) PSD.2 / e-IDAS Wallet “owner” (Phisical/Mobile/Cloud) PSD.2 / ECB-EBA e-Paym Security ID+access Credentials to Wallet/Instruments e-IDAS / PSD.2 / Data Protection ( e-ID + biometric > Token > two factor credentials) Payment acceptance authentication PSD.2 RTS / e-Payment Security Account holder / payment data intelligence PSD.2 / Data Protection Reg. Ugo Bechis © 2010 Colt Telecom Group Limited. All rights reserved.

The PSD.2 TPPs : Key points & impacts - highlights TPP - Third Party Payment Service providers : 3 categories PISP - Payment Initiation Service Providers : initiating a payment with an instrument at another PSP account, without handling the funds whether or not there is any contractual arrangement between PSP and payer’s ASP AISP - Account Information Service Providers : if customer’s consent to AISP, provide & consolidate payment account(s) transactions info, whether or not a contractual arrangement between AISP and the user’s ASPSP (the Bank). Issuing of Payment Instruments (new definition) : “to provide payment instruments to initiate and process payer’s payment transactions”. A broader concept of “payment instrument”, eg a service (wallet) with two/more payment brands / applications on the same payment instrument (ref to “co-badging”) Impacts - highlights Banks “must grant TPPs access in a unhindered and efficient manner to payment account information on an objective, non-discriminatory, proportionate basis” “a checkout service where payment options are offered is a payment instrument issuer”. (as opposed to the issuer of each of the available payment methods) Ugo Bechis

EBA Authority PSD2 - RTS (2017.03.23 *) The RTS - Regulatory Technical Standards on SCA and CSC Customer identification TPPs (AISP, PISP, Issuer PSP) to initiate each transaction with SCA (Strong Customer Authentication) provided by the ASPSP to the user SCA: authentication code, containing elements provided by the user to indicate consent for specific activity General exemptions from SCA Risk /fraud levels monitored via Transaction risk analysis (TRA) Exemptions based on amount, recurrence, channel: Payee in beneficiaries trusted list confirmed by payer to ASPSP C-Less payments <50€ ; Low-value remote <30€ Unattended terminals payment - transport/ parking Security and Confidentiality PSPs security measures; audit of systems ▪ Website authentication, identification between PSPs with eIDAS qualified certificates for electronic seals (Article 3(30), 3(39) of Regulation (EU) No 910/2014) Open interfaces, standards ASPSP interface: TPPs access to info on trx, accounts with same level of service as on-line banking Interface doc on ASPSP website free for authorized TPPs. (ISO 20022 specs, data, routines, protocols) Max access 4 times/day without contrac agreements Ugo Bechis (*) 2017.02.23 RTS, to be submitted to EC for adoption and scrutiny by the EP and the Council © 2010 Colt Telecom Group Limited. All rights reserved.

PSD.2 RTS - highlights Banks to define their interfaces via APIs documented, available on websites (ASPSP shall offer at least one communication interface for secure communication with AISPs, PISPs, and PSPs issuing card , which shall be documented and freely available on the ASPSP’s website. ASPSPs shall ensure that their communication interface uses common and open standards which are developed by International or European standardisation organisations. Banks must provide AIS TPP accounts, trx info ; not sensitive data (personal) Payment security & authentication up to the Payment Instrument Issuer on basis of prior contract customer-ASPSP (Bank), also when initiation via TPP (*) eIDAS security (PKI - ETSI) for ASPSPs-AISPs-PISPs mutual authentication Card Acquiring PSP to support strong authentication for all transactions Prevention, detection, real-time block of fraud trx before authorisation Ugo Bechis * to be verified in the National laws for PSD2 adoption and with the final RTS to be published

PSD.2 RTS: TPP-ASPSP data exchanges - Art. 22 - excerpts (*) 1) Account servicing payment service providers (ASPSP, ie Banks) shall provide to: (a)  AISP : same information from designated payment accounts, associated payments available to the user when directly accessing the info online (not sensitive payment data); (b)  PISP : same information on initiation and execution of transaction available to the payment service user when directly initiating the payment transaction, (c)  PSP issuing card instruments : a confirmation of availability of amount for execution of card trx on payer’s account. This confirmation shall be a simple ‘yes’ or ‘no’ 3) AISP shall have mechanism to limit request of information to both designated payment accounts and associated payment transactions, in accordance with the user’s explicit consent; 4) PISP shall provide ASPSP the same info when user directly initiating the payment 5) AISP shall request info from designated payment accounts and associated payment transactions: (a) any time the payment service user is requesting such information, (b) or, where the user is not actively requesting such information, no more than 4 times a day. Ugo Bechis * to be verified in the National laws for PSD2 adoption and with the final RTS to be published

PSD.2 RTS on SCA and SCS: Comunication interfaces - highlights Art. 27 - Communication interface ASPSPs to define their open interfaces (e.g. open APIs) with PSPs via documented APIs freely available to licensed PSPSs on ASPSP’s websites. ASPSPs (i.e. Banks) shall: offer at least one interface for secure communication with AISPs, PISPs, and PSPs issuer ensure that communication interface uses common and open standards developed according to International or EU standardisation organisations (ISO 2022, W3C, other) Authentication of the user of the payment instrument is up to the ASPSP issuing the instrument on basis of prior contract customer-ASPSP, also when via TPP Art. 29 - Certificates eIDAS Certificates, Electronic seals are required for ASPSPs-to-AISPs/PISPs/Issuer PSPs mutual website authentication (re PKI in ETSI standards) and secure communication Ugo Bechis (*) to be submitted to EU Commission for adoption and scrutiny by the EP and the Council © 2010 Colt Telecom Group Limited. All rights reserved.

Open API.s case - CheBanca! What is an API? Application Programming Interface (API) is a set of programming instructions & standards to access a web-based sw application/tool (request/response http standard) An API is a software-to-software interface, not a user interface. With APIs, applications talk to each other without user knowledge or intervention. Customer Bank t1 https://api.chebanca.it/private/customers/71524/products/0001489520/balance/retrieve To Bank … "availableBalance": { "amount": "315.920", "currency": "EUR” } , "date": "08/10/2016", "hour": "18:39", "isPocketAccount": false}, From Bank t2 Time CheBanca! 20.10.2016

PSD.2 RTS - SCA : EP ECON Briefing - clarifications p.8, § 6) Third-country payment instruments “When third-country payment instruments used in EU for cross-border transactions, the EU PSP shall make every effort to avoid fraud, but not necessarily applying SCA if not possible. Cross-border trx are not taken into account for fraud rates, re new Art. 16 RTS. Article 16 - Exemptions “Some services would no longer qualify (e.g. Amazon 1-Click, single authentication) unless they are exempted (Art. 10-18), i.e. : amount, recurrence of beneficiary, TRA TRA exemption fraud rates are for payments between EUR 100 to 500” Fraud rates assessed by qualified independent auditors, reported to national Authorities AISPs require SCA, single-use code, at each login where sensitive payment data disclosed” Art. 4 - Standards “reference to ISO 20022, as in PSD2, for standardised messages formats between PSPs” Ugo Bechis (*) discussed at the European Parliament ECON meeting - 27.03.2017 © 2010 Colt Telecom Group Limited. All rights reserved.

New EU Regulations : impacts on customer relationship PSD2 e-IDAS requirements in the TPP-to-AIPSP domain identify ‘who’ is the gateway accessing on behalf of users 2) PSD2 RTS : SCA + ’instrument definition’ allow choice of instrument at the TPP ‘wallet’ step > > 3) PSD.2: mandatory open access to Banks shifts the point of customer capture to the TPP step > PSD2 RTS: Info availability is key for the ‘value’ of entry point © 2010 Colt Telecom Group Limited. All rights reserved. Ugo Bechis

Russian Federation - Law 161 vs EU Regulations Russian Federal Law 161-FZ EU Bodies - Regulatory Acts EP - European Parliament PSD.2 Art. 61 to 66 Art. 74 , 85 e-ID & Trust Services Reg. Art. 3 , 25 ,26 , 29 , 30 , 32 , 35 , 41 ECB - European Central Bank Security of Internet Payments Rules 1 to 11 EBA PSD2 RTS Art. 5 - Procedures for transferring funds Art. 6 - Specifics for funds transfer Art.7 - Specifics executing e-Money transfer Art. 8 - Client’s instruction , procedures for acceptance , execution Art. 9 - Procedures for use of electronic means of payment Art. 26 - Ensuring Banking Confidentiality in a Payment System Art. 27 - Ensuring Data Security Art. 28 - Risk Management Art. 29 - Securing Execution of Payment System Participants’ Obligations Ugo Bechis Ugo Bechis © 2010 Colt Telecom Group Limited. All rights reserved.

A view from a non-EU , a Russian perspective The access player within or out-of-EU “owns” the customer A Bank can be a ‘digital agent’ (‘TPP’) vs other banks The big (non-EU) web players have a choice whether to operate within the EU PSD2 framework or out-of EU jurisdiction Usability of the customer interface, info availability, choice of payment instruments are key (i.e. 60 seconds) Russian payment processing rules are safeguarded Cross-jurisdiction Data Protection on non-transaction behavioral data is the open issue Ugo Bechis © 2010 Colt Telecom Group Limited. All rights reserved.

e-Payments & SEPA Advisor Ugo Bechis e-Payments & SEPA Advisor ugo.bechis@gmail.com Ugo Bechis