Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2

Go back

Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?

NA

Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.

NA

Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?

Other threats than the ones identified in articles 3,4 and 5 of the draft RTS are especially during initiating and association of service users’ personalized security credentials in terms of impersonation.
Globally the ISO/IEC 29115 (Entity Authentication Assurance Framework, EAAF) is the most important standard defining technical and organizational security levels in the domain of assurance levels for electronic identification means and is the basis for many countries implementing electronic identities and electronic authentication methods. The EAAF is embedded into a set of ISO standards where ISO/IEC 24760 - 1 within the framework for identity management defines the terminology and overall concepts.
The EAAF provides requirements and implementation guidance for each of the four LoAs. In particular, it provides requirements for the implementation of processes for the following phases:
a. Enrolment (e.g., identity proofing, identity verification, registration);
b. Credential management (e.g., credential issuance, credential activation); and
c. Authentication.

It also provides guidance regarding management and organizational considerations (e.g., legal compliance, information security management) that affect entity authentication assurance. Entity Authentication Assurance (EAA) comes not from technical factors alone, but also from regulations, contractual agreements, and consideration of how the service provision is managed and organized.
A technically rigorous solution without competent management and operation can fall short of its potential for providing security in the provision of EAA.
Within the ISO/IEC 24760 - 1 entities will have an identity. An identity is the information used to represent an entity in an Information and Communication Technology (ICT) system. The purpose of the ICT system determines which of the attributes describing an entity are used for an identity.
An attribute of an identity describes the state, appearance or other qualities of an entity relevant in a domain. Within the PSD 2 / RTS the most relevant attributes are:
- Information about physical existence, such as
• Biographical details,
• Horne or business address,
• Device location;
- Information describing the entity's evolution over time such as
• Installed applications,
• Device configuration;
- Information intrinsic to the physical existence of the entity, such as
• Biometry;
-Information assigned to the entity, such as
• Title,
• Role,
• Digital signature,
• Social security number,
• Citizenship number,
• Passport number,
• Manufacturer's serial number,
• Network (MAC) address,
• Cryptographic key;

ISO/IEC 29115 provides a framework for entity authentication assurance. Assurance within this international Standard refers to the confidence placed in all of the processes, management activities, and technologies used to establish and manage the identity of an entity for use in authentication transactions. An overview of the Entity Authentication Assurance Framework is shown in Figure 1. (Note: all figures mentioned in this answer are send to the EBA via separate E-Mail as the online consultation form does not provide the ability uploading drawings).

Figure 1

ISO/IEC 29115 defines four Levels of Assurance (LoA) where the “strong customer authentication” as defined within PSD 2 is associated either with LoA3 or LoA4. The ISO/IEC 29115 was taken into account within the EU when setting up the e-IDAS regulation also.
ISO/IEC 29115 clearly defines the threats (e.g. impersonation) and necessary controls for all LoAs and how to deal with attributes (e.g. Biometrics) and Non Person Entities (NPEs) like mobile Phones and tablets during the initiation and association phases as it is required for PSD 2.
Most of the requirements described in articles 3, 4, 5 within chapter 1 are following the requirements of ISO/IEC 29115 already but without mentioning it explicitly.
Figure 2 shows how ISO/IEC 29115 interacts with PSD 2 and RTS:





Figure 2

