association of foreign exchange and payment companies (afep)

Association of Foreign Exchange and Payment Companies (AFEP)

1

Regulatory Technical Standards on strong customer authentication and common and secure communication (SCA-RTS)

Jack Wilson, PSD2 interface assessment project lead, Payments Supervision Department

Agenda

2

1. Strong customer authentication

a) Who’s in scope?

b) Overview

c) Key dates

2. Common and secure communication

a) Overview (PSD2/ open banking/ APIs)

b) Who’s in scope?

c) Key dates

Any questions?

Foreign exchange in scope of PSD2?

3

Providing foreign exchange services is not itself a payment service. Foreign exchange transactions may exist as part of, or independent from, payment services.

(PERG15 Q12)

In scope Out of scope

e.g.

customer can make payment in euros from their sterling payment account to a payee's account

e.g.

spot or forward fx transaction itself

RTS on Strong Customer Authentication and common and secure communication (SCA-RTS)

4

• The SCA-RTS sit under PSD2 (the PSRs 2017 in the UK) as additional legislation

• They support the security of electronic payments and the security of communications between firms and providers of open banking services (which firms is discussed below)

• The SCA-RTS is fully effective from 14 September 2019

• To enable firms to complete their PSD2 implementation projects in the event of a no-deal Brexit, we are making technical standards substantially in the same form as the SCA-RTS.

5

SCA-RTS-CSC

Strong customer authentication

6

Who’s in scope?

All PSPs

From 14 September 2019 PSPs must ensure that strong customer authentication is applied when a customer:

• accesses their payment account online

• makes a payment online

• carries out actions through a remote channel which may imply risk of fraud

There remain exemptions from SCA:

• low value remote payments up to 30 Euros

• contactless card payments up to 50 Euros (with certain cumulative limits)

• online payments to trusted beneficiaries

• corporate payments (subject to NCA satisfaction)

• where PSPs are using transactional risk analysis and meet fraud rate thresholds

Strong customer authentication

7

Knowledge

Possession

Inherence

Elements must be independent so that breach of one does not compromise the integrity of the others

Strong customer authentication – dynamic linking

8

Where a payment is strongly authenticated there is a requirements that:

• the payer is made aware of the amount of the payment transaction and of the payee;

• the authentication code generated is specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction;

• the authentication code accepted by the payment service provider corresponds to the original specific amount of the payment transaction and to the identity of the payee agreed to by the payer;

• any change to the amount or the payee results in the invalidation of the authentication code generated.

9

• There are a number of account aggregators already in the UK

but payment initiators are less common

• Currently account aggregators operate by ‘screen scraping’

i.e. a consumer provides the AIS provider with their banking

credentials, which in turn logs in to their account to ‘scrape’

data

• PSD2 sees a move towards the use of application

programming interfaces (APIs) – a more secure method of

accessing data involving third parties ‘plugging in’ to the banks

• Open Banking seeks to provide a single ecosystem for

these providers to gain access (via an API)

• The CMA has mandated 9 UK banks to establish common

standards for API access through the Open Banking

Implementation Entity

• These APIs can be used by firms seeking to become PSD2

compliant

Common and secure communication – how will this work in the UK?

PSD2 CMA Open Banking

Scope All payment accounts accessible online (including e-money, credit cards and instant savings)

Originally current accounts only – now aligned to PSD2

Application All providers of payment accounts that are accessible online (e.g. other banks and some building societies)

UK’s nine largest banks –open to other banks and account providers

Deliverable

A regulatory framework for access to payment accounts (technology neutral)

Standardised APIs and an “ecosystem” facilitating access by regulated AIS and PIS providers

PSD2

regulates mandates

All PSPs CMA 9

observes

Open banking APIs can be used to access accounts under PSD2

Common and secure communication


11

Who’s in scope?

Providers of payment accounts that are

accessible online aka. account servicing payment

services providers (ASPSPs)

This can include:

• Banks

• Building societies

• Payment institutions

• E-money issuers

• Credit card providers

Key questions

- Do you provide payment accounts? (PERG15 Q16)

- Are they accessible online?

“an account which is available online on a ‘view only’ basis, but without any payment functionality, would not be ‘accessible online’ for the purposes of PIS. It would, however, be ‘accessible online’ for the purposes of AIS and confirmation of availability of funds to a CBPII”. (AD 17.15)


12

What are the access requirements?

ASPSPs must provide AISPs and PISPs with access to customers’ accounts that are accessible online (where customers have consented).

Access may only be denied by the account provider where there is evidence that the access/payment may be fraudulent or unauthorised; if access is denied, the account provider must notify the FCA.

SCA-RTS compliant access can be either:

• Modified customer interface

• Dedicated interface

If accounts are in scope, there is no do nothing option


13

Access via dedicated interface

• Same availability and performance as customer

interface

• KPIs, service level targets

• No obstacles

• Monitoring

• Contingency mechanism (unless exempt)

• Identification (eIDAS certificates)

• Security of communication sessions

• Data exchanges (exchange of messages)


14

cxertificate

ASPSPDedicated interface

Customer’s account data/ payments functionality

AISP/ PISP

Provision of account information services or payment initiation to the

customer

Customer account info/

payments functionality


15

Contingency mechanism:

• intended to ensure that if an AISP or PISP cannot access a customer’s payment account via the dedicated interface (due to unavailability), it can, instead, access through the online interface(s) the customer has with their ASPSP.

• reliance on the contingency mechanism should be a temporary measure, until the dedicated interface is restored to the required level of availability and performance or the ASPSP has implemented the modified customer interface.

• where the contingency mechanism is relied upon, the ASPSP must ensure it provides a means for the AISP or PISP to be identified (this must be through the use of certificates).


16

Access via modified customer interface

An ASPSP can choose to provide access via the

interfaces used for authentication and communication

with the ASPSP’s customers.

However, this interface will need to be modified to

meet SCA-RTS requirements:

• identification, secure communication and allowing

AISPs and PISPs to rely on all the authentication

procedures provided by the ASPSP to the customer.

• Identification (certificates)

• security of communication session

• data exchanges


17

Timelines (where implementing a dedicated interface and seeking an exemption)

• Technical specifications (specify a set of routines, protocols, and tools needed by TPPs for allowing their software and applications to interoperate with the systems of the account servicing payment service providers) available to TPPs (including those not yet authorised) no later than 14 March 2019

• Testing facilities (following EBA guideline criteria a-g) available to TPPs no later than 14 March 2019

• Those seeking exemption from the contingency mechanism requirements should contact us as soon as possible to discuss their plans.

• Firms should aim to submit completed exemption requests by 14 June 2019 at the latest. More details can be found on our website.

• Email [email protected] in advance of submission, to let us know that you intend to request an exemption, or if you have any questions.

Any questions?

18

association of foreign exchange and payment companies (afep)

Documents