Association of Foreign Exchange and Payment Companies (AFEP)
Transcript of 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.
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
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)
Common and secure communication
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
Common and secure communication
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)
Common and secure communication
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
Common and secure communication
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).
Common and secure communication
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
Common and secure communication
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.