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?

Due to the new format that the EBA has implemented, KAL is including an additional preface statement on the scope of ATMs in Payment Services Directive 2 and the EBA Regulatory Technical Standards and requests confirmation as below:

KAL understands that the original PSD2 legislation listed cash withdrawal services via ATMs in Article 3(o) as an exclusion to the Directive 2015/2366, however, KAL has read the EBA Regulatory Technical Standards draft and notes that all the principles proposed are equally applicable to ATMs as they are to card-based POS terminals in all respects.

In light of similar or dependent message formats, new dedicated interface services, and EU business rules on the requirements of SCA (or exemptions) for certain transactions, KAL believes that the EBA RTS clarification on Article 97 of PSD2 has sufficient overlap and potential impact on ATMs and their operation, and KAL, therefore, requests that consideration be made to bring ATMs back within the scope of PSD2 to ensure compliance and maintain standards for SCA and Secure Communication in line with the responsibilities of any other ASPSP, PSP, PISP or AISP.

If ATMs remain out of scope for PSD2 and EBA RTS, then KAL requests that the EBA ensures that non-discrimination and fair access is guaranteed to ATM software providers for all PSP, AISP and PISP services, provided that they are compliant with licensing and certification requirements.

In either case, KAL kindly requests confirmation from the EBA, ECB or EU of the above in the final publication of the EBA RTS.

Question 1 Response:

1. KAL agrees with the EBA and PSD2 on the need for Strong Customer Authentication, using two factors, in order to protect customers from payment fraud and theft of credentials.

Recommendations on Draft Text:

None.

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.

No comment.

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?

Response:

1. KAL understands that the EBA has taken a principle based approach with the definitions of SCA elements, however, KAL suggests that the EBA considers greater incorporation of existing standards for security, such as NIST, EMV, PCI or Global Platform.

2. KAL notes that ATMs, with use of EMV Cards and PIN are currently compliant with SCA, however, it should be noted that as currently read in PSD2, SCA is not applicable to ATM machines and this should be corrected to bring ATMs in scope ensuring pan-European application of SCA and consistent security for PSUs.

3. Ref Article 5 - As inherence verification should be unique and statistically sufficient to individual identity, the risk posed is that once the biometric template (such as facial recognition or fingerprint) is lost or compromised, then that type of biometric template should not ever be used again for any other Inherence type verifications. Therefore, the storage and access of a biometric template is paramount and we would recommend that the EBA mandates that all biometric template handling scenarios follow either or both of the following:

a. If the Biometric Template is held by an Institution or held centrally, there should be use of algorithms with sufficient strength and encrypted with a token, so that the Inherence element is never used solely without a secondary element used to proceed with verification.

b. If a secure device with a Trusted Execution Environment is available (such as a a mobile phone), so that the Inherence template is only ever stored and verified locally on the secure device, then this protects against possible loss and theft when in transit to a central biometric template store.

Recommendations on Draft Text:

General – KAL recommends that specific mention of ATM machines is made, to apply the SCA in accordance with this RTS.

Article 3 - the EBA should reference NIST Special Publication 800-63B in addition to any other European security standards bodies.

Article 4 - the EBA should reference NIST, EMV, PCI and Global Platform standards to ensure that physical devices issued or approved for use to the payer as they have been market tested with existing supply chain and business rules/liabilities apply. This should not prejudice future innovations following separate standards, but KAL would suggest the EBA lays out interoperability rules to ensure inclusion.

Article 5: the EBA should reference NIST Special Publication 800-63B in addition to any other European security standards bodies.
As in the above response, we strongly recommend the EBA address the impact of loss of a biometric / inherence template, rendering the element unusable in all future uses of that element.

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?

Response:

1. KAL agrees with the requirement to keep the SCA elements independent of each other.

2. From industry discussions, more detail of what constitutes a ‘multi-purpose device’ and how it may differ from a ‘single purpose device’ would help those without previous prior knowledge of payments devices and give clarity to the possible standards that EBA recommends.

Recommendations on Draft Text:

Article 6: EBA should provide reference architecture or reference specific information on Secure Elements (EMV), FIPS (NIST) or TEEs (Global Platform).

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?

Response:

1. KAL agrees with the concern that the ASPSP or PSP may not be able to perform SCA if there is sufficient analysis and suspicion of fraudulent activity, particularly with remote transactions.

2. Current contactless card exemptions to SCA in the market are also accompanied by business rules which assign liability and loss coverage between a customer, issuer, and merchant. The EBA should clarify what liability is being proposed in this SCA exemption.

3. As implementations of contactless ATMs currently exist in market, the EBA should confirm that these ATM terminals are in scope of PSD2 and the EBA RTS application of SCA (with the appropriate exemptions).

4. KAL agrees with the limits being proposed for contactless card transactions at ATM terminals.

Recommendations on Draft Text:

Article 8.1(b) – the EBA must amend this to include contactless ATMs, in addition to ‘point of sale’ terminals, otherwise, there will be a disparity for SCA standards for current market operations.

General – the EBA should provide more detail on the liabilities expected, where SCA is exempted in accordance with PSD2.

General – the EBA could provide more details on the use of fraud analytics and acceptable scenarios where SCA, if normally exempted, may be requested.

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?

