Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
From a legal point of view the wording in article 97(A) is not self-explanatory. This unclarity applies also to definitions 97(B) and 97(C). The definitions in article 97 have fundamental impact on the functional and technical requirements related to strong customer authentication. EBA should therefore identify and specify the processes or points in the payment chain where strong customer authentication is necessary, for example the procedures for changes in payment services, changes in geographic validity of cards, changes in payment limits, initiation of recurring transfer/payment which signs off on ensuing money transfers/payments and amendments in white or black lists or acceptance of electronic mandates. After these clarifications have been added the RTF will provide more clear guidance on which the processes/transactions are where strong customer authentications is required.
Minimum requirements on a two factor authentication mechanism should be defined. The importance of the Know Your Customer (KYC) process and origin identification should be considered and described.
It is essential that adding issuing of payment credentials" as an item where strong customer authentication is required. The requirement is valid both when issuing the original credentials and when re-issuing (new) credentials. The purpose is to prevent creating a weak link in the payment chain/flow, a link that is a prerequisite for a secure transaction. Also, there is probably a need for using strong authentication in a situation where the PSU orders the PIS to execute future and/or recurring payments. All payment orders, including immediate, future and recurring should thus be required to be subject to strong authentication.
Dynamically link: The EBA should provide requirements of the context in which the customer is authorizing the payment to enhance mitigation of real time phishing attacks. Dynamic link to amount and payee is not sufficient; it needs to be visible to the customer what is being signed.
The additional examples could the "issuing of payment credentials" as an item where strong customer authentication is required. The requirement is valid both when issuing the original credentials and when re-issuing (new) credentials. The purpose is to prevent creating a weak link in the payment chain/flow, a link that is a prerequisite for a secure transaction. Also, there is probably a need for using strong authentication in a situation where the PSU orders the PIS to execute future and/or recurring payments.
Article 63 Derogation for low value payment instruments and electronic money includes several exceptions regarding low value payments, but still requires strong customer authentication in accordance with Article 97 (1). The proposal is to evaluate one-factor authentication requirements for those payments. Otherwise, the payment chains (e.g., SMS based payments, NFC based payments widely used in public transport) based on one-factor authentication, will not meet new legal requirements. Article 97 doesn’t allow some basic access to the payment account such as a choice of specific account, check of available balance, currency, which is a crucial payment process part in any payment, including low-value payment.
PSP can use several risk minimizing services, such as immediate account notifications in the form of SMS or Push notification or real-time reply on customer request on Account Balance, allowing PSU to perform real-time account monitoring. The proposal is to allow some basic access to the payment account online without allowing the access to the new payment initiation or a payment instrument directly based on one-factor authentication in order to ensure PSU with real-time monitoring services.
The exception on lower-level authorization could be added for white-listed payers."
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 typically have a shorter life span and are 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 foot printed" by the software issuer. In practice this means, that the possession of the unique mobile device is necessary to make the authentication.
The possession elements can be in an electronic (data) form as well as a physical form which is hard to copy. Cards, mobile phones, specialized separate secure authentication and signing apps can all be appropriate examples of possession. The Nordic countries (Sweden, Finland, Norway and Denmark) represent some of the most developed digital countries in the World. The Nordic banking industry has developed eID solutions where possession elements consists of both physical elements like Chip Authentication Technology (CAP) solutions and electronic elements like apps. Both solutions have provided valuable experiences based on their ability to adapt to evolving threats (for example malware, identity theft, social engineering and DDOS), potential service development (for example instant payment schemes) and feedback from end users (citizens and customers).
The driver in this transition is digitalization in general and specifically end users’ behavior change. Customers and citizens appreciate and use electronic possession elements for strong customer authentication purposes to a larger extent than they do physical elements. The banking industry is constantly exploring fraud levels and has detected no difference between the use of physical elements and electronic elements for strong customer authentication. Electronic possession has increased flexibility for customers and citizens and has created an environment which is more conducive to digitalization for both public services and banking services for the end user.
To secure that the data is only controlled by the PSU it is vital to monitor mobile cyber threats like malware, identity theft, social engineering and DDOS etc. The app itself also needs to be protected and the below can function as input:
• Make sure it is your software that runs on the user device
• Protect against manipulation of apps and pirated apps
• Make sure no one spies on the conversation – you are going to send sensitive data, make sure no one can listen to it or change it
• Prevent theft of PIN – the user will enter his PIN into your app, make sure it is difficult to steal it
• Prevent remote control – make it difficult to remote control the app
• Protected storage – store your secrets securely, use the best the OS can provide, add your own layers
• Hardware binding – tie your app to the hardware, detect if anyone copies or moves credential
• Phone security level – detect the phones security level, prepare to require step-up authentication on attacked system types"
It is very important that these two areas are clearly separated: 1) what is required of an element to qualify as a strong customer authentication factor, and 2) what are the valid parameters to use in a risk-based decision not to require strong authentication. It is important to have clear discrepancy in definitions in the risk analysis between what strong authentication is and what low risk is. There are two main reasons for this:
• to understand the dynamics between the two in the practical implementation
• to understand the context of determining liabilities according to PSD2. When exemptions are used in compliance with the potential RTS that will allow risk analysis – and strong authentication is therefore not done on a transaction – the liability falls on the party not supporting strong authentication for the specific transaction
There are several ways to obtain the required security features of the mobile token app. The most central is to secure a strong hardware connection between the app and the mobile device. This is done during the initial enrolment process of the mobile token app.
Making the mobile device a true and independent “possession” element is about avoiding that the software token app can be migrated on to another mobile device. This means that the software is tied to the physical mobile device and therefore can be considered independent. The only condition is that the app is not storing the password “knowledge” element. This means that you cannot login if you get hold of the mobile device alone as you will also need to know the user id and password. Vice versa, it must also not be possible to download the mobile token app on another mobile device and using the name of another user if you know the user’s knowledge element (password).
By splitting crypto keys/certificates used in the authentication and signing process some parts are stored on the mobile inside the app and some parts are stored centrally on the host. This makes it very difficult to move the app to another mobile and get it operational.
Independence of authentication elements in mobile banking
• A software token authentication app is exposed to malware with the potential ability to intercept communication and compromise the security. Currently, there are no commercial authentication solutions (mobile or other) that cannot be tampered with by malware. As a consequence, security is focused on building adequate measure that minimizes and mitigates the risks. This is done by adding several security layers, for example:
• All communication between the apps and the host is encrypted. The app will only communicate to the host as the communication crypto key/certificate is pinned
• Complete separation of the mobile banking app from the mobile token app - i.e. two independent apps
• No direct communication on the mobile device between the two apps
• No app switching on the mobile via the mobile operating system
• Encrypted communication goes from the banking app to the host, from the host back to the mobile and pushes an authentication request to the mobile token app
• The mobile token app conducts the crypto mechanisms required in the authentication process through encrypted communication with the host and returns an “ok” or “not ok” to the authentication request
• The host sends the result to the banking app via encrypted communication
• Not allowing the banking app and the mobile token app to run on rooted/jailbroken mobile devices. This reduces the risk of having malware running on the mobile trying to intercept the banking session
• Sealing mechanisms built into the mobile token app can also protect the app from malware interference
• Additionally and on top of that there are several commercial solutions that can detect if malware is trying to intercept the session. Malware detection is also running on the host and issue alarms if malware is detected. Additionally, fraud monitoring and risk engines can stop any false events from being conducted if malware should succeed in bypassing all other measures.
• There are indications on what is likely to be seen in the future when it comes to the next level in securing mobile token apps running on mobile devices for mobile banking. Currently, most smartphones are equipped with so called Trusted Execution Environment (TEE) in the hardware. This will make it possible to step up security measures even further having the mobile token app running towards the TEE isolated and bypassing the mobile device’s operating system. This includes also the possibility to have a Trusted Display that cannot be reached from the mobile operating system. The mobile handset industry is working on identifying a commercial standard for this TEE and it is likely that this will be widely spread on the market within a couple of years."
• Currently, several security tokens (devices generating challenge/response OTPs) exist in the market and fulfill the dynamic linking requirement. But this type of devices has extremely low user acceptance and quite high production costs. In case of many PSPs would move to that specific type of tokens, the penetration of specific technology would increase and it could become more attractive target for any kind of attack.
• Is the usage of qualified electronic signatures to sign a specific transaction fits the requirements of dynamic link to the payee and a specific sum. A content of signed document gets fixed, so is it treated as dynamic linking with specific sum and a payee?
• How dynamic linking should work in case of inherence data element usage, e.g., password and fingerprint.
• The requirement to link a transaction with specific amount and payee definitely should protect a PSU, but would not allow to perform the approval of standing order or a multiply payment approval.
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).
• Can a white list consist (in part or in whole) of payees that the payer have payed to before, i.e. “passive collection”? Additionally, with an opportunity for the payer to delete payees from the list.
• Does a PSP using PSU-generated white lists have to accept all payees that a PSU would like to white list? Our opinion is that the PSP should not be required to accept all payees on the white list. This must be at the PSPs discretion, i.e. which payees and/or categories of payees that are eligible for the PSU to white list.
• Who is responsible if a white-listed merchant does not meet the necessary requirements set up by EBA?
• 42 (B) What level of authentications are required for initiating payments to white-listed recipients? What is the lower level of authentication required (passwords?). Should there be monetary limits for white-listed recipients, shared white-list for all payment instruments (cards, online banking, etc.)?
• General comments: Is the secure administration of white lists in scope for PSD2?
• 42 (E) Needs further explanations - non-sensitive payment data may very well be sensitive PII
In example 42 (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 behavior 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).”
A lack of detailed history of data from both the payer and payee will result in difficult assessments for all parties in the payment chain. The SBA’s view is that aggregation of this information is impossible to accomplish in a four-party model where most payments are carried out. The PSP of the payer has the necessary information on the payer (at least if the PSP is also the ASPSP) but little information on the payee. It could be the merchant name and a merchant category code, but the payer’s PSP lacks information about the payee´s transaction history. The other way around, the PSP of the payee has the necessary 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 consider and elaborate 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 exemptions from the requirements on strong authentication. The RTS should specify what maximum that can be allowed as criteria for exemptions. With this in place the individual PSP can decide not to exercise this possibility 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).
Finally, limits on contactless payments. The value in PSD2 is currently set at 30 euro, is this reasonable in the long run?
The RTS should define and include information and/or risk level indicator(s) related to the strong customer authentication mechanism used. This should be forwarded to the ASPSP as part of the communication. If the ASPSP considers the transaction as a high risk then it should be possible to request a step-up procedure.
PISP doesn’t need to have any agreement with PSP, the PSU should have an easy possibility (easy available register with good search function, mobile friendly) to check and track a legal aspect of any PISP.
Strong consideration and additional measurements and security requirements toward treating personal inherence data should be done. If constantly many PSP or PISP will provide inherence data based authentication means, PSU can face situation, when his inherence data is spread and available to the several issuer of authentication means. In case of usage of inherence data, the possibility to block a payment instrument is very limited. As far as fingerprint is the unique, not changeable, not revocable etc.
It is not clearly defined what the status is related to third parties’ using and storing of customers’ banking credentials. This should not be allowed since there are other ways to give third parties access without them knowing the credentials of the bank customer. More details must be provided in the RTS. For example, the issue regarding context is not discussed in the clarification paragraphs.
There is an inherent risk that the technology protecting the users’ personalized security credentials becomes too complicated as the payment chain changes. Therefore, it is important that each part in the payment chain identifies, carries and is responsible for their risk in that chain. A lack of common oversight of the payment chain can create problems for those parties under oversight and can push regulatory arbitrage which is a contradiction to the purpose of the DP. Personal security credentials should not be stored on third party service providers and used by third party service providers other than what is explicitly agreed by all parties.
There is a risk that the PSU doesn't understand the value of the security credentials if the enrolment is not managed properly and the PSU is not sufficiently informed. Information on new setup of payment chain and new role of PIS should be explained to the society.
Several of Sweden banks have a chain of trust (strong authentication) that gives the opportunity for easy on boarding of new services including new authentication mechanisms, see Mobile BankID: https://www.bankid.com/en/
• Identification of the licensed PSP. The main concern is how a PSU can make a distinction between the licensed PIS/AISPSP and a fraudster. This is the point in the payment chain which is most likely to be subject to social engineering
• PSU has no effective control over the factual exploitation of the service credentials in the PIS/AIS services. The risks related to PIS and/or AIS services are embedded into their business models and not connected to specific technology or legislation
• Payment platforms exploited by the payee or payee’s PSP may be technically insecure
• In the PIS and the AIS the risk increases due to current non-regulated situation where personal security credentials are visible to the PIS and AIS and there is no legal ground to prevent it
• Anti-money laundering part can suffer. User will be able to use payment services through PISP for a long-term, but PSP should ensure AML requirements? If PSP and ASP is the same entity, it should ensure infrastructure, but at the same time ensure Know you customer principle
• What is the vision on consumer protection regarding inherence data, for example, fingerprint. In case it’s compromised, what will be next step? It can’t be canceled or blocked etc.?
• Better conditions for Trojan attacks. Less possibility to differ a behavior between human taping and robot data input, the number of tool for issuer of security credentials becomes much smaller.
a) “Common and open” standards: a common definition would be welcome – as there are currently a range of definitions and interpretations available. Such definition should include a view on the required governance to evolve the standards concerned.
b) Identification of AIS and PIS providers towards ASPSPs for access: yes, including providing evidence that they are duly registered and regulated.
c) Secure communication between ASPSPs and PSUs, and AIS/PÏS providers: PKI architectures should be used.
d) Minimum functionalities requirements for the future common and secure open standards of communication: yes, and full automatization should be included as minimum.
e) Minimum security controls: there should be 3 layers of security controls:
- The PSU should be able to verify that he gives consent to a registered and regulated AIS/PIS provider;
- The AIS/PIS provider should be able to verify that he deals with a genuine PSU.
- The ASPSP should be able to verify automatically that any request originates from a registered and regulated AIS/PIS provider, on behalf (i.e. with the express consent of) a genuine PSU. The ASPSP should be able to reject any request that i.a. does not meet this test.
f) Minimum technical requirements for the common and secure open standards of communication: a wide range of market solutions already exist to supporting such secure communication. For due reasons interoperability is required. It can however not be expected that all existing solutions become interoperable with each other. For practicality yet mostly for cost efficiency purposes EBA should the requirements for a small (e.g. 3) set of default secure communication standards, for interoperability purposes. Such approach would support channel independence and allow for the gradual introduction of innovations.
The PSU should be able to see the context (information/services and identity of the PIS/AIS) through the PSPs personal security credential solution if the PSP so choses. This in order to avoid situations where the PSU is tricked by the PIS/AIS without understanding which information/services the PSU expose.
Not only innovation, but also market continuity is to be enabled. The RTS thus should specify a small range (e.g. 3) of communication protocols, how ASPSPs and AIS/PIS providers will identify themselves and how they will be authenticated, and a set of generic request, response and authentication messages. On the basis of the RTS market players will have to work on implementation guidelines in order to over time achieve full interoperability.
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. There are a small number of well accepted market solutions in Europe which leverage the PKI architecture and which would continue to be used by AIS/PIS providers. Work on interoperability between these solutions should be encouraged.
Use of an API - ensures encrypted communication and it´s adaptable to be used to innovative business models mentioned under Article 66 and 67.
For the PIS/AIS/PSP identification purposes e-IDAS may provide some benefits and additional security features. However, this should be subject to further analysis related to the e-IDAS standards.
When it comes to other e-IDAS services like “trusted sites” and “seals” they may be useful for identification of licensed PSP, PISP, AISP, ASP or secure service site.
It is up to the e-IDAS regulator to take responsibility and guarantee the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs
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.
The scope of article 97 has direct impact to PSPs production costs and requirements related to achieving a level playing field between the service providers. Therefore, the clarity of the definitions and the scope of article 97 are very important.From a legal point of view the wording in article 97(A) is not self-explanatory. This unclarity applies also to definitions 97(B) and 97(C). The definitions in article 97 have fundamental impact on the functional and technical requirements related to strong customer authentication. EBA should therefore identify and specify the processes or points in the payment chain where strong customer authentication is necessary, for example the procedures for changes in payment services, changes in geographic validity of cards, changes in payment limits, initiation of recurring transfer/payment which signs off on ensuing money transfers/payments and amendments in white or black lists or acceptance of electronic mandates. After these clarifications have been added the RTF will provide more clear guidance on which the processes/transactions are where strong customer authentications is required.
Minimum requirements on a two factor authentication mechanism should be defined. The importance of the Know Your Customer (KYC) process and origin identification should be considered and described.
It is essential that adding issuing of payment credentials" as an item where strong customer authentication is required. The requirement is valid both when issuing the original credentials and when re-issuing (new) credentials. The purpose is to prevent creating a weak link in the payment chain/flow, a link that is a prerequisite for a secure transaction. Also, there is probably a need for using strong authentication in a situation where the PSU orders the PIS to execute future and/or recurring payments. All payment orders, including immediate, future and recurring should thus be required to be subject to strong authentication.
Dynamically link: The EBA should provide requirements of the context in which the customer is authorizing the payment to enhance mitigation of real time phishing attacks. Dynamic link to amount and payee is not sufficient; it needs to be visible to the customer what is being signed.
The additional examples could the "issuing of payment credentials" as an item where strong customer authentication is required. The requirement is valid both when issuing the original credentials and when re-issuing (new) credentials. The purpose is to prevent creating a weak link in the payment chain/flow, a link that is a prerequisite for a secure transaction. Also, there is probably a need for using strong authentication in a situation where the PSU orders the PIS to execute future and/or recurring payments.
Article 63 Derogation for low value payment instruments and electronic money includes several exceptions regarding low value payments, but still requires strong customer authentication in accordance with Article 97 (1). The proposal is to evaluate one-factor authentication requirements for those payments. Otherwise, the payment chains (e.g., SMS based payments, NFC based payments widely used in public transport) based on one-factor authentication, will not meet new legal requirements. Article 97 doesn’t allow some basic access to the payment account such as a choice of specific account, check of available balance, currency, which is a crucial payment process part in any payment, including low-value payment.
PSP can use several risk minimizing services, such as immediate account notifications in the form of SMS or Push notification or real-time reply on customer request on Account Balance, allowing PSU to perform real-time account monitoring. The proposal is to allow some basic access to the payment account online without allowing the access to the new payment initiation or a payment instrument directly based on one-factor authentication in order to ensure PSU with real-time monitoring services.
The exception on lower-level authorization could be added for white-listed payers."
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?
Authentication elements can be data elements and a link with a physical device with the PSU’s adequate control of the device, platform or software used. A requirement for a physical possession of the authentication element will impact service development. Instead of focusing on dedicated devices or tokens, the RTS should focus on generic security factors of the authentication and not limit the 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 typically have a shorter life span and are 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 foot printed" by the software issuer. In practice this means, that the possession of the unique mobile device is necessary to make the authentication.
The possession elements can be in an electronic (data) form as well as a physical form which is hard to copy. Cards, mobile phones, specialized separate secure authentication and signing apps can all be appropriate examples of possession. The Nordic countries (Sweden, Finland, Norway and Denmark) represent some of the most developed digital countries in the World. The Nordic banking industry has developed eID solutions where possession elements consists of both physical elements like Chip Authentication Technology (CAP) solutions and electronic elements like apps. Both solutions have provided valuable experiences based on their ability to adapt to evolving threats (for example malware, identity theft, social engineering and DDOS), potential service development (for example instant payment schemes) and feedback from end users (citizens and customers).
The driver in this transition is digitalization in general and specifically end users’ behavior change. Customers and citizens appreciate and use electronic possession elements for strong customer authentication purposes to a larger extent than they do physical elements. The banking industry is constantly exploring fraud levels and has detected no difference between the use of physical elements and electronic elements for strong customer authentication. Electronic possession has increased flexibility for customers and citizens and has created an environment which is more conducive to digitalization for both public services and banking services for the end user.
To secure that the data is only controlled by the PSU it is vital to monitor mobile cyber threats like malware, identity theft, social engineering and DDOS etc. The app itself also needs to be protected and the below can function as input:
• Make sure it is your software that runs on the user device
• Protect against manipulation of apps and pirated apps
• Make sure no one spies on the conversation – you are going to send sensitive data, make sure no one can listen to it or change it
• Prevent theft of PIN – the user will enter his PIN into your app, make sure it is difficult to steal it
• Prevent remote control – make it difficult to remote control the app
• Protected storage – store your secrets securely, use the best the OS can provide, add your own layers
• Hardware binding – tie your app to the hardware, detect if anyone copies or moves credential
• Phone security level – detect the phones security level, prepare to require step-up authentication on attacked system types"
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, the functionality and reliability of behavior-based characteristics as a method in the context of strong customer authentication needs to be verified. We consider that behavior does not qualify for inherence as it is not strong enough to be considered as a strong authentication element by its own right. The use of behavior-based characteristics is valid for increasing the strength of a strong authentication element, for example typing patterns can be used to strengthen the use of PIN. The use of behavior-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.It is very important that these two areas are clearly separated: 1) what is required of an element to qualify as a strong customer authentication factor, and 2) what are the valid parameters to use in a risk-based decision not to require strong authentication. It is important to have clear discrepancy in definitions in the risk analysis between what strong authentication is and what low risk is. There are two main reasons for this:
• to understand the dynamics between the two in the practical implementation
• to understand the context of determining liabilities according to PSD2. When exemptions are used in compliance with the potential RTS that will allow risk analysis – and strong authentication is therefore not done on a transaction – the liability falls on the party not supporting strong authentication for the specific transaction
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 challenges in combining customer and security needs particularly in multipurpose devices used via multichannel communication. From a security perspective, isolation of the authentication application needs to be separated and secured apart from the “generic” mobile apps. The generic nature of the device may lead to weak foot printing" of the device from the issuer of the authentication elements. There are no formal requirements for foot printing of a device from a technical perspective and it would be positive if there were. The architecture in all devices are also different which provides challenges as well as setting the appropriate definition of strong customer authentication method for the various devices/tools being used. A governance model for assurance of the level of security level achieved will too be required.There are several ways to obtain the required security features of the mobile token app. The most central is to secure a strong hardware connection between the app and the mobile device. This is done during the initial enrolment process of the mobile token app.
Making the mobile device a true and independent “possession” element is about avoiding that the software token app can be migrated on to another mobile device. This means that the software is tied to the physical mobile device and therefore can be considered independent. The only condition is that the app is not storing the password “knowledge” element. This means that you cannot login if you get hold of the mobile device alone as you will also need to know the user id and password. Vice versa, it must also not be possible to download the mobile token app on another mobile device and using the name of another user if you know the user’s knowledge element (password).
By splitting crypto keys/certificates used in the authentication and signing process some parts are stored on the mobile inside the app and some parts are stored centrally on the host. This makes it very difficult to move the app to another mobile and get it operational.
Independence of authentication elements in mobile banking
• A software token authentication app is exposed to malware with the potential ability to intercept communication and compromise the security. Currently, there are no commercial authentication solutions (mobile or other) that cannot be tampered with by malware. As a consequence, security is focused on building adequate measure that minimizes and mitigates the risks. This is done by adding several security layers, for example:
• All communication between the apps and the host is encrypted. The app will only communicate to the host as the communication crypto key/certificate is pinned
• Complete separation of the mobile banking app from the mobile token app - i.e. two independent apps
• No direct communication on the mobile device between the two apps
• No app switching on the mobile via the mobile operating system
• Encrypted communication goes from the banking app to the host, from the host back to the mobile and pushes an authentication request to the mobile token app
• The mobile token app conducts the crypto mechanisms required in the authentication process through encrypted communication with the host and returns an “ok” or “not ok” to the authentication request
• The host sends the result to the banking app via encrypted communication
• Not allowing the banking app and the mobile token app to run on rooted/jailbroken mobile devices. This reduces the risk of having malware running on the mobile trying to intercept the banking session
• Sealing mechanisms built into the mobile token app can also protect the app from malware interference
• Additionally and on top of that there are several commercial solutions that can detect if malware is trying to intercept the session. Malware detection is also running on the host and issue alarms if malware is detected. Additionally, fraud monitoring and risk engines can stop any false events from being conducted if malware should succeed in bypassing all other measures.
• There are indications on what is likely to be seen in the future when it comes to the next level in securing mobile token apps running on mobile devices for mobile banking. Currently, most smartphones are equipped with so called Trusted Execution Environment (TEE) in the hardware. This will make it possible to step up security measures even further having the mobile token app running towards the TEE isolated and bypassing the mobile device’s operating system. This includes also the possibility to have a Trusted Display that cannot be reached from the mobile operating system. The mobile handset industry is working on identifying a commercial standard for this TEE and it is likely that this will be widely spread on the market within a couple of years."
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
The concept of “dynamic linking” could be a good additional layer of the security and the main reason and objective behind is very clear, but it can have some limitations or potential business restrictions.• Currently, several security tokens (devices generating challenge/response OTPs) exist in the market and fulfill the dynamic linking requirement. But this type of devices has extremely low user acceptance and quite high production costs. In case of many PSPs would move to that specific type of tokens, the penetration of specific technology would increase and it could become more attractive target for any kind of attack.
• Is the usage of qualified electronic signatures to sign a specific transaction fits the requirements of dynamic link to the payee and a specific sum. A content of signed document gets fixed, so is it treated as dynamic linking with specific sum and a payee?
• How dynamic linking should work in case of inherence data element usage, e.g., password and fingerprint.
• The requirement to link a transaction with specific amount and payee definitely should protect a PSU, but would not allow to perform the approval of standing order or a multiply payment approval.
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?
Several MobileID solutions (MobileID in Estonia, Mobile BankID in Sweden etc.) fulfil both the objective of independence and dynamic linking. Solutions with strong foot-printing currently fulfil both the objective of independence and dynamic linking. When considering the detailed content of the dynamic linking the main focus should be on functional linking of the independent security factors.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Yes, clarifications including examples would be very useful. The clarifications seem adequate if low risk (value) payments are included and defined. The examples listed as 42(A), 42(C) and 42(E) is good examples when strong authentication should not have to be used consistently. Example 42(B) raises additional questions, such as how and on what ground white lists are collected and applied. It would be beneficial if EBA can elaborate on this in the RTS, for example:• Can a white list consist (in part or in whole) of payees that the payer have payed to before, i.e. “passive collection”? Additionally, with an opportunity for the payer to delete payees from the list.
• Does a PSP using PSU-generated white lists have to accept all payees that a PSU would like to white list? Our opinion is that the PSP should not be required to accept all payees on the white list. This must be at the PSPs discretion, i.e. which payees and/or categories of payees that are eligible for the PSU to white list.
• Who is responsible if a white-listed merchant does not meet the necessary requirements set up by EBA?
• 42 (B) What level of authentications are required for initiating payments to white-listed recipients? What is the lower level of authentication required (passwords?). Should there be monetary limits for white-listed recipients, shared white-list for all payment instruments (cards, online banking, etc.)?
• General comments: Is the secure administration of white lists in scope for PSD2?
• 42 (E) Needs further explanations - non-sensitive payment data may very well be sensitive PII
In example 42 (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 behavior 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).”
A lack of detailed history of data from both the payer and payee will result in difficult assessments for all parties in the payment chain. The SBA’s view is that aggregation of this information is impossible to accomplish in a four-party model where most payments are carried out. The PSP of the payer has the necessary information on the payer (at least if the PSP is also the ASPSP) but little information on the payee. It could be the merchant name and a merchant category code, but the payer’s PSP lacks information about the payee´s transaction history. The other way around, the PSP of the payee has the necessary 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 consider and elaborate 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 exemptions from the requirements on strong authentication. The RTS should specify what maximum that can be allowed as criteria for exemptions. With this in place the individual PSP can decide not to exercise this possibility 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 the e-IDAS regulation the premise in the RTS should be that authentication requirements arising from PSD2 are not the same as the requirements arising from e-IDAS. Also, the security levels defined in e-IDAS have neither been assessed nor decided regarding payment services. For this reason the methods or processes and actual requirements of strong authentication in PSD2 are not the same as in e-IDAS. The PSD2 approach should be based merely on definitions in the PSD2 (i.e. two security factor approaches). In practice this would mean that strong authentication which meets the e-IDAS requirements meet the requirements arising from PSD2. In addition to this there may also be other methods which can be used for authentication of PSD2 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, for example 1) a detailed risk profile of the payer, 2) exploitation of payer’s or payee’s location data and, 3) behavior-based characteristics.Finally, limits on contactless payments. The value in PSD2 is currently set at 30 euro, is this reasonable in the long run?
The RTS should define and include information and/or risk level indicator(s) related to the strong customer authentication mechanism used. This should be forwarded to the ASPSP as part of the communication. If the ASPSP considers the transaction as a high risk then it should be possible to request a step-up procedure.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Yes, clarification should and how PSP can ensure the protection of data in case of PISP involvement? Article 67 (b) says, the PASP ensure the personalized security credentials are not accessible to the other parties and are transmitted through safe and efficient channel, but at the same time the Article 66 (3) (b) says, PISP can transmit that data also through safe and efficient channel. So, that means PASP can’t ensure and be responsible for the data at the moment when PSU communicates with PISP. So, there is needed a shift of liability and explanation. The right to initiate a payment through the PIS service will increase the vulnerability of the services e.g. due to risk of social engineering or lack of information. To protect different payment entities standardization is crucial and it is also important to implement a standard governance model including a corresponding certification process.PISP doesn’t need to have any agreement with PSP, the PSU should have an easy possibility (easy available register with good search function, mobile friendly) to check and track a legal aspect of any PISP.
Strong consideration and additional measurements and security requirements toward treating personal inherence data should be done. If constantly many PSP or PISP will provide inherence data based authentication means, PSU can face situation, when his inherence data is spread and available to the several issuer of authentication means. In case of usage of inherence data, the possibility to block a payment instrument is very limited. As far as fingerprint is the unique, not changeable, not revocable etc.
It is not clearly defined what the status is related to third parties’ using and storing of customers’ banking credentials. This should not be allowed since there are other ways to give third parties access without them knowing the credentials of the bank customer. More details must be provided in the RTS. For example, the issue regarding context is not discussed in the clarification paragraphs.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
The highest risk if a possibility to perform phishing services and low protection of consumer. Consumer can provide security credentials’ data to the PISP or fake PISP, e.g., fingerprint, and relies on it. Attacks can become much more scalable, so consumer protection mechanism should be analyzed. New attacks against PISP could appear.There is an inherent risk that the technology protecting the users’ personalized security credentials becomes too complicated as the payment chain changes. Therefore, it is important that each part in the payment chain identifies, carries and is responsible for their risk in that chain. A lack of common oversight of the payment chain can create problems for those parties under oversight and can push regulatory arbitrage which is a contradiction to the purpose of the DP. Personal security credentials should not be stored on third party service providers and used by third party service providers other than what is explicitly agreed by all parties.
There is a risk that the PSU doesn't understand the value of the security credentials if the enrolment is not managed properly and the PSU is not sufficiently informed. Information on new setup of payment chain and new role of PIS should be explained to the society.
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?
No real innovative solutions, but there is important to remember, if the full set of security credentials is issued to the user, or there is a replacement of one element not compromising another. Possible channels: Post, SMS, stand-alone disconnected device.Several of Sweden banks have a chain of trust (strong authentication) that gives the opportunity for easy on boarding of new services including new authentication mechanisms, see 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?
No, certification should be a global standard. Otherwise the whole concept of TPPs access to account becomes chaotic. The TPPs should be regularly audited and certified according to mandated rules and regulations from approved authorities. e.g. ISAE3402, PCI DSS. The applicable rules should apply to all parties involved; i. e. AIS and PIS should be certified in the same way as the ASPSP. To secure a level playing field AIS and PIS should be certified at and on the same level.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, additional layers drive complexity and reduce control, for example third parties and their environments. The highest risk/threat segment will likely be a moving target and the weakest link in the chain will change over time. The following points in the payment chain should be taken into account when EBA develops the RTS:• Identification of the licensed PSP. The main concern is how a PSU can make a distinction between the licensed PIS/AISPSP and a fraudster. This is the point in the payment chain which is most likely to be subject to social engineering
• PSU has no effective control over the factual exploitation of the service credentials in the PIS/AIS services. The risks related to PIS and/or AIS services are embedded into their business models and not connected to specific technology or legislation
• Payment platforms exploited by the payee or payee’s PSP may be technically insecure
• In the PIS and the AIS the risk increases due to current non-regulated situation where personal security credentials are visible to the PIS and AIS and there is no legal ground to prevent it
• Anti-money laundering part can suffer. User will be able to use payment services through PISP for a long-term, but PSP should ensure AML requirements? If PSP and ASP is the same entity, it should ensure infrastructure, but at the same time ensure Know you customer principle
• What is the vision on consumer protection regarding inherence data, for example, fingerprint. In case it’s compromised, what will be next step? It can’t be canceled or blocked etc.?
• Better conditions for Trojan attacks. Less possibility to differ a behavior between human taping and robot data input, the number of tool for issuer of security credentials becomes much smaller.
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:a) “Common and open” standards: a common definition would be welcome – as there are currently a range of definitions and interpretations available. Such definition should include a view on the required governance to evolve the standards concerned.
b) Identification of AIS and PIS providers towards ASPSPs for access: yes, including providing evidence that they are duly registered and regulated.
c) Secure communication between ASPSPs and PSUs, and AIS/PÏS providers: PKI architectures should be used.
d) Minimum functionalities requirements for the future common and secure open standards of communication: yes, and full automatization should be included as minimum.
e) Minimum security controls: there should be 3 layers of security controls:
- The PSU should be able to verify that he gives consent to a registered and regulated AIS/PIS provider;
- The AIS/PIS provider should be able to verify that he deals with a genuine PSU.
- The ASPSP should be able to verify automatically that any request originates from a registered and regulated AIS/PIS provider, on behalf (i.e. with the express consent of) a genuine PSU. The ASPSP should be able to reject any request that i.a. does not meet this test.
f) Minimum technical requirements for the common and secure open standards of communication: a wide range of market solutions already exist to supporting such secure communication. For due reasons interoperability is required. It can however not be expected that all existing solutions become interoperable with each other. For practicality yet mostly for cost efficiency purposes EBA should the requirements for a small (e.g. 3) set of default secure communication standards, for interoperability purposes. Such approach would support channel independence and allow for the gradual introduction of innovations.
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?
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 important to define to what extent the PIS/AIS services may or may not be exploited by the corporate customers. If file based payment services are included there should also be standards for the batch transfer services.The PSU should be able to see the context (information/services and identity of the PIS/AIS) through the PSPs personal security credential solution if the PSP so choses. This in order to avoid situations where the PSU is tricked by the PIS/AIS without understanding which information/services the PSU expose.
Not only innovation, but also market continuity is to be enabled. The RTS thus should specify a small range (e.g. 3) of communication protocols, how ASPSPs and AIS/PIS providers will identify themselves and how they will be authenticated, and a set of generic request, response and authentication messages. On the basis of the RTS market players will have to work on implementation guidelines in order to over time achieve full interoperability.
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?
No, most federated solutions deals with identification, not providing context for transactions.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. There are a small number of well accepted market solutions in Europe which leverage the PKI architecture and which would continue to be used by AIS/PIS providers. Work on interoperability between these solutions should be encouraged.
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)?
We would submit that for the period until the planned review of PSD2, the transposition of the latter’s new dispositions whilst maintaining customer confidence and system efficiency already constitutes a significant challenge – “other innovative business models” could be contemplated at a later stage.Use of an API - ensures encrypted communication and it´s adaptable to be used to innovative business models mentioned under Article 66 and 67.
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.
Currently it can’t be basis or mandatory part included to the strong authentication requirements and/or communication. The e-IDAS Regulation has been drafted with mainly government services in mind, most of its definitions and dispositions could be applied to the development of market services, where identities would be issued by PSD2 registered and regulated market participants within own schemes or joint schemes with government authorities (processes may however need to be adapted to the realities and obligations of a primarily commercial environment).For the PIS/AIS/PSP identification purposes e-IDAS may provide some benefits and additional security features. However, this should be subject to further analysis related to the 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.
Yes, it could address authentication and communication part, but as not mandatory part. Mutual recognition of schemes includes high costs, which could destroy small business models and would over complicate a payment market.When it comes to other e-IDAS services like “trusted sites” and “seals” they may be useful for identification of licensed PSP, PISP, AISP, ASP or secure service site.
It is up to the e-IDAS regulator to take responsibility and guarantee the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs