Overview PSD2 1 - NOREA

NOREA\ Kennisgroep Betalingsverkeer\ Overview PSD2 1

NOREA\ Kennisgroep Betalingsverkeer\ Overview PSD2

2

Agenda

� What is meant by PSD2?� Why PSD2?� PSD2 in a picture� Timeframe of PSD2� Strong Customer Authentication

o exemptionso summarised

� Impact of PSD2: Open Banking� Application Programming Interface� PSD2 access to account (XS2A)� Open ends� Attention points for the auditor� Summary� Glossary� Disclaimer


3

What is meant by PSD2?

In 2015 the EU adopted a new directive on payment services (hereafter: PSD2) to improve the existing rules

and take new digital payment services into account. The directive became applicable in January 2018. It

includes provisions to:

� make it easier and safer to use internet payment services;

� better protect consumers against fraud, abuse, and payment problems;

� promote innovative mobile and internet payment services;

� strengthen consumer rights; and

� strengthen the role of the European Banking Authority (hereafter: EBA) to coordinate supervisory

authorities and draft technical standards.

The directive is part of a legislative package that also includes a regulation on multilateral interchange fees.

Together, the regulation and the second payment services directive limit the fees for transactions based on

consumer debit and credit cards, and ban retailers from imposing surcharges on customers for the use of

these types of cards.


4


In other words, the new rules will:

� prohibit surcharging, which are additional charges for payments with consumer credit or debit cards,

both in shops or online;

� open the EU payment market to companies offering payment services, based on them gaining access to

information about the payment account;

� introduce strict security requirements for electronic payments and for the protection of consumers'

financial data; and

� enhance consumers' rights in numerous areas. These include reducing the liability for non-authorised

payments and introducing an unconditional (‘no questions asked’) refund right for direct debits in Euro.


5


High level overview of PSD and PSD2 via Wikipedia: https://en.wikipedia.org/wiki/Payment_Services_Directive

More complicated summarised in text under the tab ‘Summary of legislation’:http://eur-lex.europa.eu/legal-content/EN/LSU/?uri=CELEX:32015L2366

with the actual text under the tab ‘Document information’:http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366

The PSD2 conferred on the European Banking Authority (hereafter: EBA) the development of twelve

technical standards Regulatory Technical Standard (hereafter: RTS) and guidelines (hereafter: GL) to specify

detailed provisions in relation to payments security, authorisation, passporting, supervision, and more.

The EBA issued an opinion on the transition from PSD1 to PSD2:https://www.eba.europa.eu/documents/10180/2067703/EBA+Opinion+on+the+transition+from+PSD1+to+PSD2+%28EBA-Op-2017-16%29.pdf


6



7

Why PSD2?


8

Introduction to PSD2 in a picture


9

Timeframe of PSD2

20151116 – The Council of the European Union passes PSD2, giving member states two years to incorporate

the directive into their national laws and regulations.

20160112 – Date of entry into force.

20171127 – The European Commission adopted rules that spell out how strong customer authentication

(SCA) is to be applied. Following the adoption of the Regulatory Technical Standards by the Commission, the

European Parliament and the Council have three months to scrutinise them. Subject to that period, the new

rules will be published in the Official Journal of the EU (a.k.a. OJEU). Banks and other payment services

providers will then have 18 months to put the security measures and communication tools in place. As

such, the working date is September 2019.

20180113 – Date that the rules apply. EU countries had to transpose Directive (EU) 2015/2366 into national

law. Directive 2007/64/EC is repealed and replaced by Directive (EU) 2015/2366

20190914 – enforcement of Strong Customer Authentication. This is the RTS on strong customer

authentication and common and secure communication (EBA-RTS-2017-03).


10

Timeframe of PSD2

Either because of a delay in adoption or because PSD2 intended it to be so, not all the provisions of PSD2 or

EBA technical standards and guidelines are applicable on 13 January 2018. This misalignment, whether

explicitly foreseen in PSD2 or a result of the delayed entry into force of EBA guidelines and technical

standards, has led to a situation in which only a few of the 12 mandates are applicable.

The PSD2 rules are applicable as of 13 January 2018 through provisions that member states (should) have