The risk assessment to determine if PSD 2 correlate to LoA 3 or LoA 4 shall be done by the commission and/or the EBA as there should be a common risk assessment across the EU.
An identity and relevant attributes within PSD 2 might vary from an identity and attributes acquired during establishing a business relations between a user and a PSP (e.g. opening a bank account). Currently while opening a bank account there are three major aspects which have to be taken into account.
1. Opening a bank account shall fulfill directive EU/2015/849 where the focus is on anti-money laundering and anti-terror financing. This is a risk based approach with a focus on anti-money laundering and anti-terror financing but not a focus on the true identity of a customer as described in the FATF recommendations . Within these recommendations an uncertainty with respect on the true identity of a customer is accepted (e.g. carrying out occasional transactions above the applicable designated threshold (USD/EUR 15,000) . An additional evidence of the above mentioned is that it might be accepted that “verifying the identity of the customer and the beneficial owner after the establishment of the business relationship (e.g. if account transactions rise above a defined monetary threshold)” .

2. According to FATF recommendations the Customer Due Diligence measures to be taken are e.g. identifying the customer and verifying that customer´s identity using reliable, independent source documents, data or information . Based on the ISO/IEC 29115 Controls against enrolment phase threats Identity proofing Authoritative Information:

“Ensure the entity provides a document from another context which includes both contact information and identity information, such as address or phone number from a utility bill or phone bill” limits the achievable LoA of opening a bank account following the FATF Recommendations to LoA 2.

As a result of the above mentioned all bank accounts opened under EU/2015/849 following the latest FATF Recommendations provide identities only with LoA 2 and not as they are required with LoA 3/4 of PSD 2.

3. Opening a bank account may not enroll other than administrative attributes (e.g. name, birthdate, address) but no biometrics or NPE related information. Therefor the Customer due diligence following FTAF recommendations might not deliver the required proven identity information with all necessary attributes required for PSD 2.

Within PSD 2 there is a fundamental different approach. One major goal is enhancing the customer’s security within electronic payments which have led to “strong customer authentication”. Here the focus is that the payment will be initiated with a high assurance by the legitimate payment services user. The associated Level of assurance is either LoA 3 or LoA 4.
One fundamental rule for LoA 3 or LoA 4 is that all required identity information shall come from at least one authoritative source of identity. Authoritative sources of identities are either countries (e.g. ID-Cards, register of birth, register of immigration) or Registration Authorities (RA) working on the required level of assurance especially where ID-cards do not provide required information (e.g. MAC-Addresses, phone numbers, biometrics). Authoritative sources of identities are neither utility nor phone bills. Utility and phone bills might be used as initial sources of contact information (e.g. address) but not as an authoritative source of identity on LoA 3/4 because it is not the purpose of a utility or phone company being liable for identities of customers against third parties. Utility and phone companies are no identity brokers.
According to ISO/IEC 24760 an identity of an entity consist of any set of attributes that describes a particular entity. All relevant attributes have to be verified by a RA working under the required LoA. Every time when a customer append attributes (e.g. phone number, mac-addresses, biometrics) to their own identity (self-asserted) the LoA of the identity data set will be corrupted to LoA 1 even if some attributes (e.g. Name, birthdate) may come from an official source of identity. Therefore ISO/IEC 29115 forces MAC addresses, phone numbers of NPEs (e.g. mobile phones, tablets), biometrical data (e.g. finger print, face, voice) have to be enrolled and verified by RAs working at the required LoA 3 or 4.
During an enrolment/initiation phase an identity and all related attributes have to be captured and verified according to the required LoA 3/4. All effort implementing PSD 2 and the extensive legal consequences associated with PSD 2 could just be justified if every process step follows the requirements of the determined LoA 3/4 as defined within ISO/IEC 29115 and ISO/IEC 24760. This includes explicitly enrolment and verification of all relevant attributes of an entity.
As described in ISO/IEC 29115 “threats and controls” the threat of impersonation during enrolment/issuing phase for biometric data and all other attributes (e.g. phone number) have to be taking into account fulfilling LoA 3/4 requirements.

Therefor for all authentication elements mentioned in articles 3, 4 and 5 there have to be organizational procedures in place (controls against enrolment/issuing phase threats) ensuring enrolment/issuing minimize the risk of impersonation and fulfill either LoA 3/4. Especially self-enrolment procedures for biometrics (e.g. picture) and NPE attributes does not fulfill LoA 3/4 requirements. As mentioned above EAA comes not from technical factors alone, but also from regulations, contractual agreements, and consideration of how the service provision is managed and organized.
Furthermore the required security level could only be achieved if the enrolment/association processes are at least on the same level as the overall security level. Enrolment/association could not be done going from “lower levels” to “higher levels” (e.g. using username/password to download credentials into a mobile device).

Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?

NA

Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?

NA

Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?

Following ISO/IEC 29115 processes (Figure 1) there should be an additional article in the RTS (article 11 new) between article 10 and article 11 which might be called “enrolment of the payer for personalised security credentials, authentication devices and software”. This article shall describe the principle process requirements according to ISO/IEC 29115 enrolment phase.
The overall basic principles for the following articles shall be all processes described in chapter 3 must at least be carried out on the required Level of Assurance of ISO 29115 LoA 3/4.
Within ISO/IEC 29115 the processes for enrolment are defined. The enrolment phase consists of four processes: application and initiation; identity proofing; identity verification; and record-keeping/ recording. These processes may be conducted entirely by a single organization, or they may consist of a variety of relationships and capabilities provided by a number of organizations including shared or interacting components, systems, and services. Within ISO/IEC 29115 non person entities (NPEs) like mobile phones or tablets are also included.
As described within the answer to question 3 there is a threat of impersonation during the enrolment/initiation phase where one threat might be caused by achieving a different LoA then required by PSD 2 if business between a user and a PSP was established according to latest FATF recommendations (max. LoA 2) and not the requirements of PSD 2 (LoA 3/4). Within article 11 new it also shall be described that all attributes which are part of an identity within PSD 2 shall be captured and verified according to LoA 3/4. If attributes are captured and self-asserted only by the user the overall achievable LoA will be limited to LoA 1 (see Figure 4).


Figure 4

Enrolment might be done when establishing business relations between the user and a PSP at the first time (no online activities) but could be done afterwards also.
The PSPs have to check if the attributes relevant within PSD 2 “strong customer authentication” of a customer already fulfill LoA 3/4 requirements or if they have to adopt enrolment or verifying processes. The effort for PSPs implementing ISO/IEC 29115 conform processes might vary from “do not need improvements” to “have to implement new processes”.
Most of the requirements described in chapter 3 are following the requirements of ISO/IEC 29115 already but without mentioning it. Articles 11, 12 and 13 are implicit references to ISO/IEC 29115. But on the other hand some fundamental requirements are missing. To make the requirements clear for the industry being compliant with ISO/IEC 29115 it should be stated that all processes within chapter 3 have to be ISO/IEC 29115 compliant.
If chapter 3 of the RTS will not follow the ISO/IEC 29115 LoA 3/4 overall process chains and focusing just on technical aspects all effort implementing “strong customer authentication” within PSD 2 will be limited to the weakest part of the process chain, which is the customers identity and customer attributes and so the overall achievable LoA will be limited to LoA 1 (self-asserted attributes).
Examples of processes which will not fulfill LoA 3/4 requirements are “selfie-pay” instruments where the first “reference” selfie will be captured by the customer himself (self-asserted) without being verified by an authorized registration agent (RA).

Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?

NA

Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?

NA

Question 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?

NA

Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.

NA

Please select which category best describes you and/or your organisation

[Non-financial, private sector institution"]"

Please select which category best describes the services provided by you/your organisation

[Other"]"

If you selected "Other", please provide details

Consulting, implementing and auditing identity management systems with a focus on legal and organisational aspects.

Name of organisation

LSc LifeScience Consult GmbH