Response:

1. KAL agrees with the provisions laid out in Chapter 3.

2. Related to Article 4 – Possession - multi-purpose mobile phones used for HCE payments are not issued or accessible by ASPSPs/PSPs and are instead, provisioned with explicit agreements and technical systems between the handset, operating system manufacturer/suppliers and ASPSPs. KAL believes that such a provisioning and agreement process falls outside of the scope of PSD2 and requests a clarification on whether this is the case.

3. If the use of use multi-purpose mobile devices and provisioning process is in scope of PSD2, then the EBA should provide sufficient mandate to these manufacturers/suppliers to allow ASPSP non-discriminatory access as this is currently restricted and monetised by suppliers such as Apple, Samsung and Google.


Recommendations on Draft Text:

General – the EBA could provide more references to existing industry standards such as NIST or EMV Issuing Guidelines, specific to each SCA element type and confirm the mandated access to TEEs by ASPSPs for multi-purpose devices.

Article 16 – as per Article 7, EBA should provide more direction on the frequency, schedule, standards, certified auditors and to whom to report to within each Member State or to EBA. For efficiency, Article 7 and 16, should be performed in the same auditor/report and schedule.

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?

Response:

1. KAL disagrees, given the lack of definitions for standards for the communication interface, with the EBA’s reasoning on the requirements for common and secure open standards for the purpose of identification, authentication, notification, and information. KAL understands that the EBA is seeking to remain technologically neutral, however, the lack of definition or technical standards will ultimately create a very disparate situation for PISPs, AISPs and PSP Card providers to connect to each individual ASPSP for required services.

2. KAL would prefer the use of industry standard APIs and can find no rationale for the explicit backing of APIs or for more detail on the minimum technical requirements for ASPSPs and PSPs, which would support 100% of the market to connect in a standard and interoperable manner.

3. Given the exclusion in PSD2 Article 3, KAL seeks clarification from the EBA that there will be no discrimination against ATM software providers using the PSP-Card Based amount confirmation services, PISP services, or AISP services, if they have the correct registration and certification.

Recommendations on Draft Text:

Article 19 – the EBA should select APIs as the technical interface as all third parties would be technically able to connect without technological discrimination.

Article 19 - the EBA should provide guidance on the minimum APIs standards to be applied by ASPSPs such as REST, SOAP, and data formats for AISP data, such as JSON, XML.

General – KAL request EBA to confirm non-discriminatory access to ATM providers for the three new services proposed in the RTS.

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?

Response:

1. KAL strongly agrees that ISO 20022 elements should be used, however KAL disagrees with the text “or approved message definitions, if available” as this is: a) open to interpretation; b) allows ASPSPs to introduce legacy or non-standard messaging; and, c) generally works against the intent to provide common and interoperable communication standards between all ASPSPs and third parties.

2. Reference technical constraints - KAL understands that card based transactions are currently done in a variety of formats and so significant changes would be needed to convert these to ISO 20022, however, KAL is aware that the European organisation Nexo is currently standardising POS and ATM to ISO 20022 and would advise close co-operation with the EBA on this initiative.

Recommendations on Draft Text:

Article 19.3 – the EBA should remove ambiguous text as above to ensure that common format and standardisation occurs using ISO 20022. Alternatively, mention could be made for POS and ATMs to migrate to Nexo / ISO 20022.

General – again KAL requests the EBA to confirm ATM inclusion into PSD2 for standardisation of ISO 20022 in line with other connections and services.

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 ?

Response:

1. KAL agrees 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, however, KAL again requests that ATMs be brought into scope for access to the new payments services and interfaces.

2. KAL notes that there is a lack of mention of E-IDAS operations, particularly for registration, issuing of certificates and how the ASPSP may check the status and permissions given to the third party and KAL would welcome a detailed process by the EBA in the final publication, so that third parties may work with ASPSPs to fully test this process prior to the implementation date.

3. Additionally, KAL notes that the EC has recently changed their website related to the E-IDAS scheme and it is difficult to find a detailed list of the current providers in each Member State. KAL requests that this information is made available in a human readable format along with the final publication of the EBA RTS.

Recommendations on Draft Text:

Article 20.1 – the EBA should provide a clear, publicly available, website on E-IDAS and the providers in each Member State so that third parties may begin the registration process as soon as possible.

General – the EBA should provide detail on the process and suggested operations to occur between the third party, the Trusted Certificate Authority, and the ASPSP for each new service mandated in PSD2.

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.

Response:

1. KAL agrees with the frequency proposed.

2. KAL would also welcome additional details or requirements for AISP Data Retention, Data Auditing and Data Reporting procedures (to whom?) as part of PSD2 as a whole.

3. KAL seeks confirmation that ATMs and ATM providers will be able to access AISP services via the new interface in a non-discriminatory manner.

Recommendations on Draft Text:

KAL has no recommendations on draft text.

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

[Other "]"

If you selected "Other", please provide details

ATM multi-vendor software provider

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

[Other"]"

If you selected "Other", please provide details

KAL's product suite enables ATM hardware, software, and bank networks, sourced from multiple vendors,to work together perfectly.

Name of organisation

Korala Associates Limited (KAL)