introduced in their national laws in compliance with the EU legislation.

Countries have not transposed PSD2 into local law yet. For an overview: https://ec.europa.eu/info/publications/payment-

services-directive-transposition-status_en

Situation for the Netherlands:

20180904 – discussed in Dutch parliament.

20180911 – voting by Dutch parliament.

20190101 – expected implementation.

In more detail: https://www.tweedekamer.nl/kamerstukken/wetsvoorstellen/detail?cfg=wetsvoorsteldetails&qry=wetsvoorstel%3A34813


11

Timeframe of PSD2


12

Strong Customer Authentication

Strong Customer Authentication is defined in Article 97 ‘Authentication’ of the Directive:


13


Strong Customer Authentication will apply to online payments within the EU.

The EU provided additional guidance re. authentication (use link).https://ec.europa.eu/transparency/regdoc/rep/3/2017/EN/C-2017-7782-F1-EN-MAIN-PART-1.PDF

The actual text of EBA’s RTS can be found via this link:https://www.eba.europa.eu/documents/10180/1761863/Final+draft+RTS+on+SCA+and+CSC+under+PSD2+%28EBA-RTS-2017-02%29.pdf

The RTS for Strong Customer Authentication (hereafter: SCA) is a key requirement for the implementation

of PSD2 as:

� it defines security requirements to ensure effective and secure communication between parties; and

� it is directly applicable to member states of the EU, i.e. it does not have to be transposed to national

legislation.


14



15


The RTS further defines:

� the authentication shall be based on two or more elements which are categorised as knowledge,

possession and inherence and shall result in the generation of a unique authentication code (*);

� dynamic linking;

� session length (less than 5 minutes of inactivity);

� error authentication management (message);

� secured channel;

� block mechanism (rules, warning and process to regain access);

� risk mitigation regarding authentication elements disclosure (technical mechanism); and

� independence of the elements.

(*) the authentication code generated is specific to the amount of the payment transaction to which the payee agreed

and any change to the amount and/or payee results in an invalid generated authentication code.


16


The RTS further defines:

� Payment service providers shall have transaction monitoring mechanisms in place that enable them to

detect unauthorised or fraudulent payment transactions:

� lists of compromised or stolen authentication elements;

� the amount of each payment transaction;

� known fraud scenarios in the provision of payment services;

� signs of malware infection in any sessions of the authentication procedure; and

� a log of the use of the access device.

� Review of the security measures through regular audits by a qualified auditor (article 3).


17

Strong Customer Authentication - exemptions

Exemptions to the SCA according to PSD2:

� consultation access for only the balance of payment account or list of transfers for the last 90 days, only

for 90 days « session » and not the first connection;

� contactless payment;

� parking fare payment;

� trusted beneficiaries;

� recurring transactions;

� transfer between accounts held by the same natural or legal person;

� low-value transaction (less than EUR 30);

� secure corporate payment with specific processes and protocols; and

� transaction risk analysis.

For questions and answers the EU has a dedicated SCA site: http://europa.eu/rapid/press-release_MEMO-17-4961_en.htm


18

Strong Customer Authentication – summarised

The crux: it requires payments to be authenticated using at least two of the following elements:

� something that only the customer should know, e.g. password, code, or PIN;

� something that only the customer has or possesses, e.g. a card, hardware token, or mobile phone; and

� something that the customer is, e.g. biometric (fingerprint, facial recognition, or iris scan).

As part of SCA, the customer’s bank will generate a single-use authentication code corresponding to the

amount of the payment and the business it is intended for.

Exceptions are applicable e.g. a corporate’s batch payment instruction or a customer’s standing direct debit.


19

Impact of PSD2: ‘Open banking’

The new directive will establish the rules of the game in a field that will become very familiar: open

banking. While PSD laid the legal framework for the SEPA area, PSD2 regulates the move towards greater

competiveness in the financial services terrain.

Open banking is based on two principles:

� The details a bank (‘a traditional financial institution’) has on its customers belong to the individual

customer, not the bank. This will require banks to allow third-party payment service providers access to

the details of clients who authorise it.

