Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
The scope of the article 97 has direct impact to to PSP’s production costs and requirements related to level playing field between the service providers. Therefore the clarity of the defintions and the scope of the article 97 is utmost important.
From legal point of view the e.g. definition “access into accounts” is not self-explanatory. The certain unclarity applies also to the other definitions (b) and (c) of the article 97 of the PSD. Due to the fact the definitions in the article 97 have fundamental impact on requirements related to strong customer authentication EBA should focus on clarifying the operations or points in the payment chain where strong authentication is necessary (what are e.g. the procedures for changes in payment services, e.g. changes in geographic validity of cards, changes in payment limits, amendments in white or black lists or acceptance of electronic mandates). After the clarification RTF should give clear guidance what are the processes/transactions strong authenticaton is needed.
It is important that the RTS allows for the use of general purpose devices such as mobile phones and universal identification methods. Other physical devices constitute additional cost and are at risk to be short life cycle, as well as being less customer-friendly. Therefore the RTS must allow data, e.g. mobile apps, to be appropriate as a possession element. That requires, however, that the data is stored in a device that is strongly footprinted" by the software issuer, in practice meaning that the possession of the unique mobile device is necessary to make the authentication.
Cards, mobile phones, specialized separate secure authentication and signing apps can all be appropriate examples of possession."
These parameters in a risk analysis are used in an opposite way to strong authentication measurements: e.g. when the PSU is not in his usual location, that is a signal of higher risk, which might bring the risk analysis not to decline the transaction, but to prompt for strong authentication – i.e. the exemption does not apply as the risk analysis shows higher risk.
It is very important that these two areas are clearly separated: what is required of an element to qualify as a strong customer authentication factor, and what are valid parameters to use in a risk-based decision not to require strong authentication. It is important to have clear discrepancy in definitions between what strong authentication and what is low risk in a risk analysis, both to understand the dynamics between the two in practical implementations, but also in the context of determining liabilities according to PSD2: when exemptions are used in compliance with the potential RTS that will allow risk analysis for exemption and strong authentication therefore is not done on a transaction, the liability falls on the party not supporting strong authentication (=exercising the possibility of exemption) for the specific transaction.
The definition of the “inherence” need also to be clarified.
For card transactions the 3D Secure infrastructure provides a dynamic linking to the amount and the payee, for whatever authentication method the card issuer chooses to use (strong, weak or suppressed (risk-based)).
For card transactions the 3D Secure infrastructure provides a dynamic linking to the amount and the payee, for whatever authentication method the card issuer chooses to use (strong, weak or suppressed (risk-based).
Example B gives rise to additional questions, such as how and on what ground white lists are collected and uses, and for which EBA should elaborate in the RTS:e.g:
• Could a white list be constituted (in part or in whole) of payees that the payer have payed to before, i.e. “passive collection” of white list? Possibly with an opportunity for the payer to delete payees from the list.
• Do a PSP using PSU generated white lists have to accept all payees that a PSU potentially would like to white list? Nordea’s view is that they PSP should not be required to accept all payees on the white list, it must be on the PSPs discretion, which payees and/or categories of payees that are eligible for the PSU to white list.
On example D, EBA states in paragraph 44 that it “currently observes in the market that the reliability of such analysis is closely related to the availability of sufficiently detailed information and history from both, the payer and payee.” Further, EBA states in paragraph 45 that it should be required “to be based on comprehensive real-time risk analysis taking into account (a) an adequate transaction history of that customer to evaluate the latter’s typical spending and behaviour patterns, (b) information about the customer device used (e.g. IP address, model, operating system, language preferences) and where applicable (c) a detailed risk profile of the payee (e.g. types of service provided, transaction history) and the payees device (where applicable).”
Nordea’s view is that this aggregation of information is almost impossible to accomplish in a the normal four-party model in which most payments are carried out. The PSP of the payer has relevant and valid information on the payer (at least if the PSP is also the ASPSP) but usually poor information on the payee, it could be the merchant’s name and a merchant’s category code, but the payer’s PSP of course lacks information about the transaction history of the payee. The other way around, the PSP of the payee has valid information about the payee, but lacks information about the payer, apart from any transaction history on this specific payee (and if the same payment instrument was used by that payer).
EBA should focus on elaborating the criteria under what circumstances risk-based analysis should be possible to be used by the payer’s PSP or the payee’s PSP, or both. For a card transaction, for example, if the PSP of the payee, the acquirer, together with the payee (merchant) decides to use a risk-based decision not to support strong authentication (i.e. 3D Secure infrastructure which enables the dynamic linking of the authentication method used by the issuer) for a specific transaction, the PSP of the payer, the issuer, does not get any possibility to do a risk-based decision of its own, the decision is already taken from the point of interaction. This strongly relates to the allocation of liability for fraudulent transactions, as provided by Article 74(2) in PSD2.
EBA should also make it clear in the RTS that it is up to each PSP to what extent the PSP uses the possible reasons for exemtions from the requirements on strong authentication. The RTS should specify what per maximum can be allowed as criteria for exemptions. Then the individual PSP may decide not to exercise this possibility at all, or to a lesser extent than possible (i.e. with stricter requirements than stated in the RTS for when the strong authentication is not prompted.
Particularly in Nordic and Baltic countries service credentials are widely also used for strong identification against the third party series (e.g. public services). This kind of usage is segregated as an independt services which are implemented in line with national laws. In most of the countries current regulation expressly prohibits a customer to give service credentials anyone else than directly to contracting party (including PIS/AIS PSPs). Due to PIS/AIS service model national laws on strong identification need to be amended. Because these services are well established the accepted procedure how provide services via PIS and/or AIS services need to be analysed and RTS should acknowledled timelines needed for amendments of the current regulations.
Ensure that software components are adequately protected and do not comprise malware. Too complicated technology does not meet all business needs; there is a fear for very long implementation times.
Credit institutions are required to have in place a detailed IT security risk policy.
While third party certification may make sense in certain areas, any requirements for additional certification by third parties should take into account measures and requirements already in place.
If an approach is chosen where TPPs are allowed to access and transmit PSCs, steps should be taken to ensure an adequate security environment – which could include third party certification.
(a) Identification of the licensensed PSP. The primary problem is that how a PSU can make a distinction between the licensed PIS/AISPSP and fraudster. This is the point in the chain most likely subject to social engineering.
(b) PSU has no effective control over the factual exploitation of the service credentials in the PIS/AIS services. These risks related to PIS and/or AIS services are embedded into the business model as such not to the specific technology or defects in the regulation.
(c) Payment platformes exploited by the payee or payee’s PSP may be technically unsecure
API standardization is key. Also governance related issues need to be taken into account.
According to definitions and terminology of the PSD2 a PSU exploiting PIS or AIS services may also be a corporate customer using file transfer based payment services. Examples and arguments around the benefits of the PIS/AIS services are however only focused on consumer/private customer services.
It is utmost important to define in what extent the PIS/AIS services may or may not be exploited by the corporate customers. In case also file based payment services are included there should be standards also for the batch transfer services.
Also, If the open and common secure standards are mandatory but include e.g. defects which cause security incident there should be clear liability regime to cover the damage of the ASPSP.
For the PIS/AIS PSP identification purposes e-IDAS may provide some benefits and additional security features. This should be however subject to further analysis related to e-IDAS standards.
When it comes to other e-IDAS services like “trusted sites” and “seals” they may be usefull for identification of licensed PSP or secure service site.
1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.
Examples highlighted in the Discussion Paper are basically appropriate- We understand the list of examples is not exhaustive but explanatory. An issue which is worthile of considering is the exploitation of service credentials for strong identification purposes for e-government services or other strong electronic identification purposes.The scope of the article 97 has direct impact to to PSP’s production costs and requirements related to level playing field between the service providers. Therefore the clarity of the defintions and the scope of the article 97 is utmost important.
From legal point of view the e.g. definition “access into accounts” is not self-explanatory. The certain unclarity applies also to the other definitions (b) and (c) of the article 97 of the PSD. Due to the fact the definitions in the article 97 have fundamental impact on requirements related to strong customer authentication EBA should focus on clarifying the operations or points in the payment chain where strong authentication is necessary (what are e.g. the procedures for changes in payment services, e.g. changes in geographic validity of cards, changes in payment limits, amendments in white or black lists or acceptance of electronic mandates). After the clarification RTF should give clear guidance what are the processes/transactions strong authenticaton is needed.
2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
Nordea is of the opinion that authentication instrument may also be virtual, but it must be personalized to a PSU with PSU’s adequate control to device, platform or software used. Requirement of physical possession of the authentication elements may hinder service development. Instead of focusing on dedicated devices or tokens, RTA should focus on generic security factors of the authentication. We welcome adoption of risk based approach instead of limiting the technical means of authentication methods as such.It is important that the RTS allows for the use of general purpose devices such as mobile phones and universal identification methods. Other physical devices constitute additional cost and are at risk to be short life cycle, as well as being less customer-friendly. Therefore the RTS must allow data, e.g. mobile apps, to be appropriate as a possession element. That requires, however, that the data is stored in a device that is strongly footprinted" by the software issuer, in practice meaning that the possession of the unique mobile device is necessary to make the authentication.
Cards, mobile phones, specialized separate secure authentication and signing apps can all be appropriate examples of possession."
3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
No, behaviour does not qualify for inherence, it is not strong enough by itself to be considered as an strong authentication element by its own right. The use of behavior-based characteristics is valid for increasing the strength of a strong authentication element, .e.g. typing patterns can be used to strengthen the use of PIN. The use of behaviour-based characteristics is also valid as parameters together with other parameters in a risk-based analysis to conclude if the transaction could qualify for an exemption from the requirement on strong authentication, as example D in paragraph 42 in section 4.2 of the DP which concerns the application of exemptions.These parameters in a risk analysis are used in an opposite way to strong authentication measurements: e.g. when the PSU is not in his usual location, that is a signal of higher risk, which might bring the risk analysis not to decline the transaction, but to prompt for strong authentication – i.e. the exemption does not apply as the risk analysis shows higher risk.
It is very important that these two areas are clearly separated: what is required of an element to qualify as a strong customer authentication factor, and what are valid parameters to use in a risk-based decision not to require strong authentication. It is important to have clear discrepancy in definitions between what strong authentication and what is low risk in a risk analysis, both to understand the dynamics between the two in practical implementations, but also in the context of determining liabilities according to PSD2: when exemptions are used in compliance with the potential RTS that will allow risk analysis for exemption and strong authentication therefore is not done on a transaction, the liability falls on the party not supporting strong authentication (=exercising the possibility of exemption) for the specific transaction.
The definition of the “inherence” need also to be clarified.
4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
We see challenging to combine customer/security needs particularly in multipurpose devices used via multichannel communication. From security perspective isolation of the authentication application need to be separated and secured apart from the “generic” mobile apps. The generic nature of the device may lead to weak footprinting" of device from the issuer of the authentication elements. There must be requirements on the minimum security level from footprinting of device techniques perspective."5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
The concept of “dynamic linking” is unclear eventhough it has significant importance in view of the potential authentication processes and liability related to them. Neither does the PSD2 give any help to intrepet the specific content of this concept. Therefore the concept needs to be clarified in the RTS. If both identity of the PSU and specific data of the single payment transaction needs to be technically combined to one “file”, the feasibility of the “dynamic linking” based solutions may be low. This is also an issue when the Issuer of payment service is different from the Issuer of Authentication mechanisms and not linked together.For card transactions the 3D Secure infrastructure provides a dynamic linking to the amount and the payee, for whatever authentication method the card issuer chooses to use (strong, weak or suppressed (risk-based)).
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
In general. Solutions with strong Foot-printing. When considering the detailed content of the « dynamic linking » main focus should be on functional linking of the independent security factors. See also answer to question 4.For card transactions the 3D Secure infrastructure provides a dynamic linking to the amount and the payee, for whatever authentication method the card issuer chooses to use (strong, weak or suppressed (risk-based).
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
YES. Clarifications including examples would be utmost useful. The examples listed as A, C and E are clear examples of when strong authentication should not have to be used on all cases.Example B gives rise to additional questions, such as how and on what ground white lists are collected and uses, and for which EBA should elaborate in the RTS:e.g:
• Could a white list be constituted (in part or in whole) of payees that the payer have payed to before, i.e. “passive collection” of white list? Possibly with an opportunity for the payer to delete payees from the list.
• Do a PSP using PSU generated white lists have to accept all payees that a PSU potentially would like to white list? Nordea’s view is that they PSP should not be required to accept all payees on the white list, it must be on the PSPs discretion, which payees and/or categories of payees that are eligible for the PSU to white list.
On example D, EBA states in paragraph 44 that it “currently observes in the market that the reliability of such analysis is closely related to the availability of sufficiently detailed information and history from both, the payer and payee.” Further, EBA states in paragraph 45 that it should be required “to be based on comprehensive real-time risk analysis taking into account (a) an adequate transaction history of that customer to evaluate the latter’s typical spending and behaviour patterns, (b) information about the customer device used (e.g. IP address, model, operating system, language preferences) and where applicable (c) a detailed risk profile of the payee (e.g. types of service provided, transaction history) and the payees device (where applicable).”
Nordea’s view is that this aggregation of information is almost impossible to accomplish in a the normal four-party model in which most payments are carried out. The PSP of the payer has relevant and valid information on the payer (at least if the PSP is also the ASPSP) but usually poor information on the payee, it could be the merchant’s name and a merchant’s category code, but the payer’s PSP of course lacks information about the transaction history of the payee. The other way around, the PSP of the payee has valid information about the payee, but lacks information about the payer, apart from any transaction history on this specific payee (and if the same payment instrument was used by that payer).
EBA should focus on elaborating the criteria under what circumstances risk-based analysis should be possible to be used by the payer’s PSP or the payee’s PSP, or both. For a card transaction, for example, if the PSP of the payee, the acquirer, together with the payee (merchant) decides to use a risk-based decision not to support strong authentication (i.e. 3D Secure infrastructure which enables the dynamic linking of the authentication method used by the issuer) for a specific transaction, the PSP of the payer, the issuer, does not get any possibility to do a risk-based decision of its own, the decision is already taken from the point of interaction. This strongly relates to the allocation of liability for fraudulent transactions, as provided by Article 74(2) in PSD2.
EBA should also make it clear in the RTS that it is up to each PSP to what extent the PSP uses the possible reasons for exemtions from the requirements on strong authentication. The RTS should specify what per maximum can be allowed as criteria for exemptions. Then the individual PSP may decide not to exercise this possibility at all, or to a lesser extent than possible (i.e. with stricter requirements than stated in the RTS for when the strong authentication is not prompted.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
With reference to question 19 and e-IDAS regulation the premise in the RTS should be that authentication requirements arising from PSD are not the same than the requirements arising from e-IDAS. Also the security levels defined in e-IDAS related standards have neither assessed nor decided in view of payment services. For this reason the methords or processes what are actual requirements of strong authentication in the PSD are not the same than in e-IDAS. PSD approach should be based merely on defintions in the PSD (i.e. two security factor approach). In practise this would mean that strong authentication which meets the e-IDAS requirements meet the requirements arising from PSD, but in addition to this there may also other methods which can be used for authentication of PSD related transactions.9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?
YES, e.g. detailed risk profile of the payer. Exploitation of payer’s or payee’s location data.10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
YES. It is obvious that right to initiate the payment through the PIS service will increase the vulnerability of the services e.g. due to risk of social engineering or lack of information. In order to response how to unify the protection towards different payment entities, standardization is crucial.11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
Personalized credentials should not be stored on 3rd party services and used by a 3rd party. Via an API we can offer the 3rd party a log in, without exposing the users personal security credentials for the 3rd party.Particularly in Nordic and Baltic countries service credentials are widely also used for strong identification against the third party series (e.g. public services). This kind of usage is segregated as an independt services which are implemented in line with national laws. In most of the countries current regulation expressly prohibits a customer to give service credentials anyone else than directly to contracting party (including PIS/AIS PSPs). Due to PIS/AIS service model national laws on strong identification need to be amended. Because these services are well established the accepted procedure how provide services via PIS and/or AIS services need to be analysed and RTS should acknowledled timelines needed for amendments of the current regulations.
Ensure that software components are adequately protected and do not comprise malware. Too complicated technology does not meet all business needs; there is a fear for very long implementation times.
12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?
Nordea has a chain of trust (Strong Authentication) that gives the opportunity for easy on boarding of new services including new authentication mechanisms. (see. e.g. Swedish Mobile BankID https://www.bankid.com/en/ )13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?
We prefer one global standard.Credit institutions are required to have in place a detailed IT security risk policy.
While third party certification may make sense in certain areas, any requirements for additional certification by third parties should take into account measures and requirements already in place.
If an approach is chosen where TPPs are allowed to access and transmit PSCs, steps should be taken to ensure an adequate security environment – which could include third party certification.
14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?
In general TPPs and their environments. At least following points in the chain should be taken into account.(a) Identification of the licensensed PSP. The primary problem is that how a PSU can make a distinction between the licensed PIS/AISPSP and fraudster. This is the point in the chain most likely subject to social engineering.
(b) PSU has no effective control over the factual exploitation of the service credentials in the PIS/AIS services. These risks related to PIS and/or AIS services are embedded into the business model as such not to the specific technology or defects in the regulation.
(c) Payment platformes exploited by the payee or payee’s PSP may be technically unsecure
15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?
YES.API standardization is key. Also governance related issues need to be taken into account.
16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?
For increased clarity sake, we would like to get a clear understanding of following:According to definitions and terminology of the PSD2 a PSU exploiting PIS or AIS services may also be a corporate customer using file transfer based payment services. Examples and arguments around the benefits of the PIS/AIS services are however only focused on consumer/private customer services.
It is utmost important to define in what extent the PIS/AIS services may or may not be exploited by the corporate customers. In case also file based payment services are included there should be standards also for the batch transfer services.
17. In your opinion, is there any standards (existing or in development) outlining aspects that could be common and open, which would be especially suitable for the purpose of ensuring secure communications as well as for the appropriate identification of PSPs taking into consideration the privacy dimension?
Nordea prefers global standard, e.g. ISO 20022. This should be subject to supervisor's further exhaustive analysis both from technical and business impact perspectives.Also, If the open and common secure standards are mandatory but include e.g. defects which cause security incident there should be clear liability regime to cover the damage of the ASPSP.
18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?
See answer to question 17. In any case APSPS right to decide on the accepted methods of authentication.19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.
Security standards of e-IDAS have not yet decided. In order to answer it should be decided what authentication level is required (Normal, substantial or high). Merely from service credential perspective we answer NO. Due to risk management requirements and business reasons it is at ASPSP's interest to decide which service credentials are acceptable for account accessing purposes.For the PIS/AIS PSP identification purposes e-IDAS may provide some benefits and additional security features. This should be however subject to further analysis related to e-IDAS standards.
20. Do you think in particular that the use of “qualified trust services” under e-IDAS regulation could address the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs? If yes, please identify which services and explain how. If no, please explain why.
See answer to question 19. In private services customer relatioship and electronic identification are often combined. It is more challenging to try to make a distinction between these two in private services. Also in many countries strong electronic identification data is forbidden to submit service credentials to any third party.When it comes to other e-IDAS services like “trusted sites” and “seals” they may be usefull for identification of licensed PSP or secure service site.