Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
It is important to recognise that risks stemming from data breaches are wider than payment fraud – and that banks are legally obliged to protect not only the funds but also the data of their customers. Data which can be used for e.g. identity theft (e.g. through obtaining access to authentication credentials through other channels) should also be protected.
Furthermore, as a logical consequence of the technological development and the decreased importance of bank branches, web- and mobile-banking portals are increasingly used as the main channel of interaction between banks and their customers. Hence, the RTS should recognise this development – and take into account that further functionalities are likely to be added to these portals over time – potentially giving rise to a need to re-evaluate which services do and do not require SCA.
In addition to the items requiring SCA listed in para 27. iii, we would add:
• Any secure communication between PSP and PSU
• Any change of security levels, PINs or other characteristics in pay-ment instruments already issued to the PSU
• Application and/or enrolment for new payment instruments, authentication tools or other
• Changes to PSU personal data (address, mail, phone no, etc).
• Entering into mandates regarding direct debit products, recurrent payments, standing orders or the like, which we do not think should fall under article 97(1) (b) – see further under question 5
The trick is to ensure that a. only the user can access the possession ele-ment; having the mobile device is not enough (which means no storage of passwords) and b. the possession element cannot be migrated to another mobile device and is tied to the physical mobile device.
There are several ways to obtain this feature of a mobile token app. Most central is to make a strong hardware binding between the app and the mobile device. This is done during the initial enrolment process of the mobile token app, which should also require SCA.
A further consideration is to split crypto keys/certificates used in the au-thentication and signing process, storing some on the mobile inside the app and some centrally on the host. This makes it very difficult to move an already hardware-bound app to another mobile and get it to work.
See further under question 4.
Behaviour-based characteristics thus have the potential to fill the role as the inherence element in strong customer authentication. Depending on the implementation and deployment scenario it can either fulfil this role alone or together with other inherence elements. However, the technology may (as yet) be too immature to be considered as an independent element in SCA – although the day will come where this is possible. Furthermore, behaviour-based characteristics can only be used when the PSP has adequate history of interaction with the PSU which enables it to identify such characteristics – meaning that it cannot, in the nature of things, be used e.g. when initially signing up the PSU.
Hence, it should not be the only indicator that is used but used together with other indicators and/or authentication measures it is a very effective tool and should not be dismissed.
The use of behaviour-based characteristics in a risk-based security approach potentially gives rise to particular challenges when PISPs and AISPs are involved.
If sharing of PSCs is allowed under the RTS, we fear that future security developments are at risk. Such a set-up relies on log-in credentials being static and assumes that online banking security measures are only those that meet the eye. This is not always the case – as the use of behaviour-based characteristics illustrate.
PSPs must also be allowed to add further security measures as they see fit in order to meet new threats to their services. Depending on the threat at hand, adding new measures may even be a very urgent matter in order to minimize the impact of criminal activities.
Adding new measures may, however, in turn impede the ability of PISPs and AISPs to provide their services, if this includes changing the authentication mechanism around which their services is tailored. Hence, when considering the future set-up for AS PSP-TTP interaction, such a dependence should be avoided.
We strongly agree that independence between authentication elements is a key characteristic of a well-designed authentication mechanism. Hence we believe a restrictive requirement of independence (device and channel) should only be required for very high risk transactions. As mentioned above, we do believe that it is possible to have adequate security around a software solution, making e.g. a mobile device a true and independent possession element even when also using the mobile device to initiate the payment.
When performing mobile banking and authentication on the same mobile device (e.g. through a software token authentication app), there is obviously a risk of that malicious software on the mobile can intercept and compromise the security. However, to our mind, there are no commercial authentication solutions (mobile or not) that cannot be tampered by malware. So the key is to build in adequate measure that minimise the risks.
On current mobile token app solutions, several security layers can be added to ensure the necessary independence between payment and authentication:
• 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
• Total separation of the mobile banking app from the mobile token app - i.e. two truly independent apps
• No direct communication on the mobile device between the two apps
• No app switching on the mobile via the mobile operating system
• Not allowing the banking app and mobile token app to run on rooted/jailbroken mobile devices. This reduces the risk for having malicious software running on the mobile trying to intercept the banking session
• Sealing mechanisms build into the mobile token app can also protect the app from malware interference
As regards the workflow, it could be set up as follows:
• Encrypted communication goes from the banking app to the host, from the host to back to the mobile and pushes an authentication request to the mobile token app.
• The mobile token app does the crypto mechanisms needed in the authentication process in encrypted communication with the host and returns an 'ok' or 'not ok' on the authentication request to the host
• The host sends the result to the banking app via encrypted communication.
This could be augmented by solutions that can detect if malware is trying to intercept the session, by malware detection running on the host and by fraud monitoring and risk engines which ultimately can stop any false events from being conducted if malware should succeed in bypassing all other measures.
These solutions are already available today, and fraud levels in the Nordics, where mobile token apps have been in use 2-3 years, are negligible. While risk levels will increase as mobile payments are increasingly used, our view is that there are currently adequate countermeasures.
In the medium term (2-3 years), the next level in securing mobile token apps running on mobile devices for mobile banking should appear. Already today all high-end smartphones have built in so called Trusted Execution Environment (TEE) in the hardware. This will make it possible to step up security to next level with 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 cooperating about a commercial standard for this Trusted Execution Environment and we can expect this to get wider spread on the market within the coming years.
Dynamic linking can be perceived in (at least) two ways:
• Linking the users’ intent with the transaction content through explicitly requiring the user to enter amount and payee information into a transaction token generation device
• Linking the users’ intent with the transaction content by ensuring the end-to-end integrity of the transaction content from WYSIWYS to transaction processing through ensuring that authentica-tion/validation codes are unique and cannot be reused for other transactions
In our view, the latter interpretation is superior as it is technology and process neutral and does not limit future technological evolution of authentication measures and does not, in effect, tie the PSU to a token device. Such a device would severely negatively impact the user experience with the risk of mobile payments becoming too complicated to be used. This interpretation would also meet the goal set out in para. 34 of the DP: “to ensure that the authentication value used for a remote transaction can neither be used for any other purpose than originally intended by the payer nor be re-used if it is disclosed”.
We are also aware, however, that the aim of dynamic linking could be to ensure that the PSU is always aware of and have agreed to the specific amount and the specific payee, even if the PSU cannot observe the banking interface/browser/app through which the transaction is initiated (when payment occurs through a third party as known from some PISPs today).
If this is the interpretation intended from legislators, we again think it is important to allow transaction signing to occur on the same device used for the payment initiation as set out under questions 2 and 4.
In any event, the introduction of dynamic linking potentially has huge economic consequences should it be rolled out across the hundreds of millions bank customers in the EU, which should also be taken into consideration when deciding on the preferred interpretation.
Two further issues related to dynamic linking should be mentioned here:
First of all and in relation to the discussion in para 35 of the DP, we do not believe that dynamic linking should be applied, on a transactional basis, to direct debits, recurrent card payments and recurrent credit transfers. As described above, entering into mandates or agreements pertaining to such payments should be subject to SCA – but the single payments should not be subject to dynamic linking (in particular if it is the first interpretation of dynamic linking that is chosen).
Secondly, and again in particular if the more strenuous approach to dynamic linking is chosen, the definition of a “remote payment transaction” seems to give rise to some problems. A remote payment transaction is defined as “a payment transaction initiated via internet or through a device that can be used for distance communication”, while a means of distance communication is defined as “a method which, without the simultaneous physical presence of the payment service provider and the payment service user, may be used for the conclusion of a payment services contract” (from the PSD text, our emphasis). Hence, as the definition only requires that the device “can be” (not necessarily “is”) used at a distance, this would also seem to capture situations where a payment card is registered in a wallet on a mobile phone and this is used for e.g. contactless payment at a POS.
Thus, paying by plastic card at a POS would not require dynamic linking, paying by the same card stored on a mobile phone would require dynamic linking (and potentially confirming the transaction through a separate device, depending on which interpretation is chosen) which to the PSU would obviously be quite confusing and would almost certainly limit the move towards such convenient wallet solutions.
Even the best authentication system will not protect users from social engineering, and authentication thus needs to be augmented by a dynamic risk approach and the possibility to scale security requirements to the risk of the payment; see further below.
As mentioned above, we believe that payments carried out under a specific mandate from the PSU to the PSP (be it direct debits, standing orders or recurring card payments) should not be subject to SCA on a transactional basis but as and when the agreement or mandate is concluded, as it is also made clear in the EBA Guidelines for the Security of Internet Payments, para 7.1 – and just as is the case for payments to trusted beneficiaries.
In addition to PSU-specific whitelists, the setting up of national whitelists could be considered – e.g. payments to mortgage accounts, tax authorities or other such trusted and often used payees.
In accordance with the need to allow PSPs to adjust security requirements to the risks involved, banks adjust security requirements according to the risks and user situation at hand, ensuring a proper balance between convenience and security. In Denmark, this e.g. typically implies that security requirements for only viewing accounts on mobile applications (“account peep”) are less stringent (e.g. no SCA but only one-factor authentication) than for accessing web banks, setting up direct debits or initiating payments.
Furthermore, there is a strong need to ensure that customers are not confused by an uneven application of security across channels or transaction types. The current regulatory regime has e.g. created an environment where a payment initiated through the browser on a mobile phone requires SCA, while the same payment on the same mobile phone initiated via an app would not necessarily require SCA.
Customer behaviour patterns should include date, time, duration and geography. The overall threat landscape should also be taken into consideration when quantifying transaction risk (current technology of threats, current geography of threats, fraud patterns etc.)
The risk analysis could also incorporate e.g. PSP or national white lists (e.g. payments to tax authorities etc) and PSP, national or international black lists (e.g. payments to known mule accounts or other fraudulent accounts).
While we fully recognise the aim of the PSD2 to introduce innovation and competition through third parties (TPPs"), the presence of third parties may introduce an unfortunate link between these and AS PSPs. The latter must not be impeded in their ability to counter criminal activities or to evolve their security measures. In particular, in the words of the Danish Payments Council, basically, “the security of payer authentication should not depend on whether a third party is involved”:
While this section of the DP does not mention TPPs specifically, we think it is important to consider these here. Our key area of concern is business models relying on the consumer handing over their personal banking log-in credentials to the third party (“screen-scraping” or “credential sharing”).
Banks, the public sector and other providers of online services have spent a long time educating users that personal log-in credentials are personal and that handing them over to third parties involves significant risks. This principle is also enshrined in both the previous and new Payment Services Directive. In Denmark, the risks of handing over one’s credentials are even larger, as log-in to banks’ online banking portals occurs through the use of NemID – a public-private co-operation which also allows users to access a large number of public services (including tax reporting, health files, changing one’s address etc) – and other private services in need of proper user authentication and digital signing of binding transactions. Hence, if NemID is compromised, it is not only the bank account that is at risk – but the consumers’ entire digital identity.
While we recognise that the aim may have been for the PSD to allow cre-dential sharing (and this is not entirely clear from the PSD text as it stands), we believe there are technical alternatives that at the same time allows AISPs and PISPs to deliver their services, reduce inherent risks in the screen-scraping business model and ensure that PSUs are left in full control of which data they wish to share with certain third parties. On top of this, an added benefit is a clearer liability regime, which in particular does not leave the AS PSP with “residual liability” for situations over which it does not have control. Hence, from a public policy point of view, not only a narrow AS PSP point of view, we see strong arguments for considering an API approach.
Summing up, the API approach:
• Does not necessarily rely on credential sharing
• Leaves the PSU in full control over which data to share
• Solves the problem of PSU consent and third party authentication towards the AS PSP
• Leaves the AS PSP with the freedom to develop security measures around the web- and mobile banking portals without inhibiting TPPs’ ability to operate
• Establishes a clear, stringent liability regime
In short, under an API approach, AS PSPs display an API through which third parties can access functionality (payment initiation) and data from the AS PSP. The PSU should be able to control e.g. which third parties are and are not allowed access to its data or to initiate payments through the AS PSP systems, e.g. through white-lists that can be edited in the internet banking application.
The APIs could be developed by individual banks, by groups or communities of banks or by other service providers offering an interface between TPPs and AS PSPs. The APIs should respect certain common and open standards to be defined, allowing a standardised access model across AS PSPs.
PSU authentication should still occur directly with the issuer of the credentials, e.g. through a pop-up window or a separate app on the mobile. The third party is then issued with a PSU-specific token, allowing the third party a one-time call (for payment initiation) or multiple calls (for account information services) to the API. Such a procedure would not require a “redirect” and the PSU could remain in the interface of the TPP, allowing a smooth customer experience.
To allow AS PSPs to protect against fraudulent TPPs and to ensure the smooth functioning of such an API approach (or indeed any approach to third party access), we believe two further elements are necessary:
- An online, real-time registry of authorised/registered TPPs (PISPs, AISPs and card-based payment instrument issuers (“TPPIIs”)), preferably with a mechanism to issue certificates to the TPPs, giving AS PSPs the tools necessary to protect against fraud (the latter could be provided by some other independent body also). The entity responsible for this should be liable if inaccurate information leads to financial fraud
- A governance set-up that can regulate standards, rights and re-sponsibilities, SLAs, cost and pricing etc
In general, we believe the clarification to be useful – with two caveats:
Firstly, the clarifications only relate to the technical aspects of protecting PSCs. The main risks are, to our mind, of a different nature: social engi-neering and phishing – and in a wider context identity theft; see question 11.
Secondly, these risks are closely related to the sharing of credentials and education of consumers and keeping security messages simple. Allowing credentials to be shared with some (licensed) third parties but not with others is a difficult thing to comprehend."
It is our general experience that the main security risks relating to pay-ments (outside card payments) are phishing and social engineering – i.e. tricking the customer to hand over their PSCs – or tricking them to willingly transfer funds to e.g. a fraudulent account. It is difficult to protect against these risks on a technical level, and much thus depends on educating customers on how to protect their PSCs – preferably through simple, easy to remember rules. Allowing credentials to be shared with certain “trusted parties” makes such education quite complex.
As mentioned previously, in countries like Denmark, with a shared private-public e-identity solution, the risks of sharing credentials becomes much wider than financial losses – the entire digital identity of users is at risk.
As a more general comment, however, it also needs to be considered what exactly is the EBAs role under the mandate in PSD2. The PSD is concerned with payment sevices; authentication tools are used much wider, and it is not entirely clear whether “enrolment and issuance” of credentials fall under the PSD remit? At the very least it needs to be recognised that other authorities and other regulation (e.g. the e-IDAS regulation – see further under section 4.5) also potentially address these issues – and any EBA rules on this need to take this into account.
Thus, 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 number of key principles derive from this:
- There is a need to continuously educate PSUs on the why’s and how’s of safe digital interaction
- There is a need to keep such messages simple, easy to understand and easy to adhere to – including the simple message embedded in article 69 of the revised PSD: “…take all reasonable steps to keep its personalised security credentials safe”
- Third parties should not become part of the authentication process in ways not intended. In the Danish eID solution, the PSCs entered by the customer are encrypted end-to-end and are not even visible to the AS PSP
It is also important to keep in mind that the risk landscape is ever changing as technology evolves and criminals seek out the weakest points in the payment chain. As efforts to open up access to customer data and payment initiation continue, new vulnerabilities are likely to arise, once again underlining the need for a flexible approach from regulators – and in the case of third party access, to the need for a proper governance structure (c.f. the general comments under section 4.3) and for continuous dialogue and exchange of information between AS PSPs and TPPs.
As previously argued, one area not dealt with in the DP which we think will be key to making this work is considerations on a governance set-up.
Although they are mentioned as an aside in para 58, here, as elsewhere, the DP seems to ignore the fact that TPPIIs, under article 65 of the PSD2, will also need to communicate securely with AS PSPs. As above, our as-sumption is that such requests for information on the availability of funds shall be subject to the same technical, security and functional requirements as AIS and PIS.
a. While there seems to be no clear definition of what makes a standard “common” and “open”, the standards used should be internationally used and recognised standards which are set transparently and collaboratively by multi-stakeholder bodies and which can be used by everyone.
b. TPPs should identify themselves towards the AS PSP in an agreed manner – e.g. through the presentation of a certificate issued by a central authority, potentially coupled with the possibility to check against an online directory of authorised/registered TPPs. This would include
- Specification of generic request, response and authentication messages, regardless of the communication protocol.
- Specification of a communication protocol, supported by all registered parties
- Specification of a certification authority that has up-to-date information of authorized/registered TPPs
c. As above
d. The services available through the API are, for now at least, well-defined in PSD2:
- Standardised request for and return of information on the availability of funds (for TPPIIs)
- Standardised request for and return of information on transaction history for set period of time (for AIS)
- Standardised request for and initiation of payments (for PIS)
e. As set out above, security standards should be kept at a general level, allowing for fast changing technology and threats and should preferably be based on existing standards already used in the market. Key principles should be no sharing of credentials and certification of TPPs.
f. If the API approach is chosen, reachability requirements would simply be that all AS PSPs would have to display at least one API delivering the defined services, living up to defined technical principles. Once again, the RTS should not set out detailed technical requirements, restricting the possibility to evolve security or other aspects of the API solution, but should set out the principles for the solution to deliver the functionality set out by the PSD2 in a safe and efficient manner.
- for communication, application of e.g. ISO 20022 (open standard communication)
- Interface between AIS/PIS and ASPSP could be inspired by EBICS, stand-ardising the upload and download of transactions or account data
- Needs to support PKI certificates, aligned with server-based access from AIS and PIS service providers
No matter which services might evolve in the future, the security of PSU funds and data should remain an overarching consideration. As a key princi-ple, we still believe it necessary for the authentication process to occur with the issuer of the PSCs, which ensures adequate security without hampering the possibility for TPPs to deliver their services.
As regards the issuing of own credentials by TPPs, we do not see the need for this, nor are we certain how the AS PSP could be assured about the identity of - and consent of - the PSU in this case.
In fact, the link to the e-IDAS regulation is more problematic in countries where eID schemes are shared between the public and the private sector as in Denmark.
According to article 8 of the e-IDAS regulation, to achieve an assurance level of “substantial”, the eID scheme must provide “a substantial degree of confidence in the claimed or asserted identity of a person, and is characterised with reference to technical specifications, standards and procedures related thereto, including technical controls, the purpose of which is to decrease substantially the risk of misuse or alteration of the identity” (our emphasis). It is our view that this rules out any sharing of the PSCs to third parties.
Hence, should the RTS allow for credential sharing when the PSCs are used for banking, the consequence could be that common public-private solutions are no longer possible if, as is the case in the Denmark, the eID scheme is to be recognised under e-IDSA. This would be highly problematic. In the Danish context, the common solution is seen to bring strong benefits to all parties through
- Recognition and ease of use for citizens – one solution for both public and private services
- Co-operation on security issues and consumer education
- Economies of scale – and the banking sector provides more than 80% of the turnover in NemID
Allowing credential sharing could thus strike a blow at efforts to enhance the digitalisation of Danish society.
As one general remark, however, we remain unconvinced that physical presence needs to be a requirement to become “qualified” – in an increasingly digital world, efforts should be made to get around this.
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.
As a general comment pertaining to all the answers below, the RTS should set high-level principles and retain technological neutrality: Due to the complexity of the issues and the pace of technological change, it is important that the RTS are not too specific, leaving market players leeway to respond and adapt as technology and the risk environment evolves. Furthermore, while we recognise the need to promote the common market, the fact that current solutions and practices vary considerably between countries also needs to be taken into account. Banks in Denmark e.g. have invested heavily in current security solutions, including the Danish eID solution NemID, and have implemented these solutions with specific regard to the convenience of their use. Hence, to our mind, imposing regulation that would dictate the development of specific security solutions across Europe would require very strong security or efficiency arguments to justify investment costs (setting aside technological neutrality). We remain unconvinced that such arguments exist.It is important to recognise that risks stemming from data breaches are wider than payment fraud – and that banks are legally obliged to protect not only the funds but also the data of their customers. Data which can be used for e.g. identity theft (e.g. through obtaining access to authentication credentials through other channels) should also be protected.
Furthermore, as a logical consequence of the technological development and the decreased importance of bank branches, web- and mobile-banking portals are increasingly used as the main channel of interaction between banks and their customers. Hence, the RTS should recognise this development – and take into account that further functionalities are likely to be added to these portals over time – potentially giving rise to a need to re-evaluate which services do and do not require SCA.
In addition to the items requiring SCA listed in para 27. iii, we would add:
• Any secure communication between PSP and PSU
• Any change of security levels, PINs or other characteristics in pay-ment instruments already issued to the PSU
• Application and/or enrolment for new payment instruments, authentication tools or other
• Changes to PSU personal data (address, mail, phone no, etc).
• Entering into mandates regarding direct debit products, recurrent payments, standing orders or the like, which we do not think should fall under article 97(1) (b) – see further under question 5
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?
While possession elements may well have a physical/hardware form, we do not believe it is imperative that this is so. In particular, PSUs increasingly expect to be able to handle everything from a single device – mainly their mobile phone or tablet. Hence, we believe that the RTS should also allow possession elements in the form of software solutions. Separate hardware/physical tokens run the risk of introducing frictions in the payment process, resulting in a non-satisfactory user experience and hence lower uptake – and we believe that it is possible to establish adequate security around a software solution, making e.g. a mobile device a true and independent possession element. Sole control is however required for software to qualify as a possession element.The trick is to ensure that a. only the user can access the possession ele-ment; having the mobile device is not enough (which means no storage of passwords) and b. the possession element cannot be migrated to another mobile device and is tied to the physical mobile device.
There are several ways to obtain this feature of a mobile token app. Most central is to make a strong hardware binding between the app and the mobile device. This is done during the initial enrolment process of the mobile token app, which should also require SCA.
A further consideration is to split crypto keys/certificates used in the au-thentication and signing process, storing some on the mobile inside the app and some centrally on the host. This makes it very difficult to move an already hardware-bound app to another mobile and get it to work.
See further under question 4.
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?
In general, we believe that behaviour-based characteristics can play a key role in PSPs security and authentication measures. They are, in effect, something that the PSU is, and are very hard to fake – and can thus be seen as very strong indicators of identity.Behaviour-based characteristics thus have the potential to fill the role as the inherence element in strong customer authentication. Depending on the implementation and deployment scenario it can either fulfil this role alone or together with other inherence elements. However, the technology may (as yet) be too immature to be considered as an independent element in SCA – although the day will come where this is possible. Furthermore, behaviour-based characteristics can only be used when the PSP has adequate history of interaction with the PSU which enables it to identify such characteristics – meaning that it cannot, in the nature of things, be used e.g. when initially signing up the PSU.
Hence, it should not be the only indicator that is used but used together with other indicators and/or authentication measures it is a very effective tool and should not be dismissed.
The use of behaviour-based characteristics in a risk-based security approach potentially gives rise to particular challenges when PISPs and AISPs are involved.
If sharing of PSCs is allowed under the RTS, we fear that future security developments are at risk. Such a set-up relies on log-in credentials being static and assumes that online banking security measures are only those that meet the eye. This is not always the case – as the use of behaviour-based characteristics illustrate.
PSPs must also be allowed to add further security measures as they see fit in order to meet new threats to their services. Depending on the threat at hand, adding new measures may even be a very urgent matter in order to minimize the impact of criminal activities.
Adding new measures may, however, in turn impede the ability of PISPs and AISPs to provide their services, if this includes changing the authentication mechanism around which their services is tailored. Hence, when considering the future set-up for AS PSP-TTP interaction, such a dependence should be avoided.
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)?
While adequate security is vital, some possible implications of the RTS could be tantamount to making the payment processes so onerous that no-one would use them. This e.g. relates to not allowing authentication and payment to occur from the same mobile device or to requiring all web-based transactions to be independently verified by a separate hardware device (for the latter see next question)..We strongly agree that independence between authentication elements is a key characteristic of a well-designed authentication mechanism. Hence we believe a restrictive requirement of independence (device and channel) should only be required for very high risk transactions. As mentioned above, we do believe that it is possible to have adequate security around a software solution, making e.g. a mobile device a true and independent possession element even when also using the mobile device to initiate the payment.
When performing mobile banking and authentication on the same mobile device (e.g. through a software token authentication app), there is obviously a risk of that malicious software on the mobile can intercept and compromise the security. However, to our mind, there are no commercial authentication solutions (mobile or not) that cannot be tampered by malware. So the key is to build in adequate measure that minimise the risks.
On current mobile token app solutions, several security layers can be added to ensure the necessary independence between payment and authentication:
• 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
• Total separation of the mobile banking app from the mobile token app - i.e. two truly independent apps
• No direct communication on the mobile device between the two apps
• No app switching on the mobile via the mobile operating system
• Not allowing the banking app and mobile token app to run on rooted/jailbroken mobile devices. This reduces the risk for having malicious software running on the mobile trying to intercept the banking session
• Sealing mechanisms build into the mobile token app can also protect the app from malware interference
As regards the workflow, it could be set up as follows:
• Encrypted communication goes from the banking app to the host, from the host to back to the mobile and pushes an authentication request to the mobile token app.
• The mobile token app does the crypto mechanisms needed in the authentication process in encrypted communication with the host and returns an 'ok' or 'not ok' on the authentication request to the host
• The host sends the result to the banking app via encrypted communication.
This could be augmented by solutions that can detect if malware is trying to intercept the session, by malware detection running on the host and by fraud monitoring and risk engines which ultimately can stop any false events from being conducted if malware should succeed in bypassing all other measures.
These solutions are already available today, and fraud levels in the Nordics, where mobile token apps have been in use 2-3 years, are negligible. While risk levels will increase as mobile payments are increasingly used, our view is that there are currently adequate countermeasures.
In the medium term (2-3 years), the next level in securing mobile token apps running on mobile devices for mobile banking should appear. Already today all high-end smartphones have built in so called Trusted Execution Environment (TEE) in the hardware. This will make it possible to step up security to next level with 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 cooperating about a commercial standard for this Trusted Execution Environment and we can expect this to get wider spread on the market within the coming years.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
Given the lack of a clear definition of dynamic linking, answering this question is somewhat difficult.Dynamic linking can be perceived in (at least) two ways:
• Linking the users’ intent with the transaction content through explicitly requiring the user to enter amount and payee information into a transaction token generation device
• Linking the users’ intent with the transaction content by ensuring the end-to-end integrity of the transaction content from WYSIWYS to transaction processing through ensuring that authentica-tion/validation codes are unique and cannot be reused for other transactions
In our view, the latter interpretation is superior as it is technology and process neutral and does not limit future technological evolution of authentication measures and does not, in effect, tie the PSU to a token device. Such a device would severely negatively impact the user experience with the risk of mobile payments becoming too complicated to be used. This interpretation would also meet the goal set out in para. 34 of the DP: “to ensure that the authentication value used for a remote transaction can neither be used for any other purpose than originally intended by the payer nor be re-used if it is disclosed”.
We are also aware, however, that the aim of dynamic linking could be to ensure that the PSU is always aware of and have agreed to the specific amount and the specific payee, even if the PSU cannot observe the banking interface/browser/app through which the transaction is initiated (when payment occurs through a third party as known from some PISPs today).
If this is the interpretation intended from legislators, we again think it is important to allow transaction signing to occur on the same device used for the payment initiation as set out under questions 2 and 4.
In any event, the introduction of dynamic linking potentially has huge economic consequences should it be rolled out across the hundreds of millions bank customers in the EU, which should also be taken into consideration when deciding on the preferred interpretation.
Two further issues related to dynamic linking should be mentioned here:
First of all and in relation to the discussion in para 35 of the DP, we do not believe that dynamic linking should be applied, on a transactional basis, to direct debits, recurrent card payments and recurrent credit transfers. As described above, entering into mandates or agreements pertaining to such payments should be subject to SCA – but the single payments should not be subject to dynamic linking (in particular if it is the first interpretation of dynamic linking that is chosen).
Secondly, and again in particular if the more strenuous approach to dynamic linking is chosen, the definition of a “remote payment transaction” seems to give rise to some problems. A remote payment transaction is defined as “a payment transaction initiated via internet or through a device that can be used for distance communication”, while a means of distance communication is defined as “a method which, without the simultaneous physical presence of the payment service provider and the payment service user, may be used for the conclusion of a payment services contract” (from the PSD text, our emphasis). Hence, as the definition only requires that the device “can be” (not necessarily “is”) used at a distance, this would also seem to capture situations where a payment card is registered in a wallet on a mobile phone and this is used for e.g. contactless payment at a POS.
Thus, paying by plastic card at a POS would not require dynamic linking, paying by the same card stored on a mobile phone would require dynamic linking (and potentially confirming the transaction through a separate device, depending on which interpretation is chosen) which to the PSU would obviously be quite confusing and would almost certainly limit the move towards such convenient wallet solutions.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
As described above, while no system is entirely fool-proof, we believe that systems already exist that fulfil these objectives. It is imperative to have a clear separation of the authentication app and the mobile banking app, to ensure that both apps are secured in a proper manner and that the validating code can only be used for the specific transaction.Even the best authentication system will not protect users from social engineering, and authentication thus needs to be augmented by a dynamic risk approach and the possibility to scale security requirements to the risk of the payment; see further below.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
In general terms, we find the clarifications useful. However, also here the RTS need to be kept at a sufficiently high level, leaving PSPs sufficient lee-way to apply their own transaction risk analysis and adapt security features accordingly.As mentioned above, we believe that payments carried out under a specific mandate from the PSU to the PSP (be it direct debits, standing orders or recurring card payments) should not be subject to SCA on a transactional basis but as and when the agreement or mandate is concluded, as it is also made clear in the EBA Guidelines for the Security of Internet Payments, para 7.1 – and just as is the case for payments to trusted beneficiaries.
In addition to PSU-specific whitelists, the setting up of national whitelists could be considered – e.g. payments to mortgage accounts, tax authorities or other such trusted and often used payees.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
Further to the issues set out above, the EBA should consider the meaning of article 97(1) (a): i.e. the requirement of SCA when the payer “accesses its payment account online”.In accordance with the need to allow PSPs to adjust security requirements to the risks involved, banks adjust security requirements according to the risks and user situation at hand, ensuring a proper balance between convenience and security. In Denmark, this e.g. typically implies that security requirements for only viewing accounts on mobile applications (“account peep”) are less stringent (e.g. no SCA but only one-factor authentication) than for accessing web banks, setting up direct debits or initiating payments.
Furthermore, there is a strong need to ensure that customers are not confused by an uneven application of security across channels or transaction types. The current regulatory regime has e.g. created an environment where a payment initiated through the browser on a mobile phone requires SCA, while the same payment on the same mobile phone initiated via an app would not necessarily require SCA.
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?
While we do not disagree with the criteria mentioned in para 45, we believe as mentioned several times that the RTS should not be too detailed on these issues, sticking to high-level principles and allowing PSPs to develop transaction risk analysis observing these principles and adhering to well-defined risk methodologies. As is always the case, these should be well documented, audited and should be checked as a part of the supervisory regime – as it is already required in the EBA Guidelines on internet payments.Customer behaviour patterns should include date, time, duration and geography. The overall threat landscape should also be taken into consideration when quantifying transaction risk (current technology of threats, current geography of threats, fraud patterns etc.)
The risk analysis could also incorporate e.g. PSP or national white lists (e.g. payments to tax authorities etc) and PSP, national or international black lists (e.g. payments to known mule accounts or other fraudulent accounts).
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
General comments:While we fully recognise the aim of the PSD2 to introduce innovation and competition through third parties (TPPs"), the presence of third parties may introduce an unfortunate link between these and AS PSPs. The latter must not be impeded in their ability to counter criminal activities or to evolve their security measures. In particular, in the words of the Danish Payments Council, basically, “the security of payer authentication should not depend on whether a third party is involved”:
While this section of the DP does not mention TPPs specifically, we think it is important to consider these here. Our key area of concern is business models relying on the consumer handing over their personal banking log-in credentials to the third party (“screen-scraping” or “credential sharing”).
Banks, the public sector and other providers of online services have spent a long time educating users that personal log-in credentials are personal and that handing them over to third parties involves significant risks. This principle is also enshrined in both the previous and new Payment Services Directive. In Denmark, the risks of handing over one’s credentials are even larger, as log-in to banks’ online banking portals occurs through the use of NemID – a public-private co-operation which also allows users to access a large number of public services (including tax reporting, health files, changing one’s address etc) – and other private services in need of proper user authentication and digital signing of binding transactions. Hence, if NemID is compromised, it is not only the bank account that is at risk – but the consumers’ entire digital identity.
While we recognise that the aim may have been for the PSD to allow cre-dential sharing (and this is not entirely clear from the PSD text as it stands), we believe there are technical alternatives that at the same time allows AISPs and PISPs to deliver their services, reduce inherent risks in the screen-scraping business model and ensure that PSUs are left in full control of which data they wish to share with certain third parties. On top of this, an added benefit is a clearer liability regime, which in particular does not leave the AS PSP with “residual liability” for situations over which it does not have control. Hence, from a public policy point of view, not only a narrow AS PSP point of view, we see strong arguments for considering an API approach.
Summing up, the API approach:
• Does not necessarily rely on credential sharing
• Leaves the PSU in full control over which data to share
• Solves the problem of PSU consent and third party authentication towards the AS PSP
• Leaves the AS PSP with the freedom to develop security measures around the web- and mobile banking portals without inhibiting TPPs’ ability to operate
• Establishes a clear, stringent liability regime
In short, under an API approach, AS PSPs display an API through which third parties can access functionality (payment initiation) and data from the AS PSP. The PSU should be able to control e.g. which third parties are and are not allowed access to its data or to initiate payments through the AS PSP systems, e.g. through white-lists that can be edited in the internet banking application.
The APIs could be developed by individual banks, by groups or communities of banks or by other service providers offering an interface between TPPs and AS PSPs. The APIs should respect certain common and open standards to be defined, allowing a standardised access model across AS PSPs.
PSU authentication should still occur directly with the issuer of the credentials, e.g. through a pop-up window or a separate app on the mobile. The third party is then issued with a PSU-specific token, allowing the third party a one-time call (for payment initiation) or multiple calls (for account information services) to the API. Such a procedure would not require a “redirect” and the PSU could remain in the interface of the TPP, allowing a smooth customer experience.
To allow AS PSPs to protect against fraudulent TPPs and to ensure the smooth functioning of such an API approach (or indeed any approach to third party access), we believe two further elements are necessary:
- An online, real-time registry of authorised/registered TPPs (PISPs, AISPs and card-based payment instrument issuers (“TPPIIs”)), preferably with a mechanism to issue certificates to the TPPs, giving AS PSPs the tools necessary to protect against fraud (the latter could be provided by some other independent body also). The entity responsible for this should be liable if inaccurate information leads to financial fraud
- A governance set-up that can regulate standards, rights and re-sponsibilities, SLAs, cost and pricing etc
In general, we believe the clarification to be useful – with two caveats:
Firstly, the clarifications only relate to the technical aspects of protecting PSCs. The main risks are, to our mind, of a different nature: social engi-neering and phishing – and in a wider context identity theft; see question 11.
Secondly, these risks are closely related to the sharing of credentials and education of consumers and keeping security messages simple. Allowing credentials to be shared with some (licensed) third parties but not with others is a difficult thing to comprehend."
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
The risk landscape continues to evolve as both providers of authentication solutions and criminals evolve their defence and attack strategies. This once again highlights the need for the RTS to leave leeway to adapt and innovate security solutions in the light of technological advances and the changing modus operandi of IT criminals.It is our general experience that the main security risks relating to pay-ments (outside card payments) are phishing and social engineering – i.e. tricking the customer to hand over their PSCs – or tricking them to willingly transfer funds to e.g. a fraudulent account. It is difficult to protect against these risks on a technical level, and much thus depends on educating customers on how to protect their PSCs – preferably through simple, easy to remember rules. Allowing credentials to be shared with certain “trusted parties” makes such education quite complex.
As mentioned previously, in countries like Denmark, with a shared private-public e-identity solution, the risks of sharing credentials becomes much wider than financial losses – the entire digital identity of users is at risk.
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?
In an increasingly digital world, we believe that enrolment should also be possible online and not only through physical turnout. Some steps in this direction have been taken utilising the chip in e-passports.As a more general comment, however, it also needs to be considered what exactly is the EBAs role under the mandate in PSD2. The PSD is concerned with payment sevices; authentication tools are used much wider, and it is not entirely clear whether “enrolment and issuance” of credentials fall under the PSD remit? At the very least it needs to be recognised that other authorities and other regulation (e.g. the e-IDAS regulation – see further under section 4.5) also potentially address these issues – and any EBA rules on this need to take this into account.
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?
Credit institutions are subject to a whole host of requirements regarding IT security as e.g set out in the Executive Order on Management and Control of Banks etc from the Danish FSA, which requires credit institutions to have in place a detailed IT security risk policy. Furthermore, credit institutions are subject to both internal and external (IT-) audits, and IT security is a key part of the supervisory process, both from prudential supervisors and from payment system overseers. Hence, we believe that credit institutions to a large extent are already subject to tight controls in the IT area.Thus, 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?
As mentioned above, the risks seem mainly to be at the PSU level, as targeting the PSU allows fraudsters to more or less completely bypass any security measures put in place by PSPs and/or issuers of PSCs by either impersonating the PSU or getting the PSU to transfer funds willingly. Furthermore, risks seem to be concentrated around the transmission and storage of PSCs – in particular when third parties are involved – as exemplified by the continuous news-stream on loss of customer card data at retailers.A number of key principles derive from this:
- There is a need to continuously educate PSUs on the why’s and how’s of safe digital interaction
- There is a need to keep such messages simple, easy to understand and easy to adhere to – including the simple message embedded in article 69 of the revised PSD: “…take all reasonable steps to keep its personalised security credentials safe”
- Third parties should not become part of the authentication process in ways not intended. In the Danish eID solution, the PSCs entered by the customer are encrypted end-to-end and are not even visible to the AS PSP
It is also important to keep in mind that the risk landscape is ever changing as technology evolves and criminals seek out the weakest points in the payment chain. As efforts to open up access to customer data and payment initiation continue, new vulnerabilities are likely to arise, once again underlining the need for a flexible approach from regulators – and in the case of third party access, to the need for a proper governance structure (c.f. the general comments under section 4.3) and for continuous dialogue and exchange of information between AS PSPs and TPPs.
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?
On a general level, we believe the clarifications provided are comprehensive and suitable. In the end, the key question remains which model for AIS and PIS the EBA finds to be acceptable. As mentioned above, we believe an open API approach where the PSU is authenticated directly with the issuer of the PSCs is the best way forward.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?
In general, simplicity is essential and flexibility must remain to ensure that established national solutions (e.g. on authentication) can continue to operate. As argued above, we believe the RTS should be based on the open API approach with authentication of the PSU occurring through the issuer of the PSCs which would provide the most appropriate set-up to deliver the services promoted through the PSD2 in a safe, efficient, user-friendly and future-proof way.As previously argued, one area not dealt with in the DP which we think will be key to making this work is considerations on a governance set-up.
Although they are mentioned as an aside in para 58, here, as elsewhere, the DP seems to ignore the fact that TPPIIs, under article 65 of the PSD2, will also need to communicate securely with AS PSPs. As above, our as-sumption is that such requests for information on the availability of funds shall be subject to the same technical, security and functional requirements as AIS and PIS.
a. While there seems to be no clear definition of what makes a standard “common” and “open”, the standards used should be internationally used and recognised standards which are set transparently and collaboratively by multi-stakeholder bodies and which can be used by everyone.
b. TPPs should identify themselves towards the AS PSP in an agreed manner – e.g. through the presentation of a certificate issued by a central authority, potentially coupled with the possibility to check against an online directory of authorised/registered TPPs. This would include
- Specification of generic request, response and authentication messages, regardless of the communication protocol.
- Specification of a communication protocol, supported by all registered parties
- Specification of a certification authority that has up-to-date information of authorized/registered TPPs
c. As above
d. The services available through the API are, for now at least, well-defined in PSD2:
- Standardised request for and return of information on the availability of funds (for TPPIIs)
- Standardised request for and return of information on transaction history for set period of time (for AIS)
- Standardised request for and initiation of payments (for PIS)
e. As set out above, security standards should be kept at a general level, allowing for fast changing technology and threats and should preferably be based on existing standards already used in the market. Key principles should be no sharing of credentials and certification of TPPs.
f. If the API approach is chosen, reachability requirements would simply be that all AS PSPs would have to display at least one API delivering the defined services, living up to defined technical principles. Once again, the RTS should not set out detailed technical requirements, restricting the possibility to evolve security or other aspects of the API solution, but should set out the principles for the solution to deliver the functionality set out by the PSD2 in a safe and efficient manner.
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?
There are several international globally used standards that could be con-sidered:- for communication, application of e.g. ISO 20022 (open standard communication)
- Interface between AIS/PIS and ASPSP could be inspired by EBICS, stand-ardising the upload and download of transactions or account data
- Needs to support PKI certificates, aligned with server-based access from AIS and PIS service providers
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)?
Once again, this underlines the need for flexible and high-level requirements, allowing the industry to adapt, develop and respond as technology evolves. In the nature of the question, it is very hard to anticipate what such “other innovative business models” might entail.No matter which services might evolve in the future, the security of PSU funds and data should remain an overarching consideration. As a key princi-ple, we still believe it necessary for the authentication process to occur with the issuer of the PSCs, which ensures adequate security without hampering the possibility for TPPs to deliver their services.
As regards the issuing of own credentials by TPPs, we do not see the need for this, nor are we certain how the AS PSP could be assured about the identity of - and consent of - the PSU in this case.
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.
To our mind, the e-IDAS regulation, while helpful in its own right, will not provide a possible solution to the issues arising from PIS and AIS. e-IDAS does not mandate the introduction of solutions in member states but only regulates how such solutions, where they exist, can be recognised cross-border.In fact, the link to the e-IDAS regulation is more problematic in countries where eID schemes are shared between the public and the private sector as in Denmark.
According to article 8 of the e-IDAS regulation, to achieve an assurance level of “substantial”, the eID scheme must provide “a substantial degree of confidence in the claimed or asserted identity of a person, and is characterised with reference to technical specifications, standards and procedures related thereto, including technical controls, the purpose of which is to decrease substantially the risk of misuse or alteration of the identity” (our emphasis). It is our view that this rules out any sharing of the PSCs to third parties.
Hence, should the RTS allow for credential sharing when the PSCs are used for banking, the consequence could be that common public-private solutions are no longer possible if, as is the case in the Denmark, the eID scheme is to be recognised under e-IDSA. This would be highly problematic. In the Danish context, the common solution is seen to bring strong benefits to all parties through
- Recognition and ease of use for citizens – one solution for both public and private services
- Co-operation on security issues and consumer education
- Economies of scale – and the banking sector provides more than 80% of the turnover in NemID
Allowing credential sharing could thus strike a blow at efforts to enhance the digitalisation of Danish society.
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.
While we do not see the e-IDAS regulation as a panacea for the issues at hand, certain aspects of the regulation could probably be useful when setting out the RTS, e.g. the use of qualified trust services, qualified electronic seals or qualified electronic registered delivery services. In the Danish context, third parties could actually become “service providers” in NemID.As one general remark, however, we remain unconvinced that physical presence needs to be a requirement to become “qualified” – in an increasingly digital world, efforts should be made to get around this.