� The provision of financial services cannot be a monopoly of traditional banks, meaning that third-party

enterprises, like FinTech, must be able to provide their services without needing a banking license. This

will give clients a better chance to get the best business option in terms of quality, service, comfort, etc..


20

Impact of PSD2: ‘Open banking’

How is PSD2 opening up the banking world?

Take the example of online shopping.

People have more choice how to pay for their online purchases and which provider they use, for

instance a mobile payments service like Apple Pay, Google Pay or Alibaba's Alipay. Many of these

services rely on card payments. But to execute the transaction using account-to-account transfers, the

payments service must be able to access the customer's bank account (with the customer's

permission).

Where banks used to be able to decide whether or not to allow this, under PSD2 it is up to the

customer.

This is achieved by APIs.


21

APIs: Application Programming Interfaces

APIs are application programming interfaces that allow different computer systems to interact with each other. Think

of APIs as the keys that open up certain data or resources to other internal and external developers. We may not be

aware of it, but APIs drive many of our everyday online experiences. For example, Uber uses APIs to show users

where its drivers are on Google Maps.

Using APIs, developers can plug into other computer systems in an open

banking environment. They get those APIs from the bank’s public portal

(for examples see next slide) where one can see which APIs are available, i.e.

what services they can create. Businesses can use these to build innovative

solutions for customers.

There are two sides to this new banking model: every bank can include every

other bank on its platform: it is the customer’s experience that will make the

difference.


22

Examples of developers’ portals

ABN AMRO

Deutsche Bank

ING

For reference see for example:

https://developer.abnamro.com/

https://sandbox.developerhub.citi.com/

https://developer.db.com/#/

https://developer.hsbc.com/

https://developer.sc.com/


23

Payments Services Directive 2 access to account (XS2A)

A bank risks losing

control of the

interface to the

customer, and

thereby the primary

relationship as third

parties bypass the

bank’s channels.

TPPS: Third Party

Payment Service

provider


24


PSD2 prescribes new services for bank customers. Every bank has to adhere to: Account Information Service

(AIS), Payment Initiation Service (PIS) and Confirmation Available Funds (CAF).

Under PSD2, two new types of third party providers emerged:

1. Payment Initiation Service Providers (hereafter: PISP): PSD2 encourages competition in European

payments by regulating PISPs. Rather than the payer initiating the payment directly with their bank, the

payer initiates the payment via the PISP, which in turn passes the instruction to the bank.

2. Account Information Service Providers (hereafter: AISP): these providers act as aggregators of customer

payment account information. For example, presenting the customer with an aggregated viewpoint of

transactions and balances from more than one account. Currently, a customer with more than one

account would have to access each account individually through a separate interface (each with its own

security mechanism). Under PSD2, AISPs are able to consolidate information from multiple accounts and

present this back to the customer.

New relationships will blossom.


25


Relationships with three parties emerge in the XS2A era, leading to fundamental shifts in how banks have to

position themselves!

Third partyCustomer

BankWho is responsible for what?


26

To deliver XS2A a bank needs to support 5 main use cases1 Onboarding of TPP

A TPP needs to be able to find the XS2A services a bank offers and be able to test his app against these services. The TPP app needs to be registered. Only formal registered TPPs are allowed.

2 Granting by Customer

The customer explicitly gives consent to the TPP for the XS2A services the TPP wants to use. This grant to the TPP is an agreement between the customer and the ASPSP. The TPP is receiving tokens which allow the TPP to access the customer account.

3a Customer Initiates Payment via TPP

With the tokens received after granting the TPP can initiate payments on behalf of the customer. Authorisation of these payments takes place at the TPP side.

3b Customer Initiates Payment via TPP

In this case there is no grant upfront, but the customer needs to authorise the payment with the security means of the bank.

4 Customer request Account Information via TPP

With the tokens received after granting the TPP can request balance and transaction information.

5 TPP ask for Confirmation on Availability of Funds

With the tokens received after granting the TPP can request if there is enough money on the account to make a card payment.


27



28

‘Open ends’ re. PSD2

