In 2019, the banking industry will continue its evolution toward a more digital, secure, open and interoperable global banking system – enhancing customer digital experience. Strong Customer Authentication specific Requirements Technical Standards (SCA-RTS) will therefore be a major issue for payment initiation, processing of electronic payment, protection of financial data access, and other financial services. Thus, assessing the general rules and requirements helps Payment Service Providers (PSP) to increase customer security and transparency. Analysing the implications of the SCA-RTS for PSPs and reviewing some key recommendations ensures stakeholders to create and capture value and offer customer new solution.
Digital transformation and disruption create uncertainties and risks for payment services and banks
PSD2 and SCA-RTS address payment services stakeholders’ issues and hurdles generated by industry landscape under digital transformation, and disruptive solutions triggered by new players such as e-money, payment service providers issuing card-based payment instruments (CBPII), PISP and AISP. Needs, issues and hurdles assessed by PSD2 and the Requirements Technical Standards (RTS) are summarized as follows.
|Safety and security||– Control Fraud
– Control Security both physical and online
– Access safety requirements
– 24/7 safety of PSU and personal data
|– Secure online payment and access of financial data
– Secure framework of online payment and access of financial data
– Secure ASPSP, PSP, PISP and PSPCPI
– Secure access through a remote channel which may imply a risk of payment fraud or other abuses
|– Development of user-friendly interface, accessible, secure and creating transparency in the payment transaction
– Ensure and guarantee fair competition among payment service industry
– Ensure technology innovation, and guarantee fair business model effect
– Reduce cost of processing fraudulent transaction, cost of KYC
– Compliance with international regulation (PCI DSS & PSD2)
– New Industry standards : 3D secure code 2.0
The EBA reflection on regulatory technical standards for authentication and communication need to systematically assess and consider the privacy dimension, in order to identify the risks associated with each of the technical options available and the solutions that could be put in place to minimize threats to data protection. The exponential growth of internet payments and mobile payments must be accompanied by a generalized enhancement of security measures. Visa’s infographic on european mobile payments shows that in 2016 the number of Europeans using their mobile devices to pay has tripled over the past year, more than 54% of respondents regularly use their mobile device to pay for goods and services, which is three times as many as in 2015 (18%). In 2017, Visa’s Annual Digital Payment Research stated that more than 77% of Europeans are using their mobile devices to access their payment account and make everyday payments.
As I explain in the PSD2 series #1, the objectives of PSD2 are to make payments safer, increase the consumers’ protection, foster innovation and competition while ensuring extended playing fields for all players including new ones.
The main challenge for digital banking adoption from Visa Annual Digital Payment Research :
- Fraud and security : In 2015, 62% of people cited fraud and security as the main reason for not using mobile to pay for goods and services. This figure has remained almost the same the 2016 data (65%). But, worries about security have seen a decrease, dropping to 59 percent in 2017.
- Privacy concerns: In 2015, just under half of the respondents (45%) cite privacy and data as concerns holding them back. This figure has increased slightly to 51% in 2016. Concerns about privacy have dropped to just 46 percent in 2017.
- Lack of Education and Knowledge: Visa research explain that in 2016, 55% of the respondent’s Mobile payment user are not seeing a compelling reason to switch. (no data for 2017). Moreover, a quarter of respondents (24%), who are not Mobile Payments users, state that a lack of understanding of the technology was a primary obstacle to adoption.
When looking at the growth of digital payments, one of the key drivers is to increase comfort levels of online technology. Therefore, payment services offered via internet, mobile or via other digital channels, should therefore include the authentication of transactions through dynamic codes, in order to make the user always aware of the amount and the payee of the transaction, and other relevant information that the user is authorizing.
PSD2 general rules (PSD2 2015/2366) to offer strong customer authentication
The general principals of Strong Customer Authentication enter into force on 13 January 2018 after the publication of Payment Service Directive 2 (PSD2) in the Official Journal of the European Union we are going to analyses the content in this article to grasp “What are PSD2 general rules regarding Strong Customer Authentication for the provision and use of payment services?”. The directive gives the European Banking Authority (EBA) a mission to define specific security measures beneath Regulatory Technical Standards (RTS) this will overview in a second part. Those specific tasks are fully in line with the role and responsibilities of EBA as provided in Regulation (EU) No 1093/2010. The goal is to ensure effective and secure communication between all relevant actors. Those requirements are more concrete and will be directly applicable in the member states of the EU/EEA on the 13 September 2019, and do not have to be transposed in national law.
1. Who is concerned by Strong Customer Authentication (SCA)?
SCA apply for all payment service provider in the scope of PSD2. PSP are bodies referred into Article 1 as a natural or legal person providing payment services and other financial services authorized and regulated by member state under PSD2.
|Account servicing payment service provider (ASPSP)||Payment service provider providing and maintaining a payment account for a payer;|
|Payment Instrument Issuing Service Provider (PIISP)||Payment service provider contracting to provide a payer with a payment instrument to initiate and process the payer’s payment transactions;|
|Payment Initiation Service Provider (PISP)||Payment service provider providing and maintaining a service to initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider;|
|Account Information Service Provider (AISP)||Payment service provider providing and maintaining an online service to provide consolidated information on one or more payment accounts held by the payment service user with either another payment service provider or with more than one payment service provider;|
|Payment service user (PSU)||Natural or legal person making use of a payment service in the capacity of payer, payee, or both;|
This article excludes services provided by technical service providers to comply to PSD2. Therefore, service providers which support the provision of payment services, without them entering at any time into possession of the funds to be transferred, including processing and storage of data, trust and privacy protection services, data and entity authentication, information technology (IT) and communication network provision, provision and maintenance of terminals and devices used for payment services, with the exclusion of payment initiation services and account information services.
2. What is Strong Customer Authentication (SCA)?
Article 97 – Authentication:
|Payment or account information services||SCA or SCA + Dynamic link||Security measures|
|– accesses its payment account online
– carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.
|strong customer authentication||Have in place adequate security measures to protect the confidentiality and integrity of payment service users’ personalized security credentials.
|-Initiates an electronic payment transaction
|strong customer authentication that includes elements which dynamically link the transaction to a specific amount and a specific payee.|
It is the duty of Member States to ensure that the ASPSP allows PISP and AISP to rely on the authentication procedures provided by the ASPSP to the PSU. Strong Customer Authentication as the authentication based on the use of two or more elements categorized under:
|Knowledge||something only the user knows||Pin, passwords…|
|Possession||something only the user possesses||Card, Mobile, Computer…|
|Inherence||something the user is||Biometric identification:
– Finger prints
– Iris recognition
– Face recognition
Knowledge, possession, and inherence need to be independent meaning that the breach of one does not compromise the reliability of the others and is designed in such a way as to protect the confidentiality of the authentication data.
Security of electronic payments is fundamental for ensuring the protection of users and the development of a sound environment for digital business and e-commerce. All payment services offered electronically should be carried out in a secure manner, adopting technologies able to guarantee the safe authentication of the user and to reduce, to the maximum extent possible, the risk of fraud. As an example, the protection of customer sensitive payment data, including personalized security credentials which can be used to carry out fraud.
FYI: For the activities of payment initiation service providers and account information service providers, the name of the account owner and the account number do not constitute sensitive payment data.
3. When will SCA have to be applied?
4. What are the rights and obligations in relation to the provision and use of payment services related to Strong customer authentication (SCA)?
Authorization of payment transactions (Chapter 2)
SCA is one of the pillars of PSD2 regulation, payment transaction authorization needs to be pre validated by authentication process, and the failure to offer this service will have effect on : confirmation on the availability of funds, execution and validation of payment transactions, and the liabilities for unauthorized payment transactions.
Confirmation on the availability of funds (Article 65)
Member States must ensure that an ASPSP, upon the request of a CBPII, immediately confirm whether an amount necessary for the execution of a card-based payment transaction is available on the payment account of the payer, if all the following conditions are met:
(a) the payment account of the payer is accessible online at the time of the request;
(b) the payer has given explicit consent to the ASPSP to respond to requests from a specific PSP to confirm that the amount corresponding to a certain card-based payment transaction is available on the payer’s payment account;
(c) the consent has been given before the first request for confirmation is made.
Any PSP may request the confirmation on the availability of funds where all the following conditions are met:
(a) the payer has given explicit consent to the PSP to request the confirmation on the availability of funds
(b) the payer has initiated the card-based payment transaction for the amount in question using a card-based payment instrument issued by the PSP;
(c) the PSP authenticates itself towards the ASPSP before each confirmation request, and securely communicates with the ASPSP with common and secure open standards of communication (Open banking API and ISO 20022)
The message answer from ASPSP consist only in a simple ‘yes’ or ‘no’ answer and not in a statement of the account balance. It is forbidden to store the answer message or use it for purposes other than for the execution of the card-based payment transaction. (Directive 95/46/EC). In any occasion, the confirmation on the availability of funds shall not allow for the to block funds on the payer’s payment account. The payer may request the ASPSP to communicate to the payer the identification of the PSP and the answer provided.
FYI : Article 65, Chapter 2 on confirmation of availability of funds does not apply to payment transactions initiated through card-based payment instruments on which electronic money as is stored. point (Article 2, Directive 2009/110/EC)
Evidence on authentication and execution of payment transactions (Article 72)
Member States shall require that, where a PSU denies having authorized an executed payment transaction or claims that the payment transaction was not correctly executed, it is for the PSP and PISP to prove that the payment transaction was
- accurately recorded,
- entered in the accounts and
- not affected by a technical breakdown or
- not affected by some other deficiency of the service provided by the PSP.
Where a PSU denies having authorized an executed payment transaction,
- The use of a payment instrument recorded by the PSP, including the PISP as appropriate, shall in itself not necessarily be sufficient to prove
- either that the payment transaction was authorized 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 69.
- The PSP, including, where appropriate, the PISP, shall provide supporting evidence to prove fraud or gross negligence on part of the PSU.
Payer’s liability for unauthorised payment transactions (Article 74)
- Payer may be obliged to bear losses up to a maximum of 50 EUR relating to any unauthorized payment transactions due to:
- Stolen payment instrument
- Misappropriation of payment instrument
- Payer is not obliged to bear the losses if:
- Loss, theft or misappropriation of a payment instrument was not detectable to the payer prior to a payment
- Loss, theft, or misappropriation cause by acts or lack of action of an employee, agent or branch of a PSP or an entity to which its activities were outsourced.
- Payer’s PSP do not require strong customer authentication
- Payee and Payee’s PSP fails to accept strong customer authentication
- Payer PSP do not provide appropriate means for the notification at all times of a lost, stolen or misappropriated payment instrument
- Payer is obliged to bear the losses if: (no maximum amount)
- Payer acting fraudulently
- Fail to fulfil one or more of the obligations
- Following the PSP payment instrument usage terms & conditions
- Informing the PSP without undue delay when becoming aware of the loss, theft, misappropriation or unauthorized use of the payment instrument.
- Took all reasonable steps to keep its personalized security credentials safe, or gross negligence.
- Payer is not obliged to bear the losses if:
PSU liabilities may be reduce considering, in particular, the nature of the personalized security credentials and the specific circumstances under which the payment instrument was lost, stolen or misappropriated.
- Where the payer has neither acted fraudulently
- nor intentionally failed to fulfil its obligations under Article 69
Execution of payment transactions (Chapter 3)
SCA enables to structure relationship between all payment transaction stakeholders. Liabilities are defined and right of recourse are clear (Article 92). Indeed, PSP or intermediary of a financial service shall compensate the first PSP for any losses incurred, including compensation where any of the PSP fail to use SCA. Further financial compensation may be determined in accordance with agreements between PSP and/or intermediaries and the law applicable to the agreement concluded between them.
Data protection for the purposes of payment services (Chapter 4)
Member states allow processing of personal data by payment systems and PSP safeguarding:
- Prevention of payment fraud
- Investigation of payment fraud
- Detection of payment fraud
European and national regulation regarding data privacy and protection of personal data (GDPR) must be respected when carried out a payment service. Therefore, PSP can only access, process and retain personal data necessary for the provision of payment services and with the explicit authentication of the PSU.
Operational and security risks and authentication (Chapter 5)
Management of operational and security risks (Article 95)
Member States must ensure that PSP set up a payment services framework to enable
- Mitigation measures (e.g. establish and maintain effective incident management procedures)
- Control mechanisms (e.g. establish detection and classification of major operational and security risks)
Member States must ensure that PSP provide information regarding the payment services to the competent authority (annual basis, or at shorter intervals)
- Updated comprehensive assessment of the operational and security risks
- Adequacy of the mitigation measures and control mechanisms implemented
Therefore, since the 13 July 2017, EBA and EPC have work in close cooperation, and consult all relevant stakeholders of the payment service industry, and issued guidelines regarding:
- Establishment, implementation and monitoring of the security measures, including certification processes where relevant
Every 2 years, and considering the applications of the guidelines, the EBA develop regulatory technical standards on the criteria and on the conditions for establishment, and monitoring, of security measures. Those requirements are more concrete and are directly applicable in the member states of the EU/EEA starting the 13 September 2019, and do not have to be transposed in national law.
Incident reporting (Article 96)
In the case of a major operational or security incident, PSP must, without undue delay:
- Notify the competent authority in the home Member State of the PSP.
- Inform its PSU of the incident and of all measures that they can take to mitigate the adverse effects of the incident ( Where the incident has or may have an impact on the financial interests)
Competent authority of the home Member State must , without undue delay:
- Provide the relevant details of the incident to EBA and to the ECB.
- After assessing the relevance of the incident to relevant authorities of that Member State, notify them accordingly.
- On the basis of that notification, the competent authorities shall, where appropriate, take all of the necessary measures to protect the immediate safety of the financial system.
EBA and the ECB must in cooperation with the competent authority of the home Member State:
- assess the relevance of the incident to other relevant Union and national authorities
- notify them accordingly.
- The ECB shall notify the members of the European System of Central Banks on issues relevant to the payment system.
Therefore, since 13 January 2018, EBA, in close cooperation with the ECB and after consulting all relevant stakeholders of the payment services market, issued a guideline:
- PSP incident reporting guidelines and classification of major incidents (e.g. The content, the format, including standard notification templates, and the procedures for notifying such incidents)
- competent authorities, on the criteria on how to assess the relevance of the incident and the details of the incident reports to be shared with other domestic authorities.
Regularly, and considering the applications of the guidelines, the EBA develop regulatory technical standards on the incident reporting and ensure that PSP, at least on an annual basis, statistical data on fraud relating to different means of payment to their competent authorities. Those competent authorities must provide EBA and the ECB with such data in an aggregated form.
5. Conclusion on PSD2 general rules
The article’s objective is to enable readers to grasp the level of innovation and security PSD2 regulation is engaging the financial service industry. SCA elements (knowledge, procession and Inherence) and Dynamic Link (bridging transaction to specifics details- such as amount and payee etc.) are core to PSD2 to control and manage the digital transformation and disruption uncertainties and risks. As this first part regarding SCA assesses all PSD2 regulations and implications, the next part reviews the EBA Regulatory Technical Standards (EBA RTS) requirements to implement PSD2 regulation and grasp some recommendation to follow regarding SCA implementation, monitoring and support.
EBA’s Requirements Technical Standards and pragmatic recommendations to offer strong customer authentication
On the 13 September 2019, all payment services related to PSD2 regulation must apply the European Banking Authority (EBA) Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and secure communication (review in next series #4). Otherwise, banks and payment services provider could legally not be recognized as PSP and lose the right to provide payment services in the EU and are exposes to penalties set by national regulators. Moreover, a failure to implement these EBA RTS capabilities properly may also expose banks and payment services to potential loss, breach and miss usage of sensitive customer data and, under GDPR, they could be fines of up to 2 percent of global annual turnover.
Digital uncertainties and risks can be created by various innovation such as OCR, image analytics, computer vision, Artificial Intelligence, Machine learning, and Natural Language Processing and biometric, and these digital transformation and disruption if regulator do not channel with proper requirements, financial service to end customer could be negatively impacted (e.g. such as creating breach in their data privacy and putting at stake their data security, and even reduce the scope of accessibility to financial services due to monetization of proprietary platform development for example). Series #1 pointed out that PSD2 is dramatically changing not just the payments sector but the wider banking market. Strong customer authentication is an important pillar of PSD2, and EBA RTS provides clarity on several ambiguities.
1. Define and select the right Representational State Transfer Application Programming Interfaces architecture (Rest API architecture)
- EBA RTS requirements does not provide definitions of the interfaces needed.
- Select and join an industry groups interface e.g.: Berlin Group define common standards on XS2A, Payment initiation and SCA.
- Define and develop proprietary API interfaces respecting common industry standards
- Rest API interface is a messenger enabling information exchanges, taking request from TPP/Banks and returning an answer to them.
2. Define and select the right functions of the API interface to be the bridge between all stakeholders (API functions to connect with Banks, TPP, Customer)
- Screen scraping is no longer allowed
- Banks are required to grant third parties’ access to customer data via specific and dedicated API interfaces
- providing high-quality access,
- must not be discriminatory,
- and any rejection of access must be justified.
- Licensed TPPs using this interface must digitally sign the messages to identify themselves (SCA TPP) in order to
- Access the customers payment account (XS2A)
- Make a payment on customer behalf (via CT)
- Provide customers with overview of their various payment accounts
3. Define, select and implement the right Authentication methods to enhance payment security (Personal Security Credential, unique identifier, API Keys)
- Bank must authenticate both the TPP and their customer.
- TPP can rely on the Bank authentication procedures
- In order to authenticate a customer TPP must pass control to the bank to authenticate the customer
- A double control is therefore done one by the TPP and second by the Bank, and obviously only with the prior consent of the customers!
- Select solution and methods such as Multi-Factor Authentication, two Authentication factors, applying industry standards such as 3DSecure 2.0, Oauth 2.0, Open ID.
4. Define and select the right digital certificates e.g. use of eIDAS authorities
- EBA RTS and opinions mandated the use of Digital Certificates (eDIAS) or Qualified certificates for electronic seals (QSealCs) or qualified certificates for website authentication (QWACs)
- In December 10, 2018, the EBA release an opinion on the use of eDIAS for strong customer authentication engage banks to choose whether to use a certain digital certificates for identification purpose.
- Banks must provide the interfaces, and as well ensuring the security of the identification and the communication
5. Implement the right SCA process and authentication codes generation and verification
- Authentication code and SCA process is accepted only once for a single payment initiation
- Authentication code and SCA process is accepted multiple time for TPP:
- to initiate a series of payments,
- to retrieve account information,
- Authentication code and the transaction details (payment reference, amount and payee) need to be dynamically linked.
6. Engage a continuous, agile risk analysis and be able to operate real-time fraud detection and prevention
- Real-time fraud detection to prevent, detect and block fraudulent payments
- Risk analysis approach,
- High-risk transactions being blocked for suspected fraud,
- Low-risk transactions potentially bypassing SCA.
- Acknowledge a specific agile risk management approach with clearer reporting and processing procedures.
7. Be aware and respect exemptions from strong customer authentication
- EBA RTS give precision to exemptions from SCA including
- For contactless card payments
- Single-transaction value has been raised to €50,
- Option no more than five consecutive non-SCA transactions
- For low-value payment exemption: €30, with a cumulative value of €100 or a cumulative count of five, aligned to the contactless exemption.
- For unattended transport, and parking terminals
- For payments to beneficiaries on the list of trusted beneficiaries
8. Take measure regarding all transactions that do not fall under exemptions requires strong customer authentication e.g. Card transactions and some digital ATM withdraw
- Card payment requiring SCA will need to follow 2 elements selections and dynamic linking
- Issuing vendors have work on some interesting innovation
- Dynamic CVV (CVV change regularly) Card is used as one elements to prove “Possession”, coupled with a second elements “knowledge” satisfying the ‘two-factor’ requirement. i.e. 3D-Secure 2.0 can be another solution for online payment
- Battery-less biometric payment Card/Wearable such as the ones offer by the innovative company Zwipe
9. Safeguard the integrity and security of sensitive payment data
- Banks must provide PISP and AISP with the exact same information from designated
- Payment system
- Payment accounts
- Payment transactions
- Payment service user when accessing through AIS need to have the same information made available when directly accessing the information from banks online banking
- Banks need to guarantee the protection of customer sensitive payment data, including personalized security credentials which can be used to carry out fraud (username and password and other SCA elements)
EBA RTS are ongoing requirements, they are plethora of opinion, change and adaptation in regard to different need and lobbying from different market players. Generally, Regulatory technical standards help to clarify PSD2 rules and show the path to Banks and TPPs for innovation. The implementation of Strong communication standards (SCA) and common standards of communication (CSC) need to
- be controlled by national authorities,
- created and promoted by industry groups,
- mastered by risk manager and compliance officers.
At a pragmatic level, it is the duty of technology departments to enhance SCA and CSC knowledge and training across the enterprise wide system and as well teams. Technology departments are the key element to fully capture the added value from PSD2 and EBA RTS requirements. Indeed, in an extremely near future, API and sandbox will become digital products and services of banks and PSPs and will need to be monetized in order generate substantial revenue growth.