There are challenges during the transition period, i.e. the period between PSD2 entering in force (i.e.

13 January 2018 though actually pending local transposition) and 14 September 2019 when the EBA RTS

SCA enters into force.

The challenges are:

1. Delays in entry into force of the twelve PSD2 EBA mandates as they are not all ready yet;

2. PSD2 authorisation for different market parties (pending local transposition);

3. Third party access to bank accounts during ‘the grey period’;

4. The relationship between PSD and PSD2 security guidelines as the PSD guidelines are withdrawn in

January 2018 while the PSD2 guidelines are not published yet; and

5. Cross-border operating TPPs: can TPPs with a PSD2 license from their host member state user their

license in a host member state which has not yet transposed PSD2 into national law (like the

Netherlands).


29

‘Open ends’ re. PSD2

Scope discussion re. PSD2 https://www.thepaypers.com/expert-opinion/access-to-payment-accounts-under-psd2-which-accounts-are-in-scope-/763682

https://financieel-management.nl/artikel/psd2-heeft-wel-impact-op-nederlandse-spaarbanken

Questions and answers via Dutch Central Bankhttps://www.dnb.nl/betalingsverkeer/psd2/index.jsp

PSD2 and privacy

Transposition to local law

Are the Netherlands (too) late?https://www.banken.nl/nieuws/20894/nieuwe-vertraging-dreigt-voor-invoering-psd2

Microsoft Word

Document


30

Attention points for the auditor

� Transition of PSD2 into local legislation: has it been done, and are there any exceptions (e.g. Luxembourg

still allows OUR cost principle while PSD2 indicates the SHA cost principle), and with the transition

whether the open items are addressed (see an earlier slide):

1. Delays in entry into force of the twelve PSD2 EBA mandates as they are not all ready yet;

2. PSD2 authorisation for different market parties (pending local transposition);

3. Third party access to bank accounts during ‘the grey period’;

4. The relationship between PSD and PSD2 security guidelines as the PSD guidelines are withdrawn in

January 2018 while the PSD2 guidelines are not published yet; and

5. Cross-border operating TPPs: can TPPs with a PSD2 license from their host member state user their

license in a host member state which has not yet transposed PSD2 into national law (like the

Netherlands).

� Complaints process, especially whether the organisation can meet the PSD2 prescribed response times.

� Usual audit items relating to interfaces, though pay specific attention to the responsibilities of each

party in the sequence of interfacing.


31

Attention points for the auditor

� Realistic roadmap to meet RTS SCA (taking time into consideration (e.g. six months) for external parties

to develop the APIs) being aware the RTS SCA is being further specified.

� Meeting the requirements of EBA’s RTS SCA.

� How to deal with the ‘open ends’?

� Are all components aligned ‘to make it work’?

1. The PSD2 directive itself by the EU: the account needs to be opened to third parties;

2. EBA’s RTS on SCA and Common Secure Communication: states it needs to be done in a secure way

3. The API Evaluation Group of the European Payments Council drafts business requirements like API

principles; and

4. Stakeholders, like the Berlin Group, define technical standards to become RTS compliant.

� The relationship with privacy laws, esp. GDPR, ‘explicit consent’, and statement data (debtor and

creditor).


32

Summary


33

Summary


34

Summary


35

Summary


36

Summary


37

GlossaryAIS Account Information Service

AISP Account Information Service Provider

API Application Programming Interface

CAF Confirmation Available Funds

EBA European Banking Authority

EEA European Economic Area

EU European Union

EMI Electronic Money Institution

GL Guideline

PI Payment Institution

PIS Payment Initiation Service

PISP Payment Initiation Service Provider

PSD Payment Services Directive

RTS Regulatory Technical Standard

SCA Strong Customer Authentication

SEPA Single Euro Payments Area

TPPS Third Party Payment Service providers

XS2A Access to Account


38

Disclaimer

This document has been drafted on a personal, and a best effort basis with the intention to update the

NOREA audience on PSD2, and is no guarantee for a complete PSD2 audit. Make your own verification and

risk assessment before taking any decision on audit activities and reporting.

Overview PSD2 1 - NOREA

Documents

Transcript of Overview PSD2 1 - NOREA