Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
• We respect policy makers and regulators’ desire to enhance consumer protection and guard against fraud. We note that:
o The methods employed by fraudsters change rapidly, especially as new attack vectors open up. It is vital that those seeking to prevent fraud are equally able to adapt their approach.
o As the EBA recognises, there is a constant balance to be found between customer experience and fraud prevention. There is considerable innovation in strong authentication solutions, and it is important to ensure that the principles or standards do not inadvertently stymie their development.
o Principles, guidelines or standards naturally contain a degree of parameter-setting, and no matter how high level, this has the potential to restrict new approaches. We encourage the EBA to retain an ability to re-assess the landscape at intervals, and introduce further flexibility if there is a demonstrable case for it.
• It should be acknowledged that all actions have a potential risk of fraud – the RTS can’t describe every threat. This includes, but is not limited to:
o Change of address or other contact details such as mobile phone/number,
o Stopping and re-ordering a new token,
o Applying for an account,
o Amending white lists of trusted beneficiaries,
o Setting limits on payment functionality.
o Changing the mode of statement delivery or other communications.
o Requesting an overdraft facility or an increase in any existing facility or applying for a new product within online banking.
o Adding new account holders, card holders or administrators to existing accounts
• We want to ensure that the payments environment remains highly secure – banks must be allowed to fulfil e.g. AML requirements and to innovate around security and authentication.
• The EBA principles for the RTS need to be future-proofed and sufficiently flexible. New services and functionality will constantly arise, leading to new types of data and risk, etc. Ultimately our view is that there is not one single approach to strong customer authentication that will work in all scenarios.
• A layered/defence-in-depth approach is vital, no single authentication mechanism or security tool can be relied on solely as these solutions or mechanisms may be circumvented - the PSD2 RTS should require this kind of multi-faceted approach (the experience of the UK banking sector has demonstrated this time and time again).
• It’s not just ‘payment fraud’ on a single online channel that we need to consider, and the outcomes are not limited to ‘financial loss’. For example, risks like ID theft are also key considerations that firms need to mitigate against.
• The EBA should recognise the difference, in particular the fraud risks, between card transactions online and other online transaction types e.g. online banking. For card transactions there is currently no opportunity/mechanism in place to go through strong customer authentication (other than if 3D secure is used) and this is a decision of the retailer/online merchant. We recognise that industry and card schemes will need to work together to ensure some communality of experience (while enabling innovation). There is clearly a need to ensure that retailers/online merchants, card schemes and card issuers and other key stakeholders are also playing a part in ensuring appropriate security.
• Generally speaking hardware elements do provide a good solution in the context of strong customer authentication, in terms of proof-of-possession and independence. However, they are not the only solutions. The direction of travel across financial services and other sectors is away from the use of multiple devices. Many customers increasingly expect to perform all aspects of authentication on a single device, e.g. a mobile phone or tablet (1). Accordingly, it would not be appropriate for the EBA RTS principles to require separate hardware tokens. Non-physical software/data tokens are more forward looking options; and indeed these types of solutions have open implementations in the market – for example, ‘Google authenticate’.
• A software key can be regarded as ‘physical’, but will require specific security measures to ensure only the intended user can use it. Where a soft token (authentication data) is stored on a trusted device there should be strong authentication in place to create or migrate the token.
• In fact some banks in the UK already offer software tokens for customer use. Furthermore, given the fact that we may increasingly move towards the use of cryptography and distributed ledger solutions, it is clear that this approach needs to be recognised by the EBA principles.
• We believe that an ASPSP should be able to make its own risk assessment as to whether to accept data as possession element but we greatly welcome its inclusion in the language of the Discussion Paper and encourage the EBA to retain it. This wording provides the basis for the use of innovative and secure strong authentication solutions. To ensure the data can only be controlled by the user, it is important that PSPs introduce controls around access to the data (e.g. to prevent trivial copying of the data and prevent reuse ‘out of context’).
• The RTS should define the characteristics such possession elements must meet. It should not provide a limited list of approved possession elements, but could provide examples.
• One characteristic should be that the possession element must be unique to a customer. Examples include:
o Hardware tokens
o ‘Software creating a One Time Passcode (OTP) in conjunction with the PSU authenticating himself / herself with the software. Providing that there is an adequately protected secret key provided to, or agreed with the customer, during a suitably robust enrolment process.
• The possession element must be some significantly secure item made available by the service provider, or agreed with the user during a suitably robust enrolment process (i.e. agreed or negotiated, not necessarily issued by the PSP). This is important for allow for emerging authentication protocols. The possession element could also be a device the customer uses, but in this case it is critical that is registered/enrolled via a robust process with the ‘owner’ of the authentication (i.e. an ASPSP) and is authenticated/approved by them. There are types of authentication that support a ‘bring your own device’ solution. Under current Discussion Paper wording it is not clear whether they are permissible. For example, paragraph 28 specifies that “at the time of registration for a payment service or payment method, the provision of personalised security credentials involves the recording of authentication elements by the PSP”; but Recital 30 states that “the personalised security credentials used for secure customer authentication by the payment service user or by the payment initiation service provider are usually those issued by the account servicing payment service providers”. We would welcome clarification to ensure these methods are acceptable.
• Possession elements should also include data whose lifecycle is managed by an ASPSP e.g. mobile App, Internet of things (IoT) device enrolment under ASPSP control.
(1) In 2015 Consult Hyperion on behalf of Payments UK released a report, which forecast that within the next five years, widespread mobile adoption aligned with up-and-coming biometric security improvements and regulatory initiatives will lead to a growing emphasis on the mobile phone as the primary means of paying for goods and services and managing accounts. http://www.paymentsuk.org.uk/sites/default/files/The%20Future%20of%20Payments%20Aug%2015.pdf
• Behaviour-based characteristics are key in financial services. They can be used both for the physical behaviour of the customer (e.g. location, type of device etc) as well as spending patterns. They can be used before and after a transaction takes place and form a key part of tiered authentication. By being able to assess whether the customer is at home, on their home computer, making the same payment amount to the same payee as last month ASPSPs are able to assess the risk and the level of authentication required. This allows a balance to be reached between security and the ease of the customer experience, which is key in supporting e- commerce. At present behaviour-based characteristics are part of a risk assessment not an authentication factor. However, it is not unreasonable to expect that there could be further developments in this space.
• Behaviour based characteristics can be used to demonstrate inherence but they need to be consistent over a period of time and resilient to changes in platform or application (e.g. my behaviour needs to be the same even though I am using a different mobile device). Behaviours that are truly inherent should be distinguished from preferences, which can change at any time.
• User behaviour is constantly changing, and will change further with the introduction of new services and players (like TPPs). TPPs can themselves also introduce new behaviours (i.e. machine behaviours).
• The technology is developing fast and it has a number of very strong benefits. In particular, because it acts as a kind of ‘invisible’ strong customer authentication, where customers (and criminals) are not aware of what aspects of behaviour are being utilised.
• We strongly support the clarification that “For strong customer authentication the PSCs can be either a valid combination of these elements themselves or something which is only generated when all the elements have been provided” as this enables the use of OAuth (discussed later in our response) which can be implemented in a highly secure way. We encourage the EBA to retain this language.
• A more dynamic and risk-based framework for strong customer authentication supports future innovation and provides greater scope for customisation by the PSP. The weakest point in the chain will be attacked first and the RTS need to consider the full lifecycle of a user.
• On point 32, we agree that independence is a crucial factor for ensuring strong security. However, we do not believe that independence of devices is necessarily required, so long as there is independence of communication channels on a device the risks can be mitigated. Software-based isolation (e.g. encryption, operating system-based isolation of applications) is secure and can in some instances be as secure as a separate hardware based token. For example, for mobile devices independence can be achieved if the entry of the password and the generation of the transaction code are done by different apps which both exist on the same mobile device.
• It is worth noting that the riskiness of a transaction merits different approaches which the PSP would be best placed to decide upon. For example, if a customer is making a purchase online, using their mobile phone browser, when they want to authenticate a payment they log into a secure token on an app and receive a text message to their mobile phone. The customer can then continue with the payment in the browser (though we note that this will impact on the customer retail experience).
• As previously mentioned under question 2, the market and consumers are increasingly moving towards the use of mobile phones/tablets as their sole device (2). While there are of course some challenges with this approach, we must accept this is becoming the new norm. We are moving into mobile centric interaction for all aspects of finance. We believe that as long as there is independence of communication channels and appropriate levels of security within the device then it is possible to ensure the objectives of strong customer authentication. We therefore feel it would not be appropriate for the EBA RTS to require separate hardware tokens for authentication.
• As an example, in a cards context offline PIN in EMV would violate the requirement for independent devices, but done well it may be more secure than online PIN that is executed badly.
• However, it is clear that as customers move towards using a single device then firms need to be more aware of the externalisation of certain security elements and of the reliance they are placing on the security of other infrastructures (e.g. SMS), which need to be considered fully in any risk analysis. For example, naïve jailbreaking/device rooting can increase risk, and we would encourage device manufacturers to patch vulnerabilities more readily than today, as the market would benefit significantly.
• Finally, we note that there are multiple technologies which underlie a mobile device, for example, NFC, Bluetooth, GPRS, LTE and other developing technologies, all of which are governed and regulated differently. It is therefore worth noting that a mobile should not necessarily be defined as one element in itself (there are multiple layers) and the PSP should be able to decide their own risk-based approach to separate mobile technologies.
(2) Research conducted by BAIN in 2014 (which surveyed roughly 83,000 consumers in 22 countries to reach its conclusions) stated that “Banking customers now handle more of their banking interactions, on average, via smartphones and tablets than through any other channel”. http://www.bain.com/publications/articles/customer-loyalty-in-retail-banking-2014-global.aspx
• This is a difficult question to answer fully without a clear definition of dynamic linking in PSD2.
• One notable challenge is that in some contexts such as card transactions, strong customer authentication would begin on retailers’ websites. We would advocate that the EBA engage more directly with the retail community, regarding their shared role (particularly in the e-commerce space) in delivering a strong customer authentication environment.
• The distinction between strong authentication and dynamic linking is important. While we support strong authentication, dynamic linking is only relevant and helpful in limited circumstances.
• We would welcome clarity as to the purpose of dynamic linking to help us understand its application to remote electronic payments. PSD2 text suggests that it should be used “to make the user aware, at all times, of the amount and the payee of the transaction that the user is authorising”. The EBA Discussion Paper suggests its purpose is to provide “a high assurance that the PSU has been identified and is authorising a specific payment transaction”. These appear to be different aims, which would therefore impact the kinds of solutions and risk mitigants that would be acceptable.
• If making the user aware of the amount and payee is the objective, we question whether dynamic linking should ever be required for retailer-generated payments (like online card payments), and would encourage the EBA to exempt them from scope. For example, if a customer wishes to pay ‘Retailer x’ €200 for a flight; they will be very aware that this is the transaction they are authorising. From a fraud perspective, there is also very limited scope for a ‘man-in-the middle’ type attack.
• We note that some solutions that enable dynamically linking provide the user with visibility of the payee and amount, while others do not. Solutions where the user has to input this data do not offer any fraud prevention benefit beyond the other kind (a nefarious actor would just input the same data twice) but the customer journey contains far more friction (so causes a negative impact on e-commerce). If some form of dynamic fraud protection is required to prevent fraud (a different purpose to user awareness), a unique dynamic code offers as much protection as a dynamically linked code, but has a far better customer experience – and is therefore less detrimental to e-commerce.
• In relation to mobile banking applications, the use of cryptographic keys should be considered as a form of dynamic linking. These provide, by way of comparison, considerably greater security than one-time passcodes.
• With an evolving market, the RTS should provide discretion for PSPs to determine how they implement dynamic linking of a transaction and also to determine whether the dynamic linking of a transaction is made visible to the PSU.
• A key exemption will be around “low risk transactions”. Some providers have sophisticated tools for transaction and customer analysis which can be far more powerful than dynamic linking in confirming the identity of the customer and the likelihood of fraud. The ability to “step-up” authentication based on the risk of an individual transaction is key to the smooth functioning of electronic payments whilst ensuring that customers are protected from fraud.
• There is uncertainty around dynamic linking for bulk payments i.e. payment files that will contain multiple individual payments and thus multiple payees and amounts. It is not unusual for a bank to receive a batch payment file of 50,000 individual payments. Bulk payments which are awaiting verification by a second authorizer requires consideration – a relevant dynamic link may be beneficial but discussion on which values to employ is required. With any additional requirements, the EBA should consider the degree of change to customer experience and the impact this may have on the businesses concerned.
• In terms of the comments in paragraph 35 regarding difficulties for dynamic linking where the amount is not known, we suggest that if an amount is not available, this can be set by default to zero.
• We understand that the dynamic linking requirement applies to ‘remote electronic payment transactions’, and that PSD2 states that a ‘remote payment transaction’ is a payment transaction initiated via the internet or through a device that can be used for distance communication (but excludes non-electronic payments such as mail, paper-based and telephony). It is always difficult to define something by what it is not, therefore the definition of a remote electronic payment is challenging. We believe, though would welcome clarification, that the following are out of scope for dynamic linking:
o Video-banking, as this would be considered in the same way as telephony;
o Phone calls made from mobile phones (these could potentially be caught as a device that can be used for distance communication, though we do not believe this was the intention).
o Payments initiated at ATMs. While the networks that support these machines use phone lines, internet access and central computers to distribute information and facilitate transactions, there are specific fraud protections that apply to ATMs. ATM networks are walled ecosystems where operators have to adhere to robust requirements to protect the physical security of their devices and user credentials. This means that the risks associated with activity that happens on them are vastly different, for example, to online activity (in the commonly used sense of the term). The control environment around the operation of ATMs is extremely stringent and we would encourage the EBA to seek assurance from the schemes with regards to annual attestations to confirm the adequacy of the cryptographic control environment. Due to the different risk profile ATMs present, we encourage the EBA to consider excluding them from dynamic linking requirements. We would add that the profile of customers who use ATMs is far wider than those who use online banking, so the consequences of a big change in process (without a discernible fraud prevention benefit) is worthy of consideration.
o Point of Sale transactions, as these are not ‘remote’.
• A more general point is that any dynamic code must not be able to be used to authenticate further fraudulent activity or be of use if it (alone) is compromised.
• No solution could ever be 100% secure. We appreciate the EBA’s recognition that there are trade-offs between security and customer experience, and would caution that all activity carries some form of risk. The challenge is to mitigate it in a proportionate way rather than eliminate it completely. Total assurance that customers have sole control and/or sole visibility of any communication from the PSP is simply not realistic; SMS, email, voice calls and other forms of communications are all vulnerable to compromise.
• There are different levels of independence and dynamic linking; generally higher levels of independence and dynamic linking are used for ‘higher risk’ activity. It is important that this tiered approach, in conjunction with a risk-based analysis by individual PSPs, is maintained. Divergent approaches to methods of authentication by different PSPs ensure that it is more difficult for fraud to take place.
• Firms make decisions on which solutions to use based on individual risk assessments and an understanding of their customer base.
• It is for these reasons that any one particular solution for the authentication of mobile devices should not be endorsed. This is both to maintain secure means of authentication, but also to allow more innovative forms of authentication to continue to develop.
• We broadly consider the clarifications suggested as useful.
• However, in general, we would prefer the clarifications to be considered non-exhaustive and based on principles, as this would support the ability for PSPs to take a risk-based approach. Risk appetite is often dynamic and driven by the PSP and the environmental considerations (e.g. high usage, heightened fraud activity, the emergence of new attack vectors). At a principles level, the EBA could consider the following:
o Exemptions should balance the need for stronger authentication with minimal customer friction.
o Exemptions should include where stronger authentication has already been achieved within the same session and there are no further opportunities for fraudulent activity (e.g. a payment) – there is little value add to doing this again.
o Exemptions should include where the customer is strongly recognised e.g. the same device that is established for that customer (and not for any other customer).
o Exemptions can include where no sensitive or risky transactional capability exists post authentication (or where step up authentication is then required to perform this sort of activity).
• In terms of point 42B on whitelists, we think that this concept is already well-explained in the Security of Internet Payments guidelines (7.1), allowing alternative customer authentication measures for “outgoing payments to trusted beneficiaries included in a previously established white list for that customer”. Transactions against a whitelisted beneficiary should in themselves not require strong authentication (this exemption is part of the Guidelines and the RTS should reflect that). Manipulation of the white list would require strong authentication per PSD2 Article 97(1c).
• We appreciate the EBA’s intention to exempt “low value payments”, and appreciate that this is intended to be “as defined in the PSD”. We would welcome clarity as to the interpretation. The PSD2 wording refers to low value payments “In cases of payment instruments which, according to the relevant framework contract, concern only individual payment transactions that do not exceed EUR 30”. We believe the intention is to provide an exemption for both (i) payments below EUR 30 (or the level set by Member States) and (ii) low value payment instruments (for example, contactless wearables).
• While not an exemption as such, in terms of the EBA’s mandate to cover strong authentication when logging in to online banking we would suggest that the RTS should be clear that strong authentication at login should only be required for a login that gives access to sensitive information and/or transactional capability (unless exempt). A risk-based authentication can give access to non-sensitive information. Sensitive information should only be accessed after at least one strong authentication during the session (must not be by default at login). A default of strong authentication might be acceptable if there is a sufficiently clear framework to allow exceptions where a clear rationale can be given based on assessment of the risk and mitigation processes.
• We would encourage the exemptions to be kept at a relatively high-level to enable PSPs themselves to analyse what is deemed a low-risk transaction (we expand on this in our response to Q9).
• We would welcome clarity on the treatment of virtual cards. The Discussion Paper suggests that the ‘setting up of limits or the generation of virtual cards’ are within scope. We believe this means that the Administrator of a virtual card needs to be strongly authenticated when they set up the log-in numbers for Users on the system; but that the Users do not need to be strongly authenticated when they use the numbers. If this is not the intention, we would suggest that virtual cards could be considered for exemption as a “specific-purpose instrument”.
• There is also a question as to whether the intention is to include ‘point of sale’ transactions. This is particularly relevant for contactless payments where ease of use is the key customer benefit and innovative quality. There are safeguards in place to protect the customer, including the requirement to put in a PIN after a number of transactions and automatic refunds for any disputed payments; and of course higher value contactless payments would be supported by PIN entry or, e.g. in the case of mobile phone based solutions, a biometric authentication step. While we appreciate that low value payments are out of scope, we would encourage the EBA to consider a broader exemption for contactless payments.
• Our reading of the EBA discussion paper is that direct debits are included within the exemptions (albeit strong authentication may be required for the set-up of the direct debit instruction/collection of the first direct debit). It would be useful if the EBA could clarify this point; we note that direct debits offer other safeguards which mean the concept of Strong Authentication may have less applicability in this type of payment than others. This often includes, for example, a customer alert when a direct debit is first taken. There are complexities in application of strong authentication to Direct Debits, even the first set up. This is because a direct debit originator (e.g. a utility company) is the one to interact with the customer - rather than the PSP - but they do not have the depth of customer relationship that would enable them to easily strongly authenticate the customer. If a change were required to bring the PSP into this process (or for originators to start performing this kind of service), it would add friction to the customer experience and may undermine the use of electronic direct debits and encourage the use of the paper version. The impact on originators would need to be considered – i.e. the business community.
• Aside from specific potential exemptions, we would welcome clarification on the liability model for exempt activities. We appreciate that “where the payer’s PSP does not require strong customer authentication, the payer shall not bear any financial losses unless the payer has acted fraudulently. Where the payee or the PSP of the payee fails to accept strong customer authentication, it shall refund the financial damage caused to the payer’s payment service provider”. We would imagine that the liability model for exemptions would clarify that where a PSP is exempted from requiring strong authentication, the provisions in Article 4 1 would apply.
Introductory comments:
• Security and integrity of the payment systems are of the utmost importance: The payments industry believes that the security and integrity of the payments system is of the highest importance, not only for general economic stability but in terms of ensuring continued high consumer confidence (3). The industry works most effectively when it is able to respond dynamically and quickly to new and emerging threats. Increasingly criminals are taking advantage of the availability of customer data in order to effect fraud and other criminal activities. To highlight this, we note that in the UK in Q3 2015 alone, there was a 147% increase in data hacks / compromise incidents. A top 4 UK retail Bank reported that their organisation had seen a very significant increase (circa 50%) in card fraud that emanated from data compromise. This is why we stress throughout this response the vital importance of putting in place processes that can enable the legislative aims of PSD2 but which nevertheless allow PSPs to maintain high levels of security, integrity, protection of customer data and customer control.
• The areas of security and authentication are highly complex and are constantly developing. We believe the EBA should design the RTS at a high level and not try to define detailed ‘technical implementation standards’: The risk of the EBA being too prescriptive is that the industry will be hampered from responding and reacting to cybercrime and fraud threats adequately and the requirements will be quickly outdated, and it may be more difficult to innovate.
(3) The Commission Communication on the Digital Single Market: factsheet for the UK stated that 39% of the UK (43% EU) are concerned about someone misusing their personal data and 49% of the UK (42% EU) are concerned about the security of online payments
Comments:
• There should be an exemption for recurring transactions. Although recurrence is mentioned in paragraph 41 it is not listed in the exemptions in paragraph 42 (this may just be an oversight).
• Generally speaking, we believe that the EBA Security Guidelines published in 2014 provide a good basis for the RTS, especially as the industry is already working towards implementing these.
• Some of our members suggested that potentially the EBA could consider a tiered approach. An example is given below:
o Transactions not requiring strong authentication, e.g., a mobile app only requiring user-id user-password, allowing only small amount transfers (with a weekly/monthly max); or, logging on when there is no ability to access sensitive data.
o Transactions requiring strong authentication but no “dynamic linking”, e.g., payments to ASPSP-identified utility providers (e.g., electricity company) or payments initiated via an ATM
o Transactions requiring strong authentication with “dynamic linking” e.g., ad-hoc high value transfer
• We don’t think the three points highlighted in paragraph 45 should be considered exhaustive and don’t believe a prescriptive list is needed. Firms will take into account a wide range of aspects when analysing risk and these will change and adapt as the ecosystem changes. Firms need to constantly react to new and unforeseen changes in circumstances. If the list is intended to be definitive, we would encourage the EBA to clarify that firms may carry out their risk-based analysis by taking any of them into account, and not all of them (‘or’ rather than ‘and’).
• PSPs should take a risk-based approached to customer authentication and transactions, a one-size-fits-all solution or procedure is not practical and will hamper innovation and damage the customer journey (the experience of the UK banking sector has demonstrated the benefits of this approach in the context of balancing customer experience with security).
• The principle around risk analysis should be that the processes must adhere to generally/widely recognised/defined risk methodologies and could be demonstrated to an auditor.
• Other examples which could be added to the EBA’s points in paragraph 45 include, for example, reference to lists of known fraudulent accounts, and the interplay with AML requirements regarding transaction screening, which ASPSPs must already conduct, etc.
• We are supportive of the language around ‘customer device used’. Mobile applications (like mobile banking or person-to-person payment apps) can be specific to the device they are installed onto – such that if a different device was used to attempt a log-in to the app using the genuine PSU’s credentials, it would be refused. Where this protection is absent, they often also involve the use of data that tightly binds the application to the device, adding an extra layer of security. The ability of firms to consider the risk of the customer device used is important.
We do not believe that the aims of PSD2 to (i) give customers control over what information they make available or (ii) create a multifactor authentication environment, can be properly met by customers making their credentials accessible to TPPs who will log in on their behalf. Instead, we believe that by using an API approach there are technological solutions that mean credentials are only used between the ASPSP and customer and yet TPPs will get the full functionality and information they need.
As a key principle, ASPSPs and TPPs should own and control the method by which they authenticate their own users. So when a customer is required to authenticate itself to the ASPSP in order to grant a TPP access to its information, this authentication should happen directly between the customer and ASPSP, in whatever way they currently use. We do not believe that ‘screen-scraping’/ ‘impersonation’ type approaches are secure or appropriate (they also do not allow customer to have a granular degree of control over what information is shared).
There are technical means available that already exist and are in use that mean customers don’t need to make their credentials available to any other parties. Overall we recommend an approach of ‘delegation’ rather than ‘impersonation’.
These technical means now available (e.g. Oauth 2.0 and Open IDConnect, which are predominantly used in the API environment) make it unnecessary for other parties to have access to credentials. These solutions are used securely by some of the biggest companies in the world like Facebook, Google and Amazon.
As an example, using the scenario of an API utilising OAuth 2.0, when the customer is on the TPP website they would simply be presented with a pop-up window that allows them to authenticate directly with the issuer of the credentials (in this case the ASPSP). Once this has been done, authentication ‘access tokens’ are exchanged between the ASPSP and the TPP enabling the service to be carried out. This approach is one that customers will be familiar with (e.g. ‘login with Facebook’, and it will not require unhelpful mixed messages to customers about the use of their credentials. Importantly, this does not affect the retail experience for TPPs as customers don’t have to be re-routed between websites.
This API approach enables a customer-driven experience. The customer is in control of what can and cannot be shared with a third party, as the API is consent and permission-driven. With ‘screen-scraping’, or making credentials accessible, the third party has the ability to access and change any information the customer is able to see and edit, thereby removing the ability for customers to have granular control over what information is shared and for how long. By using encrypted access tokens to authenticate the customer, this removes the burden and security risk from the TPP, making it easier for new entrants without an existing security infrastructure to provide payment services.
Finally, and just as importantly, the EBA should recognise that ‘credentials’ as we currently understand them are already changing. Lots of credentials being used by customers are not capable of being accessed, used and stored by other parties (for example fingerprints or behavioural-based characteristics). The API approach to authentication is therefore a positive move for TPPs as it will enable them to continue to have access to customer information without needing to rely on credentials in the future.
• Accepting the caveat above about the scope of the clarifications (see our answer to question 12), we think the clarifications are generally helpful.
• As noted in para 51D, one of the biggest threats to internet payments is criminals using social engineering techniques over the phone to dupe customers into divulging their authentication codes, PIN, Passwords etc and/or duping the customer to make a fraudulent payment (https://www.youtube.com/watch?v=6yGvO-FefUc). The security recommendations from the EBA won’t ever fully address this issue. Instead, firms (both ASPSPs and TPPs) must play an active role, alongside national authorities, in providing education and ensuring that the system is both simple and safe. Elsewhere in this response we discuss the challenges and risks around customer education and mixed messages where customers are told not to share their credentials but that they can make credentials accessible to certain other parties. We don’t see how it is possible to develop a consistent and coherent message on this basis.
• Although not directly a responsibility of the EBA we believe there remains a requirement for further clarity on liability, specifically in the space of TPPs having access to customer data and (potentially) credentials. For example, whilst there are existing compliance standards for Merchants and Acquirers in handling card and customer data which falls under PCI DSS, one member reported that 70% of all their E-commerce fraud is attributed to data and compliance breaches – yet no action / liability shift is available (i.e. they take the full loss). This cannot be the case for the TPP environment also.
• However, some of our members have the view that allowance should be made for the fact that some credentials can only be used for a specific purpose and therefore the risk of misuse is lessened somewhat. For example, an electronic signature can only be used to authorize a specific account/value transaction. If it was compromised, only the intended transaction could be carried out. Therefore, in this case as the overall risk is lower an argument can be made that there should be more flexibility (if desired) in how these –personalised security credentials are protected. In terms of the reference to sensitive payment data in 52iii, we note that the EBA’s Guidelines on the Security of Internet Payments already defines that access to sensitive payment data must be protected by strong customer authentication. PSD2 Art 4(32) excludes name and account number for AISP’s and PISP’s only, so should these pieces of data still be regarded by ASPSP’s as sensitive information to be protected by strong authentication? The definition of ‘sensitive payment data’ is important and may need further clarification. A default requirement for strong authentication might be acceptable if there is a sufficiently clear framework to allow exceptions where a clear rationale can be given based on assessment of the risk and mitigation processes.
Introductory comments:
We acknowledge that the PSD2 text is set as regards making credentials ‘accessible’ to TPPs (though it’s not clear what this means in practice). However, we do not believe that the aims of PSD2 (i) to give customers control over what information they make available and (ii) to create a multifactor authentication environment, can be properly met by customers providing their credentials to TPPs who will log in on their behalf. Instead, we highlight that by using an API approach there are technological solutions that mean authentication takes place between the ASPSP and customer without introducing friction to the process and yet TPPs will get the full functionality and information that they need.
• ASPSPs and TPPs should own and control the methods by which they authenticate their own customers: PSD2 states that TPPs will ‘rely’ on the authentication methods of ASPSPs for accessing customer account information. As a key principle, ASPSPs and TPPs should own and control the method by which they authenticate their own users. So when a customer is required to authenticate itself to the ASPSP in order to grant a TPP access to its information, this authentication should happen directly between the customer and ASPSP, in whatever way they currently use.
• There are technical mechanisms that already exist and are in use that mean customers don’t need to make their credentials available to any other parties. Overall we recommend an approach of ‘delegation’ rather than ‘impersonation’: To achieve the aims set out by the Commission we do not believe that TPPs (or any other party) need access to a customer’s personalised security credentials. We do not believe that ‘screen-scraping’/ ‘impersonation’ type approaches are appropriate or necessary (crucially they do not allow the customer to have control over precisely what information is shared) (4). We believe that our approach is in line with the PSD2 text under Articles 66 (3b) and 67 (2b) which state that: The payment initiation service provider/ account information service provider shall … (b) ensure that the personalised security credentials of the payment service user are not, with the exception of the user and the issuer of the personalised security credentials, accessible to other parties and that [when] they are transmitted by the [payment initiation service provider/ account information service provider][, this is done] through safe and efficient channels”. Our position also reflects comments made by the European Data Protection Supervisor in their report on the PSD2 proposals in 2013, stating that “the EDPS underlines the importance of implementing the principles of "privacy by design" and "privacy by default" in all data processing systems developed and used under the proposed Directive” (5). We also believe this approach is more appropriate in the context of the new General Data Protection Regulation which was recently agreed.
The technical means now available (e.g. Oauth 2.0 and Open IDConnect, which are predominantly used in the API environment) make it unnecessary for other parties to have access to credentials. These solutions are used securely by some of the biggest companies in the world like Facebook, Google and Amazon. This API approach also enables a customer-driven experience. The customer is in control of what can and cannot be shared with a third party, as the API is consent and permission-driven. With ‘screen-scraping’, or making credentials accessible, the third party has the ability to access and change any information the customer is able to see and edit, thereby removing the ability for customers to have granular control over what information is shared and for how long.
• Once authentication has occurred between the customer and the issuer of the credentials (i.e. the ASPSP) encrypted ‘access tokens’ are exchanged between the ASPSP and the TPP enabling the service to be carried out. This approach is one that customers will be familiar with, and it will not require unhelpful mixed messages to customers about when they can and can’t share their credentials. Importantly, this does not affect the customer experience for TPPs (and any underlying merchants) as customers don’t have to be re-routed between websites.
• Finally, and just as importantly, the EBA should recognise that ‘credentials’ as we currently understand them are already changing. Lots of credentials being used by customers are not capable of being accessed, used and stored by other parties (for example fingerprints or behavioural-based characteristics). The API approach to authentication is therefore a positive move for TPPs as it will enable them to continue to have access to customer information without needing to rely on credentials in the future.
Comments:
• New risks will emerge all the time as criminals adapt their techniques and targets, this is why firms need to be free to innovate and adapt their own security.
• By making customers personalised credentials “accessible” to other parties new attack vectors will be opened up, especially as the market begins to mature. This is why we believe the RTS should require that personalised security credentials are transmitted directly between the customer and the issuer of the credentials for authentication purposes. It is the resulting access tokens that are produced (when using APIs) that can be exchanged between the TPP and ASPSP.
• In the UK in 2014, 47.9% of fraud related to identity fraud and Facility (account) Takeover Fraud (6). We would expect that the use of credentials by TPPs could significantly increase instances of facility (account) takeover fraud (even if that is not happening yet).
• A ‘Cifas 2014 UK Fraud Trends’ report also noted the following:
o With data driven fraud like Identity Fraud dominating, it is unsurprising that technology played a major role in 2014. While the internet offers a fantastic opportunity for fraudsters to attempt fraud on an industrial scale, technology is also the reason behind several successes in preventing fraud.
o The introduction of enhanced security procedures has made it far more difficult for fraudsters to take over existing accounts – demonstrated by the reduction in Facility Takeover Fraud (7), which is down by 38%.
o When fraudsters are being successful they are most commonly using online channels, often facilitated by a phone call. Banks and plastic card issuers have reported that some fraudsters have accessed customer accounts by phoning the customer directly and talking them through the logon process. They purport to be calling from the bank or card issuer, and claim that in order to be able to verify that they are talking to the right person; they need them to confirm their customer number, and so on. The fraudster will then be logging onto their victim’s account as they are talking to them and entering the security details as they are read out.
o In this way, the fraudster can even obtain one time only passcodes from card readers.
o Fraudsters adapt their methods – as one becomes more difficult, a number of other avenues open up. The increased difficulty in gaining access to existing accounts has occurred at the same time that Identity Frauds are increasing. This suggests that as fraudsters find it more difficult to access existing accounts they have focused on opening new ones instead. Additionally, their attention has been turning to convincing their victims to just give them the money directly. This kind of fraud is often called ‘vishing’.
The Payments and Financial Services industries have worked very hard at reducing instances of Facility Takeover Fraud, which has shown to be effective in relation to plastic cards and bank accounts. There is a definite risk of a sharp increase in this specific type of fraud if conflicting messages are given to customers, especially that they can make their personalised security credentials accessible to other parties.
(4) Technology clearly offers an opportunity to provide flexible, tailored financial services, However it is clear that customers are generally considered more financially included, and more confident when they have more ‘cash-like’ control over their financial services. This is also true of control over their data; research shows that consumers clearly have concerns over the misuse of their personal data. Consumer control of their financial services and what data is shared is imperative to the success of PSD2 - http://www.financialinclusioncommission.org.uk/pdfs/fic_report_2015.pdf
(5) Opinion of the European Data Protection Supervisor, 5 December 2013
(6) Cifas, Fraudscape – UK Fraud Trends, 2014: 2: https://www.cifas.org.uk/secure/contentPORT/uploads/documents/External%20-%20Fraudscape%20main%20report%20for%20website.pdf
(7) Facility Takeover Fraud, also known as Account Takeover Fraud, is an identity crime which occurs where a person (the facility hijacker) unlawfully obtains access to the details of their victim (namely an existing account holder or policy holder) and fraudulently operates the account or policy for his or her (or someone else’s) benefit."
• First, as a point of clarification: Our reading of paragraph 52i is that the EBA is considering providing guidance on the full end-to-end process of credential management, including “creation”, “issuance” and “delivery to” the customer”. This would seem to go beyond the remit actually intended for in PSD2 and would impact e.g. how banks issue their PINs to customers, which in many cases is already defined elsewhere, for example, scheme or industry rules. We had understood that the EBA’s remit was around the use of credentials by customers in the context of AIS and PIS.
• As noted elsewhere the RTS should be principles-based in this area to allow for developing technology which may create new, safe methods of enrolment.
• Generally speaking, for the full life cycle of the PSC all processes should be performed by the ASPSP using secure processes.
• As a general point we believe that appropriate security measures are a vital part of ensuring integrity and wide customer adoption. As demonstrated by the recent Ipsos MORI analysis (see introduction) customers place reliance on all actors in the payment chain to have high levels of security.
• Self-certification of technical components or devices hosting, providing access to or transmitting PSCs is not sufficient. While there is some external inspection of certain key components of the payments chain today (e.g. PIN security), in most cases evaluation of these components by third parties is clearly an enhancement to what is required today, but we think this is necessary. Any AIS/PIS solution should be certified and evaluated by third parties analogous to pre-existing processes like GBIC (German Banking Industry Committee) under EMVCo. ASPSPs are already regulated and therefore alternatives for evaluation and certification, like internal assessments, already exist.
• We do not believe that ASPSPs should be responsible for certifying/auditing TPPs.
• However, we believe that the solution implemented by the industry around open standards of communication can be designed to minimise the points at which PSCs are transmitted. For example, through the use of APIs and methods like OAuth, the customer can authenticate through a secure ‘pop-up window’ directly with their ASPSP. For TPPs using this approach, any external audit would only need to confirm that this aspect of their API connection is secure, rather than auditing their whole system where any credentials might be stored.
• Any external evaluations should be based on commonly agreed criteria (agreed openly with a variety of stakeholders at industry level). The RTS should set characteristics only, e.g., define the minimum encryption algorithm requirements.
• Generally speaking, there is high risk in the customer/device segment because customers are the easiest part of the chain for criminals to target.
• However, while it is useful to identify problematic segments we note that the problem has historically been that segmentation of responsibility has taken place. The entire end-to-end system should be considered in relation to protection of PSCs.
• Third parties that collate and store data on behalf of users are likely to become a primary target for criminals. A popular “main player” in this area could potentially hold a significant amount of customer data across multiple ASPSPs. Compromising this single entity could be easier and more lucrative than attacking multiple ASPSP targets. For this reason we remain very concerned about any proposal to give third parties access to customer credentials.
• As a new technology and method of gaining access to customer data, it is likely that cyber-criminals will specifically focus on a more open banking environment as a new attack vector in the future. The ability to amend or make payments will be a specific driver. Attacks are likely to include both exploiting any technical weaknesses that may exist in implementations of the open communication standards, supporting applications and services, or through social engineering of customers who will be unfamiliar with the more open environment.
• Details obtained may be leveraged to effect an account takeover or commit fraud through other channels. This may also provide opportunities for bad actors to exploit users’ naiveté or lack of familiarity with the processes surrounding the new environment to conduct phishing or social engineering attacks.
• In addition to embedding the appropriate structural safeguards including protocols, processes, controls and governance, there is the additional challenge of increasing awareness and “digital literacy” among users (i.e. individuals and businesses).
• The EBA RTS will set high level principles, however they must be capable of recognising, reacting and adapting to emerging risks and threats. We believe that as this ecosystem develops, there should be principles requiring that TPPs and ASPSPs share information on security incidents and fraud. However, this should be done via a central governance authority and possibly anonymised to reduce the risk of further compromise to a particular firm. This will facilitate recognition and help to ensure that any risks can be dealt with in the proper manner.
• We broadly agree with the clarifications under paragraph 63. We especially welcome 63.f which requires each ASPSP to support at least one interoperable interface; rather than mandating the support a myriad of different regimes.
Card-based Payment Instrument Issuers:
• We note that although Card-based Payment Instrument Issuers (PIIs) are mentioned in paragraph 58. However, they are not mentioned in the questions or clarifications of this section. We would welcome further thought and clarification regarding the EBA’s treatment of these players, as they may require an alternative approach which hasn’t yet been articulated fully by the PSD2 text. From our initial analysis of the provisions relating to PIIs there are numerous challenges, costs, risks, and possible shortcomings with the model.
• Ultimately, following the development of principles under the EBA RTS, the industry will need to develop a standardised communication protocol.
• We would welcome clarity on what extent some of the issues concerning consent, communication and liability will be addressed through the EBA RTS or through the framework contract established between the card-based payment instrument issuer and the PSU. There is potential for an API delivered solution.
• With PIIs, the service the ASPSP is providing is a “confirmation” rather than a typical payment service. It is unclear how the PSU will be prompted to notify the ASPSP of his or her consent when signing up to use a payment instrument issued by another provider (e.g. will it be covered in the PIIs terms and conditions?) Is provision of such consent made directly to the ASPSP or could/should it be conveyed via the PII? The extent to which the latter would be feasible or appropriate may also depend on the ASPSP’s willingness to accept consent received in an indirect manner.
• Our interpretation is that any confirmation requests and responses between the parties should be seen as distinct from both the card-based payment transaction (between the PII and the PSU) and the subsequent payment order used to settle i.e. to debit the PSU’s account. This distinction will also have an influence on the relevant responsibilities of the different parties in terms of e.g. authorisation, authentication and liability.
• According to Article 65(2) point (a), the PSP needs to have the payer’s explicit consent before it may request the confirmation. Assuming a continuous authority is given by the PSU when the payment instrument is issued, we think there would still be a need for the ASPSP to verify on a transactional basis that the PSU has given consent.
• In conventional card payments the payee (retailer) receives a payment guarantee when the transaction takes place in contemplation that it will subsequently receive deferred settlement. In many circumstances this would involve generation of an authorisation request that the issuer would approve or decline. Furthermore, in a conventional card payment transaction where the issuer receives and approves an authorisation request transaction they will earmark funds in the account to meet the future transaction, because once approved it is guaranteed. It is clear it is not the intention of the directive to replicate this process.
• Our understanding is that ‘earmarking’ of funds on the PSU’s account is not permitted. We also take this to mean that the ASPSP should treat receipt of a subsequent settlement payment order in the same way it would deal with any other payment order. Thus it would apply its usual AML/sanctions and/or checking/financial crime assessment processes and would also be able to return/refuse the payment if sufficient funds are no longer available at the time the payment order is received even if the ASPSP gave a ‘yes’ response to the original request for confirmation.
• There are no provisions in PSD2 on the security of the payment instrument the PII chooses to offer the PSU. As previously discussed, the ASPSP is required to apply its usual AML and fraud checks. The ASPSP therefore needs to be able to rely on the security of the payment instrument.
• We assume that the EBA Register will need to list authorised PIIs.
Introductory comments:
• We believe that at a high level the EBA RTS should be principles-focused, centring around openness, transparency, accessibility, usability, user control, security, extensibility and interoperability.
• Once the EBA has defined its principles, it should be for the market to implement these at a technical level. Our view is that the market can best achieve the aims of PSD2 through the use of open APIs (Application Programming Interface). The EBA should support the industry to create and adopt open API standards. Overall our view is that the interaction between customers, PISPs, AISPs (which we refer to collectively as Third Party Providers i.e. TPPs) and ASPSPs as described in PSD2 is most effectively achieved via an open API infrastructure. API technology is the accepted norm for secure data-sharing and embedding functionality in an online environment. The use of APIs is widespread and today there are more than 14,000 public APIs available. Alternative technologies for sharing data exist, but are less robust and less secure than APIs.
• We believe that the API standards should be ‘open standards’, developed and maintained collaboratively and transparently. Two main types of standard will need to be developed by the industry: data standards (rules by which data are described and recorded) and API standards (specifications that inform the design, development, security and maintenance of the API). But it is important to understand that API standards are not rigid and unchanging. They can be highly open, flexible, and adaptable, with the ability to be used differently by stakeholders depending on their business model and needs. They will not prevent variation and innovation of new models, but rather enhance and encourage them.
Where possible and practical the industry will seek to reuse existing standards, taxonomies, etc. The open API standards will facilitate the delivery of the Commission’s aims for increased access and innovation. A good ‘developer’ / TPP experience will be an important aspect of ensuring that the new ecosystem works well. To agree this approach an industry body where all types of industry participants have a voice will be required.
• Importance of standardisation and interoperability: Any successful network business depends on common standards. To create a strong network effect the users must be able to interoperate – to communicate in a standardised way. For example, the collaborative payment and clearing infrastructure is a network business which is dependent upon technical and business interoperability. Industry standards are essential for the efficient and resilient operation of the payments industry as well as ensuring that participants and end users interact in a safe, dependable and predictable manner.
o In a global economy of rapidly emerging new technologies, standards help set the rules. Standards can help set a baseline framework that can act as a springboard for quick innovation, commercialisation, continuous change and innovation at less cost and risk.
o If implemented well, standards can improve industry interoperability between counterparties both within a particular jurisdiction as well as cross-border, both in other markets and currencies.
o Standards also reduce the complexity, cost and risk of data manipulation and conversion in the inter-bank space and between banks and their customers. Standards enable competition and have been used as the basis for developing new products and entering new markets (both domestic and external).
o Standards further enable competition by reducing barriers to entry to infrastructure as they provide a common, level playing field for all participants. The implementation of standards does not mean that it forces all participants to conform identically. It creates a landscape that enables flexibility but also consistency.
• Avoiding fragmentation: There will always be a potential for fragmentation in the market. However, we support the aim of reducing fragmentation as far as possible for the benefit of consumers, businesses and providers. It will be a challenge for the market (i.e. all stakeholders, including fintechs, banks and consumer bodies) to come together to design common open standards that work on a pan-European basis, but it can be done with the right support and backing of the regulators and authorities. Ideally, standards should be Europe-wide, but if this proves difficult or slow to agree, it would be preferable to develop national standards with a separate agreement on inter-operability between them.
Comments:
• Broadly speaking we agree that the areas of clarification suggested by the EBA are the right ones. These are areas we covered as part of the work of the in the UK to design an open API in UK banking (see introductory comments for background on this).
• In terms of missing areas of clarification, the main one is the topic of ‘governance’. Logically, if the RTS require common standards of communication, there will need to be a layer of governance around this. This governance is not designed to limit or constrict the ecosystem but rather to help it to flourish. Further details on this are provided below.
• In terms of what each area of clarification should contain, we have provided an Appendix at the end of our response detailing this (based on the work in the UK). Much of the detail relates to the technical implementation of the API solution by the industry (rather than the principles the EBA will set), nevertheless, we feel it is useful for the EBA to get a sense of this in order to better shape the principles in the RTS. As previously mentioned, we strongly encourage the EBA to read the Report that was published on the proposed open API framework for the UK.
a) Define what makes a standard ‘common’ and ‘open’.
• There is no universally accepted definition of an open standard. The definition we have worked to in the UK in the context of the Open Banking Working Group (OBWG) is that an open standard is one developed and maintained collaboratively and transparently, and that can be accessed and used by anyone. We believe that the standard should be made available under a CC014 (8) licence (effectively public domain) to promote its use, reuse and distribution. Failing this, CC-BY15 (9) (attribution) would be recommended.
• The standard should be designed according to the following principles:
o Openness – ensuring accessibility for all interested parties, across a wide range of participants, thereby incentivising adoption, distribution and participation.
o Usability – facilitating ease of implementation and a smooth user experience for participants.
o Interoperability – promoting and progressing towards an environment where data can be exchanged between parties in a frictionless manner across organisational and technological boundaries.
o Reuse – adopting and leveraging existing standards, taxonomies and data lists wherever possible and practicable to avoid duplicative efforts and maximise interoperability.
o Independence – promoting competition among and avoiding dependencies on vendor solutions and technologies; preserving optionality in delivery models and implementation technologies.
o Extensibility – establishing flexibility and encouraging adoptees to build upon the standard and innovate locally, while providing governance mechanisms to subsequently bring extensions “back to the core”.
o Stability – ensuring the provision of a stable environment for all participants where change is communicated, actioned and governed in a transparent and consistent manner.
o Transparency – providing visibility and clarity on issues pertaining to the standard and the environment it operates in (for instance its design, specifications, and governance).
b) The way AIS, PIS providers will have to identify themselves towards the ASPSPs for access to payment account information (e.g. exchange of electronic certificates, see as well chapter 4.5), and every time a payment is initiated including the purpose for which the AIS and/or PIS is authorised by the PSU and requesting access to the ASPSP upon each connection. Such requirements could clarify whether or not trusted third-parties need to provide assurance (e.g. in the form of security assertions) about the identification of entities involved in such communication.
• Authentication is an integral element of any communication standard. We envisage that there are four key authentication scenarios:
o The user authenticating themselves to a TPP;
o The user authenticating themselves to an ASP (in order to authorise a TPP);
o The TPP authenticating themselves to an AS PSP (in order to access a user’s account);
o The TPP authenticating themselves to a user.
• As previously argued, we believe that ASPSPs and TPPs should own and control the method by which they authenticate their own users. The methods by which a TPP authenticates itself to an ASPSP, and a user may identify a TPP, should indeed form part of the guidelines/principles devised by the EBA. As noted in our opening remarks, we believe that as well as authentication, the ASPSP should have a way of confirming, in real-time, that the TPP is appropriately authorised (please see our comments on the EBA Register (or other suitable alternative) in the ‘overarching comments section’). In addition, having the ability to verify that each request is authorised by the TPP is essential for auditing and accountability – using something called Message Authentication Codes (MACs) is a way to achieve this. This helps to provide evidence for situations when each party has a different view of what a transaction intended (e.g. transfer 1k vs transfer 100k).
• In terms of what a solution might look like, we have described this below, in the context of using an API.
• The process by which a user authenticates themselves to an ASPSP in order to authorise the granting of permissions to a TPP will be a tripartite process, which should be designed in a way that minimises digital friction, to avoid discouraging or confusing users. It will potentially involve a hand-off (e.g. pop up window) of user interaction from the TPP to the ASPSP for the authentication to be carried out; the user remains on the TPPs website and continues their interaction with the TPP once the authentication is completed. This approach has the benefit of allowing the ASPSP to continue to own and control the method for authenticating its users (thereby minimising the risk that a TPP could obtain permissions without explicit approval by the user – something required by PSD2) and avoids any complications associated with parties other than the user or ASPSP using the credentials.
• Separately of course, users may also need to identify and authenticate themselves to TPPs in order to gain access to the services or functionality being provided (e.g. signing in to the TPP website). The method used by both ASPSPs and TPPs to authenticate users should be appropriate to adequately protect the data and functionality in question and meet any separate requirements laid down by the EBA RTS in this respect.
• In our view, the tripartite approach outlined above can be facilitated through use of the ‘OAuth 2.0 protocol’ (10 & 11). The OAuth 2.0 protocol supports a variety of different interpretations and styles of interaction, with different security implications, and is used widely by digital companies across the world. The open API standard (to be designed openly and collaboratively by all interested stakeholders) will prescribe how authentication and authorisation aspects of the standard are implemented, so the appropriate levels of consistency, interoperability and security are achieved. For example, something like the OpenID Connect authentication protocol (which provides an identity layer on top of the OAuth 2.0 protocol) be considered as part of this process. More information on OAuth is available in the UK Open API report.
• Having been granted permission to access a customer’s account information and act on the customer’s behalf, there must be a method whereby the TPP can authenticate themselves to the ASPSP during subsequent interactions. OAuth 2.0 solves this through the use of an encrypted access token that is provided by the ASPSP to the TPP at the point at which permission to access an account is granted. The TPP then presents the token to the ASPSP each time it wishes to access the account (this would be beneficial for TPPs as they would not need to rely on re-using a personal credential, which may have changed). ‘Permissions’ are the user’s informed consent for a TPP to obtain data stored by the ASPSP (e.g. an account balance or a list of transactions) or to instruct the ASPSP to carry out some function (e.g. make a payment). The access granted to TPPs should be defined in terms of specific permissions to access data or functionality via the API (this aligns with the overall PSD2 aim to ensure customers have full control over what data they make accessible). Permissions should be mapped to one or more API calls so that, given a specific permission (or set of permissions), it is clear to TPPs which API calls may be accessed.
• It must be remembered that there is a distinction between authentication and authorisation. The OAuth 2.0 model would apply as follows:
o In the course of an interaction with the TPP, the user communicates intent to grant the TPP access to account information held at an ASPSP:
1. The TPP requests access to the user’s account information from the ASPSP;
2. The ASPSP authenticates the user (using its own methods);
3. The ASPSP reviews whether the TPP is authorised to receive the access it is requesting (e.g. via an API call to the EBA Register of by assessing a digital certificate presented by the TPP);
4. The ASPSP displays to the user the access being requested by the TPP;
5. The user reviews the access being requested by the TPP and authorises the ASPSP to grant the requested access to the account information and act on the user’s behalf;
6. The ASPSP grants the TPP the requested access.
• Steps 5 and 6 should not involve the TPP; doing so would provide opportunities for a bad actor to conceal the extent of the access being requested from the user, leading the user to authorise more access than they intended.
• The ASPSP must ensure that no permissions are granted to a TPP without first being displayed to and authorised by the user. The user must have the opportunity to opt not to grant the TPP any or all of the permissions being requested, or to apply relevant limits to any permission (the AS PSP may opt to apply default limits but these should not be overly restrictive).
c) The way PIS, AIS and AS PSPs communicate between themselves and with the PSUs in a secure manner.
• Again, we will describe here how this could be facilitated via an open API approach.
• The use of an open API to facilitate communication between parties is in our view an ideal solution to address the challenges laid out by PSD2. As discussed in our opening remarks, APIs are a mature technology and used widely in most other digital industries.
• In terms of security for the API, again this is fairly mature and there are several means of doing this. In the UK framework report, we recommend the use of HTTP Strict Transport Security (to ensure that API connections should only be made using HTTPS, thus ensuring that all data in transit is encrypted), and Perfect Forward Secrecy (to minimise the impact if session keys are compromised). We also recommend that TLS v1.2 should be used as a minimum, with a defined set of strong cipher suites.
d) The minimum functionalities requirements that the future common and secure open standards of communication will have to provide. This includes for example what kind of information/services can be requested via the standard of communication (e.g. information on the availability of funds or initiation of a payment), how the identification of the account to be accessed and consent of the PSU should be conveyed.
• We do not believe that the EBA should define the detailed functionality of the communication standards (i.e. an open API). Instead, this should be left to the industry to implement through a broad-based governance mechanism. However, the EBA could set a high level view of the functionality requirements for an open standard for secure and open communication between players (i.e. the API) that assures the requirements of PSD2 are met as a de minimis. This would include for example principles regarding:
o The technical functionality of the standard itself
o The data that can be accessed via the API
o Identifiers to be used
The UK open API report made the following recommendations in respect of technical functionality and data:
Technical functionality
• The framework report provides a lot of detail about how an open API standard should be designed and how it should function technically. The report states that the API should comprise the following:
o Use of REST as an architectural style and HTTPS as the transport;
o Use of JSON as the resource format;
o Achievement of Level 2 from the Richardson Maturity Model;13
o Adoption of a vendor and technology independent definition.
o The API standard should comply with the following versioning requirements:
Support for major and minor releases;
Backwards compatibility for all minor – and as far as possible – major releases;
Prescription of minimum support time periods for major releases;
Embedded flexibility/response speed for security or functional errors.
• The API standard should be designed with the following features:
o A controlled core – hosting shared resources should be established and this should represent the slowest-changing part of the standard;
o Local extensions “at the edges” should be permitted, allowing for API provider innovations with subsequent potential incorporation back into the core;
o Specific characteristics allowing API providers to address scalability challenges.
Data
• We believe that an agreed data standard will be required (a reference data model). This is vital to ensuring that common data is made available in a uniform and consistent manner.
• A multi-stakeholder effort will be required to ensure that the data to be accessed is described and defined appropriately.
• Where possible, pre-existing data standards, such as the ISO20022 Financial Repository, should be re-used.
e) The minimum security controls that the future common and secure open standards of communication will have to provide related to the potential unauthorised or fraudulent access to payment accounts or initiation of a payment transaction.
• The UK framework report on an open API in UK banking suggested that further security would be required to protect this new ecosystem. In particular, a new security standard would be required for the server-side (i.e. the protection of customer data at rest). The report recommended a security standards approach be adopted based on the ISO/IEC 27000 series of standards, with a tiered risk-based approach. The report determined that independent auditing against this standard would be required.
• The ISO/IEC 27000 series of standards has achieved widespread adoption, with wide availability of qualified auditors. This approach has the advantage that there is no need for the regulatory authority to conduct audits; instead, it can define the standard that must be met and take advantage of the existing ISO/IEC 27000 ecosystem.
• The servers and infrastructure operated by TPPs and ASPSPs must be protected against cyber-attack. Security standards should mandate security controls that are commensurate with the nature of the data and functionality that is provided (in the case of AS PSPs) or sought (in the case of TPPs). The EBA should define the principles that server-side security should meet rather than any specific technological requirements.
f) the minimum technical requirements that could apply to the common and secure open standards of communication, the minimum reachability requirements for each ASPSPs to provide at least one interoperable interface serving all requirements of the RTS and compliant with PSD2, while AIS and PIS would have to adapt their services to the respective standardised interfaces used.
• As we have previously argued, we believe that, given the requirement for ASPSPs to provide at least one interoperable interface serving all requirement of PSD2 and for PIS/AIS to adapt their services to the respective standardised interface, the best solution is an open API standard. The EBA should provide the principles for this in the RTS.
• The open API report published in the UK provides a detailed view of the technical requirements of such an API. We strongly urge the EBA to review this report.
• The EBA does not need to focus on how the API would technically be designed – the market will solve this. Instead, it should provide the principles required to ensure that API is open, safe and secure, delivers the functionality required under PSD2 and can continue to evolve in order to allow innovation and to keep up with customer needs.
Missing areas - Governance
• In the UK, the open API Framework report proposed that a system of governance would be required. This would ensure the needs of all participants are adequately and equitably addressed and that trust and confidence in the ecosystem is established and maintained. Where personal data, and potentially commercially competitive data, is involved, it is particularly important that all parties understand their rights and obligations in the context of that data. This applies not just at the point of transfer or receipt, but subsequently when that data is retained, reused or even redistributed.
• We believe that the new ecosystem created by PSD2 will require governance. While this may not be something the EBA explicitly opines on (as flagged in paragraph 61, the EBA is not mandated to create the standards or appoint a body to do so) we do believe it is vital that the regulators and authorities publicly acknowledge the need for it and recognise the importance of multi-stakeholder efforts to create an ecosystem that works for all. Clearly there will be challenges, not least as a result of the short timescales and the complexity of pulling together the views of all stakeholders in a comprehensive but practical way. But we believe that effective pan-European governance is absolutely integral to successful implementation of PSD2. In an ideal world, there would be a central EU body which would be able to establish the independent and effective governance model to take account of multi-stakeholder views, which would enable this ecosystem to take effect on a pan-European basis. The next best option would be for a national level governance body with appropriate arrangements for interoperability.
• In our view, at a high level the governance of this new ecosystem should include:
o An overarching mechanism (an “independent authority”) to help to ensure the rights and responsibilities of all participants. Higher standards will mean better outcomes for new entrants and certainty will allow better planning. This body should also help to manage disputes and claims. This is already a complex area and will become more complex with the introduction of TPPs. We do not believe an appropriate body exists at a pan-European level and therefore the industry should seek to stand one up, representing all stakeholders, with the support of the authorities. It would operate according to the following principles:
Be independent of TPPs and data providers (e.g. ASPSPs) to ensure their and customers’ confidence in the ecosystem;
Act transparently;
Enable innovation and participation from participants of all sizes;
Promote the interests of customers in all of its activities;
Facilitate evolution of the ecosystem in line with new technologies and customer needs;
Adopt a risk-based approach.
o The Independent Authority would
Oversee but not define the data, technical and security standards that apply to the ecosystem;
Oversee but not define the standardisation of open data in the UK banking sector;
Create a clear process for issue resolution between participants and an escalation and appeal process;
Establish a process through which interested parties can participate in an advisory capacity to ensure the effective evolution of the ecosystem.
o A multi-stakeholder body to define the open standards, which fairly represents all types of participants. Again, we are not sure that there is a body that is ideally suited to this role at present, though we note that a body like ISO (the International Standards Organisation) may have a role to play.
o A certificate authority/PKI infrastructure to manage the digital certificates that each firm should use to demonstrate their authorisation, and possibly role/status etc. This could be linked to the EBA Register or managed at a national/European level by another independent body (see above (point C) for more information).
o [Please refer to the UK API report for more explanation of the governance proposals].
• While PSD2 states that contracts are not required between TPPs and AS PSPs, the number and variety of obligations that will exist between players, on a pan-European basis, will require coordination. We believe this is something that will greatly benefit customers, new players and incumbents in terms of providing clarity on rights and responsibilities, as well as greatly simplifying the number of bilateral relationships that will need to exist.
• We cannot overstate the importance of TPPs adhering to appropriate security standards. This is by no means intended to act as any kind of barrier to entry, but ensures protections for customers, commensurate with the level of risk associated with the data.
• We welcome the provision in PSD2 for PISPs/AISPs to hold professional indemnity insurance. The overall success of the ecosystem will depend on high quality insurance which is sufficient to cover PISP/AISP liabilities (these could be significant). We suggest this is closely monitored by, for example, requiring PISPs/AISPs to provide evidence of valid insurance cover to be listed as approved, and/or placing an obligation on insurance providers to notify the competent authority in the event that insurance cover lapses. Consideration should also be given to the possibility that the PISP/AISP’s insurer declines to pay out. The consequence would be that a blameless ASP could be left without recourse, though they will have already compensated the customer.
• With any delivery mechanism, we note that further consideration should be given to how business customers will give consent for a third party to make a payment on their behalf, given that there is often more than one payment authoriser (and often a complex matrix of a number). We would be pleased to give this further thought.
(8) See https://creativecommons.org/about/cc0
(9) See https://creativecommons.org/licenses/by/4.0/
(10) http://oauth.net/2/
(11) Wikipedia: “OAuth is an open standard for authorization, commonly used as a way for Internet users to log into third party websites using their Microsoft, Google, Facebook or Twitter accounts without exposing their password. Generally, OAuth provides to clients a 'secure delegated access' to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server”.
Recent related UK experience might be of interest to the EBA as it develops its thinking in this area.
• In Autumn 2014 a report (12) titled “Data sharing and Open Data for banks” was published by the UK Government (HM Treasury) to explore how competition and consumer outcomes in UK banking could be affected by banks giving customers the ability to share their transaction data with third parties using external Application Programming Interfaces (APIs). As part of the work, the report also reviewed how these outcomes would be improved if banks published non-personal data as ‘open data’. The Report set out a number of recommendations:
o That banks should agree an open API standard for third party access.
o Independent guidance should be provided on technology, security and data protection standards that banks can adopt to ensure data sharing meets all legal requirements.
o An industry wide approach should be established to vet third party applications and publish a list of vetted applications as open data.
o Standard data on Personal Current Account terms & conditions should be published by banks as open data.
o Credit data should be made available as open data.
• In February 2015 HM Treasury published a consultation on the Report. In the March Budget, HM Treasury published its statement on the consultation and next steps:
o The Government committed to deliver an open API standard in UK banking;
o It proposed to set out a detailed framework for the design of the open API standard by the end of 2015;
o It believed the development of an API standard that meets the requirements around data protection and security, with reasonable cost, could be feasible in 1 to 2 years.
• Following this, three trade associations (including Payments UK), working with Government, set up a multi-stakeholder group (the Open Banking Working Group – ‘OBWG’) to come up with the framework for the design and delivery of an open API standard in UK banking. The OBWG included a wide range of market participants including Government, TPPs, other fintechs, consumer organisations, businesses and banks.
• The final framework report, which was published on 9 February 2016, provides a high degree of detail on precisely the challenge that is posed by PSD2, namely how to create an ecosystem utilising API infrastructure where customers can permission TPPs to access account data and initiate payments.
• We believe that the role of the EBA RTS is to provide the principles needed to ensure that a standardised ‘communication’ ecosystem between all players (including ASPSPs and TPPs) can emerge. The purpose of this standardised approach is not to force every player to do business in the same way but to provide the common basis that enables differentiation and innovation but with a clear view of rights and responsibilities.
• In the UK our view is that this is best achieved via the implementation of an open API infrastructure.
• This work should also help to support the requirements of the Network and Information Security Directive.
• In the UK, the work that has taken place to create a framework for an open API has taken a big step towards understanding how an ecosystem based on standardised access to bank data and for making payments would work. The report that was published 9 February 2016 is yet to be fully peer reviewed but we expect that the recommendations put forward will form the basis of the implementation of this ecosystem in the UK ahead of the deadlines for PSD2.
• The open API report was written with full consciousness of the emerging requirements of PSD2 and the need to develop a view that would enable UK PSPs to meet their obligations under the Directive, although the scope is wider than PSD2. Furthermore, the recommendations were designed with more than just the UK market in mind, with a European and potentially global outlook. Finally, we note that the OBWG was a fully multi-stakeholder body, involving more than 100 representatives from FinTechs, banks, building societies, consumer bodies, and business.
• We suggest that work in the UK could be used as a template for the wider implementation of the PSD2 ecosystem. The framework report, whilst not a fully comprehensive view, made some significant inroads to understanding how to design and implement an open API in banking and we suggest that the EBA make use of this work as far as possible.
• Please also note that some very valuable research on consumer and small business attitudes to data-sharing was recently published by IPSOS MORI. While nearly 40% reacted positively to the concept of sharing financial data (and aggregation was particularly popular), 30% were wary of the idea, and the remaining nearly 30% were uncertain of the merits. One of the main sources of consumer concern is around security and redress. Consumers demand bank-grade security around their finances, expect some means of financial compensation for security breaches and their bank to be involved in the administration of such claims. Finally, consumers overwhelmingly (77%) believe that third parties accessing their financial data should be regulated (13).
Identification of PSPs
• As well as the TPP authenticating itself to the ASPSP (a requirement of PSD2), there must be a means for ASPSPs to verify the license/authorisation of that TPP in real time. This would also be of benefit to customers.
• As laid out in PSD2 the TPP has a requirement to authenticate itself to the ASPSP. As well as authentication, the ASPSP also needs to be able to verify that the TPP is indeed licensed and able to carry out the services it is requesting access to. We therefore think it is vital that the EBA Register is not a simple text description of accredited companies, but that it has interactive functionality (that could be accessed via e.g. an API).
• This functionality should include a ‘digital certificate’, which can also be attached to communication messages between the TPP and ASPSP. Having a technical mechanism in place to allow the API implementation to verify that the requestor is legitimate is essential. In addition, having the ability to verify that each request is authorised by the TPP is essential for auditing and accountability (using Message Authentication Codes (MACs) is a way to achieve this). This helps to provide evidence for situations when each party has a different view of what a transaction intended. If the EBA Register won’t support Digital Certificates (PKI infrastructure) then something else (that is legally binding) needs to exist that will (this links to the wider governance point below).
• The register will need to be updated in real time and accessible to PSPs with instant response functionality, so that e.g. an ASPSP receiving a request for a payment from its customer and a PISP can immediately verify the PISP holds a current authorisation without delaying the transaction. As such, a real time update of PISPs removed from the register will be just as important an addition if liability is to be distributed, as the PSD2 text envisages.
• In an API environment there is other information that can usefully be stored in such Registers. This could include for example descriptions of the ‘role’ of the firm. This information would provide a description (against agreed parameters) of what that firm does (e.g. accounting software) and what they are authorised to do. Such ‘roles’ can be another powerful tool when used in conjunction with the granular ‘permissions’ that are possible through APIs. When the information about a firm’s role is supplied digitally and in real-time (via a secure digital certificate) to the holder of the data (e.g. an ASPSP) then the data holder is able to have further confidence about the validity of the data/action being requested on behalf of the customer (and importantly relay this information to the customer as part of the permissions-granting process).
• If the Register needs to be housed within another independent body, then this body could act as a central point for dispute resolution/ liability claims which will otherwise be cumbersome and expensive to administer.
(12) https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/382273/141202_API_Report_FINAL.PDF
(13) Ipsos MORI Open API - Exploring the views of consumers and small businesses: https://www.ipsos-mori.com/researchpublications/publications/1769/Open-API-Exploring-the-views-of-consumers-and-small-businesses.aspx
• As mentioned above, we believe technologically it is not necessary for customers to make their personalised security credentials (i.e. their username and password/pin, etc) accessible to anyone. The work in the UK on an open API suggests that through the use of protocols like OAuth and Open IDConnect, customers can authenticate directly with the issuer of the credentials. Based on this work, we believe that there is strong support for designing the open standards such that making credentials available is not required and in fact is gradually phased out as the functionality of the API improves.
• We believe that over time new business models are likely to emerge. It is difficult (and not advisable) to try to predict what these new models might be. Instead, we believe that the approach we have outlined (see Appendix) regarding the development of an open standard that is flexible, with a clear change management framework, will help to ensure that as new innovations and models gain traction and consensus there is a means by which they can be reflected in the standard.
• Nevertheless, we are not asserting that the open API solution is the only solution (only that it appears to us to be the most suitable approach). We respect that other solutions may emerge. Regardless of this, however, the EBA principles should create an environment that is safe and secure yet modern and forward-looking.
• As a general introductory point we think it is important that the EBA is clear on the distinction between electronic identity and electronic authentication (e-IDAS Article 3.1 and Article 3.5). Identification and authentication are two distinct processes and solutions suitable for one are not necessarily interchangeable. Furthermore, distinction needs to clearly be made between the different topics in the discussion paper i.e. strong customer authentication", "protection of the confidentiality and integrity of the PSC" and "secure communication between participating service provider (AISP/PISP/ASPSP)".
• The introduction of the e-IDAS Regulation has been valuable however we question whether it is fully relevant to the implementation of PSD2. For example, we do see value in the standardisation of levels of assurance (implementing act 2015/1502) and believe this to be a positive and necessary step towards interoperability and pan-European integration of digital identity services.
• However, we believe that e-IDAS is not sufficiently equipped to provide an efficient solution for customer authentication in its current state as required by PSD2. As far as we understand, only four member states have so far signed up to e-IDAS. Also, e-IDAS is aimed at public services and government. For example, in the UK, the Government has launched a federated digital identity framework (GOV.UK Verify). Government has defined the rules by which a number of providers can verify a citizen’s identity to an acceptable level of assurance for use to gain access to Government department’s online services. The scheme is not currently intended for use in the private sector.
• The electronic identification mechanisms/schemes regulated by e-IDAS are not useful for the realisation of strong customer authentication within payment services or account information services. As proven by some industry evaluations in Germany the effort and investment for the integration in banking services is very high without any significant advantages. From the point of view of the PSU the usage is also not very convenient. Furthermore, these identification mechanisms/schemes are not generally flexible, i.e. it is not possible to enhance the authentication by elements that are dynamically linked to transaction data.
• Strong customer authentication based on "qualified trust services" like electronic signatures may have some benefits, however, the decision to support/accept electronic signatures should be made by the ASPSP based on its risk management and its business requirements. The use of electronic signatures for strong customer authentication should not be mandated by the RTS."
• As stated previously, we believe the RTS should require that personalised security credentials are transmitted directly between the customer and the issuer of the credentials (i.e. the ASPSP) for authentication purposes. Any resulting access tokens that are produced will be exchanged between the TPP and ASPSP. We therefore think it is more helpful to answer this question by alluding to ‘sensitive payment data’ (PSD2 Article 4 (32), instead of just personalised security credentials.
• We believe that the definitions and principles from e-IDAS behind the use of ‘qualified trust services’ (as distinguished from ‘trust services’) could be considered to address the risks relating to the confidentiality, integrity and availability of sensitive payment data. For example, the use of qualified electronic seals and qualified electronic registered delivery services. In addition, the Qualified Certificates for Website Authentication could be useful for a TPP user to identify that a website offering these services is genuine.
• As we have previously mentioned, we believe that for the future ecosystem to function effectively, firms will need to be assured digitally and in real time about the ‘status’ of TPPs (whether this means their authorisation status under PSD2 or their status as regards to utilisation of a common communication standard). The most obvious solution for this is the use of some kind of ‘digital certificate’.
• In order to establish a secure communication between an AIS/PIS provider and an ASPSP, the firms have to be authenticated securely by each other. As part of this authentication it has to be proven that the AIS/PIS provider has been registered/approved by EBA and that this registration/approval is still valid. In addition, the status/role of the provider should be demonstrated, i.e. whether it is an AIS provider or a PIS provider (since the services an ASPSP has to provide depends on its status). The authentication of PIS/AIS-Provider and ASPSP should be based on electronic seals based on qualified certificates issued by qualified trust service providers under the e-IDAS regulation. For this the EBA should define a policy to be implemented by the qualified trust service provider. Compliance with this policy should assure that:
(a) only a PIS/AIS provider registered/approved by EBA will get a corresponding certificate,
(b) that a parameter contained within the certificate states the role of the certificate owner (i.e. AIS provider or PIS provider or ASPSP),
(c) if the registration/approval of a PIS/AIS provider is withdrawn by the EBA or a national supervision authority the certificate is then cancelled immediately (i.e. in addition to the certificate owner also EBA (or a national supervision authority) has got the right to cancel a certificate). For all other services the use of qualified trust services under the e-IDAS regulation should be optionally and therefore not regulated by the RTS to be prepared by EBA.
• Overall we do not believe that e-IDAS should be wholly relied on by the RTS. However, some elements, for example, qualified trust services, trust marks, etc, could be concepts referred to at a principles level. We do believe however, that as highly regulated entities needing to conduct AML and KYC, PSPs are interested to play a role in understanding how a more consistent approach to identity can be encouraged, which will benefit customers and PSPs.
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.
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.• We respect policy makers and regulators’ desire to enhance consumer protection and guard against fraud. We note that:
o The methods employed by fraudsters change rapidly, especially as new attack vectors open up. It is vital that those seeking to prevent fraud are equally able to adapt their approach.
o As the EBA recognises, there is a constant balance to be found between customer experience and fraud prevention. There is considerable innovation in strong authentication solutions, and it is important to ensure that the principles or standards do not inadvertently stymie their development.
o Principles, guidelines or standards naturally contain a degree of parameter-setting, and no matter how high level, this has the potential to restrict new approaches. We encourage the EBA to retain an ability to re-assess the landscape at intervals, and introduce further flexibility if there is a demonstrable case for it.
• It should be acknowledged that all actions have a potential risk of fraud – the RTS can’t describe every threat. This includes, but is not limited to:
o Change of address or other contact details such as mobile phone/number,
o Stopping and re-ordering a new token,
o Applying for an account,
o Amending white lists of trusted beneficiaries,
o Setting limits on payment functionality.
o Changing the mode of statement delivery or other communications.
o Requesting an overdraft facility or an increase in any existing facility or applying for a new product within online banking.
o Adding new account holders, card holders or administrators to existing accounts
• We want to ensure that the payments environment remains highly secure – banks must be allowed to fulfil e.g. AML requirements and to innovate around security and authentication.
• The EBA principles for the RTS need to be future-proofed and sufficiently flexible. New services and functionality will constantly arise, leading to new types of data and risk, etc. Ultimately our view is that there is not one single approach to strong customer authentication that will work in all scenarios.
• A layered/defence-in-depth approach is vital, no single authentication mechanism or security tool can be relied on solely as these solutions or mechanisms may be circumvented - the PSD2 RTS should require this kind of multi-faceted approach (the experience of the UK banking sector has demonstrated this time and time again).
• It’s not just ‘payment fraud’ on a single online channel that we need to consider, and the outcomes are not limited to ‘financial loss’. For example, risks like ID theft are also key considerations that firms need to mitigate against.
• The EBA should recognise the difference, in particular the fraud risks, between card transactions online and other online transaction types e.g. online banking. For card transactions there is currently no opportunity/mechanism in place to go through strong customer authentication (other than if 3D secure is used) and this is a decision of the retailer/online merchant. We recognise that industry and card schemes will need to work together to ensure some communality of experience (while enabling innovation). There is clearly a need to ensure that retailers/online merchants, card schemes and card issuers and other key stakeholders are also playing a part in ensuring appropriate security.
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?
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?• Generally speaking hardware elements do provide a good solution in the context of strong customer authentication, in terms of proof-of-possession and independence. However, they are not the only solutions. The direction of travel across financial services and other sectors is away from the use of multiple devices. Many customers increasingly expect to perform all aspects of authentication on a single device, e.g. a mobile phone or tablet (1). Accordingly, it would not be appropriate for the EBA RTS principles to require separate hardware tokens. Non-physical software/data tokens are more forward looking options; and indeed these types of solutions have open implementations in the market – for example, ‘Google authenticate’.
• A software key can be regarded as ‘physical’, but will require specific security measures to ensure only the intended user can use it. Where a soft token (authentication data) is stored on a trusted device there should be strong authentication in place to create or migrate the token.
• In fact some banks in the UK already offer software tokens for customer use. Furthermore, given the fact that we may increasingly move towards the use of cryptography and distributed ledger solutions, it is clear that this approach needs to be recognised by the EBA principles.
• We believe that an ASPSP should be able to make its own risk assessment as to whether to accept data as possession element but we greatly welcome its inclusion in the language of the Discussion Paper and encourage the EBA to retain it. This wording provides the basis for the use of innovative and secure strong authentication solutions. To ensure the data can only be controlled by the user, it is important that PSPs introduce controls around access to the data (e.g. to prevent trivial copying of the data and prevent reuse ‘out of context’).
• The RTS should define the characteristics such possession elements must meet. It should not provide a limited list of approved possession elements, but could provide examples.
• One characteristic should be that the possession element must be unique to a customer. Examples include:
o Hardware tokens
o ‘Software creating a One Time Passcode (OTP) in conjunction with the PSU authenticating himself / herself with the software. Providing that there is an adequately protected secret key provided to, or agreed with the customer, during a suitably robust enrolment process.
• The possession element must be some significantly secure item made available by the service provider, or agreed with the user during a suitably robust enrolment process (i.e. agreed or negotiated, not necessarily issued by the PSP). This is important for allow for emerging authentication protocols. The possession element could also be a device the customer uses, but in this case it is critical that is registered/enrolled via a robust process with the ‘owner’ of the authentication (i.e. an ASPSP) and is authenticated/approved by them. There are types of authentication that support a ‘bring your own device’ solution. Under current Discussion Paper wording it is not clear whether they are permissible. For example, paragraph 28 specifies that “at the time of registration for a payment service or payment method, the provision of personalised security credentials involves the recording of authentication elements by the PSP”; but Recital 30 states that “the personalised security credentials used for secure customer authentication by the payment service user or by the payment initiation service provider are usually those issued by the account servicing payment service providers”. We would welcome clarification to ensure these methods are acceptable.
• Possession elements should also include data whose lifecycle is managed by an ASPSP e.g. mobile App, Internet of things (IoT) device enrolment under ASPSP control.
(1) In 2015 Consult Hyperion on behalf of Payments UK released a report, which forecast that within the next five years, widespread mobile adoption aligned with up-and-coming biometric security improvements and regulatory initiatives will lead to a growing emphasis on the mobile phone as the primary means of paying for goods and services and managing accounts. http://www.paymentsuk.org.uk/sites/default/files/The%20Future%20of%20Payments%20Aug%2015.pdf
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?
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?• Behaviour-based characteristics are key in financial services. They can be used both for the physical behaviour of the customer (e.g. location, type of device etc) as well as spending patterns. They can be used before and after a transaction takes place and form a key part of tiered authentication. By being able to assess whether the customer is at home, on their home computer, making the same payment amount to the same payee as last month ASPSPs are able to assess the risk and the level of authentication required. This allows a balance to be reached between security and the ease of the customer experience, which is key in supporting e- commerce. At present behaviour-based characteristics are part of a risk assessment not an authentication factor. However, it is not unreasonable to expect that there could be further developments in this space.
• Behaviour based characteristics can be used to demonstrate inherence but they need to be consistent over a period of time and resilient to changes in platform or application (e.g. my behaviour needs to be the same even though I am using a different mobile device). Behaviours that are truly inherent should be distinguished from preferences, which can change at any time.
• User behaviour is constantly changing, and will change further with the introduction of new services and players (like TPPs). TPPs can themselves also introduce new behaviours (i.e. machine behaviours).
• The technology is developing fast and it has a number of very strong benefits. In particular, because it acts as a kind of ‘invisible’ strong customer authentication, where customers (and criminals) are not aware of what aspects of behaviour are being utilised.
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)?
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 strongly support the clarification that “For strong customer authentication the PSCs can be either a valid combination of these elements themselves or something which is only generated when all the elements have been provided” as this enables the use of OAuth (discussed later in our response) which can be implemented in a highly secure way. We encourage the EBA to retain this language.
• A more dynamic and risk-based framework for strong customer authentication supports future innovation and provides greater scope for customisation by the PSP. The weakest point in the chain will be attacked first and the RTS need to consider the full lifecycle of a user.
• On point 32, we agree that independence is a crucial factor for ensuring strong security. However, we do not believe that independence of devices is necessarily required, so long as there is independence of communication channels on a device the risks can be mitigated. Software-based isolation (e.g. encryption, operating system-based isolation of applications) is secure and can in some instances be as secure as a separate hardware based token. For example, for mobile devices independence can be achieved if the entry of the password and the generation of the transaction code are done by different apps which both exist on the same mobile device.
• It is worth noting that the riskiness of a transaction merits different approaches which the PSP would be best placed to decide upon. For example, if a customer is making a purchase online, using their mobile phone browser, when they want to authenticate a payment they log into a secure token on an app and receive a text message to their mobile phone. The customer can then continue with the payment in the browser (though we note that this will impact on the customer retail experience).
• As previously mentioned under question 2, the market and consumers are increasingly moving towards the use of mobile phones/tablets as their sole device (2). While there are of course some challenges with this approach, we must accept this is becoming the new norm. We are moving into mobile centric interaction for all aspects of finance. We believe that as long as there is independence of communication channels and appropriate levels of security within the device then it is possible to ensure the objectives of strong customer authentication. We therefore feel it would not be appropriate for the EBA RTS to require separate hardware tokens for authentication.
• As an example, in a cards context offline PIN in EMV would violate the requirement for independent devices, but done well it may be more secure than online PIN that is executed badly.
• However, it is clear that as customers move towards using a single device then firms need to be more aware of the externalisation of certain security elements and of the reliance they are placing on the security of other infrastructures (e.g. SMS), which need to be considered fully in any risk analysis. For example, naïve jailbreaking/device rooting can increase risk, and we would encourage device manufacturers to patch vulnerabilities more readily than today, as the market would benefit significantly.
• Finally, we note that there are multiple technologies which underlie a mobile device, for example, NFC, Bluetooth, GPRS, LTE and other developing technologies, all of which are governed and regulated differently. It is therefore worth noting that a mobile should not necessarily be defined as one element in itself (there are multiple layers) and the PSP should be able to decide their own risk-based approach to separate mobile technologies.
(2) Research conducted by BAIN in 2014 (which surveyed roughly 83,000 consumers in 22 countries to reach its conclusions) stated that “Banking customers now handle more of their banking interactions, on average, via smartphones and tablets than through any other channel”. http://www.bain.com/publications/articles/customer-loyalty-in-retail-banking-2014-global.aspx
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?• This is a difficult question to answer fully without a clear definition of dynamic linking in PSD2.
• One notable challenge is that in some contexts such as card transactions, strong customer authentication would begin on retailers’ websites. We would advocate that the EBA engage more directly with the retail community, regarding their shared role (particularly in the e-commerce space) in delivering a strong customer authentication environment.
• The distinction between strong authentication and dynamic linking is important. While we support strong authentication, dynamic linking is only relevant and helpful in limited circumstances.
• We would welcome clarity as to the purpose of dynamic linking to help us understand its application to remote electronic payments. PSD2 text suggests that it should be used “to make the user aware, at all times, of the amount and the payee of the transaction that the user is authorising”. The EBA Discussion Paper suggests its purpose is to provide “a high assurance that the PSU has been identified and is authorising a specific payment transaction”. These appear to be different aims, which would therefore impact the kinds of solutions and risk mitigants that would be acceptable.
• If making the user aware of the amount and payee is the objective, we question whether dynamic linking should ever be required for retailer-generated payments (like online card payments), and would encourage the EBA to exempt them from scope. For example, if a customer wishes to pay ‘Retailer x’ €200 for a flight; they will be very aware that this is the transaction they are authorising. From a fraud perspective, there is also very limited scope for a ‘man-in-the middle’ type attack.
• We note that some solutions that enable dynamically linking provide the user with visibility of the payee and amount, while others do not. Solutions where the user has to input this data do not offer any fraud prevention benefit beyond the other kind (a nefarious actor would just input the same data twice) but the customer journey contains far more friction (so causes a negative impact on e-commerce). If some form of dynamic fraud protection is required to prevent fraud (a different purpose to user awareness), a unique dynamic code offers as much protection as a dynamically linked code, but has a far better customer experience – and is therefore less detrimental to e-commerce.
• In relation to mobile banking applications, the use of cryptographic keys should be considered as a form of dynamic linking. These provide, by way of comparison, considerably greater security than one-time passcodes.
• With an evolving market, the RTS should provide discretion for PSPs to determine how they implement dynamic linking of a transaction and also to determine whether the dynamic linking of a transaction is made visible to the PSU.
• A key exemption will be around “low risk transactions”. Some providers have sophisticated tools for transaction and customer analysis which can be far more powerful than dynamic linking in confirming the identity of the customer and the likelihood of fraud. The ability to “step-up” authentication based on the risk of an individual transaction is key to the smooth functioning of electronic payments whilst ensuring that customers are protected from fraud.
• There is uncertainty around dynamic linking for bulk payments i.e. payment files that will contain multiple individual payments and thus multiple payees and amounts. It is not unusual for a bank to receive a batch payment file of 50,000 individual payments. Bulk payments which are awaiting verification by a second authorizer requires consideration – a relevant dynamic link may be beneficial but discussion on which values to employ is required. With any additional requirements, the EBA should consider the degree of change to customer experience and the impact this may have on the businesses concerned.
• In terms of the comments in paragraph 35 regarding difficulties for dynamic linking where the amount is not known, we suggest that if an amount is not available, this can be set by default to zero.
• We understand that the dynamic linking requirement applies to ‘remote electronic payment transactions’, and that PSD2 states that a ‘remote payment transaction’ is a payment transaction initiated via the internet or through a device that can be used for distance communication (but excludes non-electronic payments such as mail, paper-based and telephony). It is always difficult to define something by what it is not, therefore the definition of a remote electronic payment is challenging. We believe, though would welcome clarification, that the following are out of scope for dynamic linking:
o Video-banking, as this would be considered in the same way as telephony;
o Phone calls made from mobile phones (these could potentially be caught as a device that can be used for distance communication, though we do not believe this was the intention).
o Payments initiated at ATMs. While the networks that support these machines use phone lines, internet access and central computers to distribute information and facilitate transactions, there are specific fraud protections that apply to ATMs. ATM networks are walled ecosystems where operators have to adhere to robust requirements to protect the physical security of their devices and user credentials. This means that the risks associated with activity that happens on them are vastly different, for example, to online activity (in the commonly used sense of the term). The control environment around the operation of ATMs is extremely stringent and we would encourage the EBA to seek assurance from the schemes with regards to annual attestations to confirm the adequacy of the cryptographic control environment. Due to the different risk profile ATMs present, we encourage the EBA to consider excluding them from dynamic linking requirements. We would add that the profile of customers who use ATMs is far wider than those who use online banking, so the consequences of a big change in process (without a discernible fraud prevention benefit) is worthy of consideration.
o Point of Sale transactions, as these are not ‘remote’.
• A more general point is that any dynamic code must not be able to be used to authenticate further fraudulent activity or be of use if it (alone) is compromised.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?• No solution could ever be 100% secure. We appreciate the EBA’s recognition that there are trade-offs between security and customer experience, and would caution that all activity carries some form of risk. The challenge is to mitigate it in a proportionate way rather than eliminate it completely. Total assurance that customers have sole control and/or sole visibility of any communication from the PSP is simply not realistic; SMS, email, voice calls and other forms of communications are all vulnerable to compromise.
• There are different levels of independence and dynamic linking; generally higher levels of independence and dynamic linking are used for ‘higher risk’ activity. It is important that this tiered approach, in conjunction with a risk-based analysis by individual PSPs, is maintained. Divergent approaches to methods of authentication by different PSPs ensure that it is more difficult for fraud to take place.
• Firms make decisions on which solutions to use based on individual risk assessments and an understanding of their customer base.
• It is for these reasons that any one particular solution for the authentication of mobile devices should not be endorsed. This is both to maintain secure means of authentication, but also to allow more innovative forms of authentication to continue to develop.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?• We broadly consider the clarifications suggested as useful.
• However, in general, we would prefer the clarifications to be considered non-exhaustive and based on principles, as this would support the ability for PSPs to take a risk-based approach. Risk appetite is often dynamic and driven by the PSP and the environmental considerations (e.g. high usage, heightened fraud activity, the emergence of new attack vectors). At a principles level, the EBA could consider the following:
o Exemptions should balance the need for stronger authentication with minimal customer friction.
o Exemptions should include where stronger authentication has already been achieved within the same session and there are no further opportunities for fraudulent activity (e.g. a payment) – there is little value add to doing this again.
o Exemptions should include where the customer is strongly recognised e.g. the same device that is established for that customer (and not for any other customer).
o Exemptions can include where no sensitive or risky transactional capability exists post authentication (or where step up authentication is then required to perform this sort of activity).
• In terms of point 42B on whitelists, we think that this concept is already well-explained in the Security of Internet Payments guidelines (7.1), allowing alternative customer authentication measures for “outgoing payments to trusted beneficiaries included in a previously established white list for that customer”. Transactions against a whitelisted beneficiary should in themselves not require strong authentication (this exemption is part of the Guidelines and the RTS should reflect that). Manipulation of the white list would require strong authentication per PSD2 Article 97(1c).
• We appreciate the EBA’s intention to exempt “low value payments”, and appreciate that this is intended to be “as defined in the PSD”. We would welcome clarity as to the interpretation. The PSD2 wording refers to low value payments “In cases of payment instruments which, according to the relevant framework contract, concern only individual payment transactions that do not exceed EUR 30”. We believe the intention is to provide an exemption for both (i) payments below EUR 30 (or the level set by Member States) and (ii) low value payment instruments (for example, contactless wearables).
• While not an exemption as such, in terms of the EBA’s mandate to cover strong authentication when logging in to online banking we would suggest that the RTS should be clear that strong authentication at login should only be required for a login that gives access to sensitive information and/or transactional capability (unless exempt). A risk-based authentication can give access to non-sensitive information. Sensitive information should only be accessed after at least one strong authentication during the session (must not be by default at login). A default of strong authentication might be acceptable if there is a sufficiently clear framework to allow exceptions where a clear rationale can be given based on assessment of the risk and mitigation processes.
• We would encourage the exemptions to be kept at a relatively high-level to enable PSPs themselves to analyse what is deemed a low-risk transaction (we expand on this in our response to Q9).
• We would welcome clarity on the treatment of virtual cards. The Discussion Paper suggests that the ‘setting up of limits or the generation of virtual cards’ are within scope. We believe this means that the Administrator of a virtual card needs to be strongly authenticated when they set up the log-in numbers for Users on the system; but that the Users do not need to be strongly authenticated when they use the numbers. If this is not the intention, we would suggest that virtual cards could be considered for exemption as a “specific-purpose instrument”.
• There is also a question as to whether the intention is to include ‘point of sale’ transactions. This is particularly relevant for contactless payments where ease of use is the key customer benefit and innovative quality. There are safeguards in place to protect the customer, including the requirement to put in a PIN after a number of transactions and automatic refunds for any disputed payments; and of course higher value contactless payments would be supported by PIN entry or, e.g. in the case of mobile phone based solutions, a biometric authentication step. While we appreciate that low value payments are out of scope, we would encourage the EBA to consider a broader exemption for contactless payments.
• Our reading of the EBA discussion paper is that direct debits are included within the exemptions (albeit strong authentication may be required for the set-up of the direct debit instruction/collection of the first direct debit). It would be useful if the EBA could clarify this point; we note that direct debits offer other safeguards which mean the concept of Strong Authentication may have less applicability in this type of payment than others. This often includes, for example, a customer alert when a direct debit is first taken. There are complexities in application of strong authentication to Direct Debits, even the first set up. This is because a direct debit originator (e.g. a utility company) is the one to interact with the customer - rather than the PSP - but they do not have the depth of customer relationship that would enable them to easily strongly authenticate the customer. If a change were required to bring the PSP into this process (or for originators to start performing this kind of service), it would add friction to the customer experience and may undermine the use of electronic direct debits and encourage the use of the paper version. The impact on originators would need to be considered – i.e. the business community.
• Aside from specific potential exemptions, we would welcome clarification on the liability model for exempt activities. We appreciate that “where the payer’s PSP does not require strong customer authentication, the payer shall not bear any financial losses unless the payer has acted fraudulently. Where the payee or the PSP of the payee fails to accept strong customer authentication, it shall refund the financial damage caused to the payer’s payment service provider”. We would imagine that the liability model for exemptions would clarify that where a PSP is exempted from requiring strong authentication, the provisions in Article 4 1 would apply.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?Introductory comments:
• Security and integrity of the payment systems are of the utmost importance: The payments industry believes that the security and integrity of the payments system is of the highest importance, not only for general economic stability but in terms of ensuring continued high consumer confidence (3). The industry works most effectively when it is able to respond dynamically and quickly to new and emerging threats. Increasingly criminals are taking advantage of the availability of customer data in order to effect fraud and other criminal activities. To highlight this, we note that in the UK in Q3 2015 alone, there was a 147% increase in data hacks / compromise incidents. A top 4 UK retail Bank reported that their organisation had seen a very significant increase (circa 50%) in card fraud that emanated from data compromise. This is why we stress throughout this response the vital importance of putting in place processes that can enable the legislative aims of PSD2 but which nevertheless allow PSPs to maintain high levels of security, integrity, protection of customer data and customer control.
• The areas of security and authentication are highly complex and are constantly developing. We believe the EBA should design the RTS at a high level and not try to define detailed ‘technical implementation standards’: The risk of the EBA being too prescriptive is that the industry will be hampered from responding and reacting to cybercrime and fraud threats adequately and the requirements will be quickly outdated, and it may be more difficult to innovate.
(3) The Commission Communication on the Digital Single Market: factsheet for the UK stated that 39% of the UK (43% EU) are concerned about someone misusing their personal data and 49% of the UK (42% EU) are concerned about the security of online payments
Comments:
• There should be an exemption for recurring transactions. Although recurrence is mentioned in paragraph 41 it is not listed in the exemptions in paragraph 42 (this may just be an oversight).
• Generally speaking, we believe that the EBA Security Guidelines published in 2014 provide a good basis for the RTS, especially as the industry is already working towards implementing these.
• Some of our members suggested that potentially the EBA could consider a tiered approach. An example is given below:
o Transactions not requiring strong authentication, e.g., a mobile app only requiring user-id user-password, allowing only small amount transfers (with a weekly/monthly max); or, logging on when there is no ability to access sensitive data.
o Transactions requiring strong authentication but no “dynamic linking”, e.g., payments to ASPSP-identified utility providers (e.g., electricity company) or payments initiated via an ATM
o Transactions requiring strong authentication with “dynamic linking” e.g., ad-hoc high value transfer
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?
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?• We don’t think the three points highlighted in paragraph 45 should be considered exhaustive and don’t believe a prescriptive list is needed. Firms will take into account a wide range of aspects when analysing risk and these will change and adapt as the ecosystem changes. Firms need to constantly react to new and unforeseen changes in circumstances. If the list is intended to be definitive, we would encourage the EBA to clarify that firms may carry out their risk-based analysis by taking any of them into account, and not all of them (‘or’ rather than ‘and’).
• PSPs should take a risk-based approached to customer authentication and transactions, a one-size-fits-all solution or procedure is not practical and will hamper innovation and damage the customer journey (the experience of the UK banking sector has demonstrated the benefits of this approach in the context of balancing customer experience with security).
• The principle around risk analysis should be that the processes must adhere to generally/widely recognised/defined risk methodologies and could be demonstrated to an auditor.
• Other examples which could be added to the EBA’s points in paragraph 45 include, for example, reference to lists of known fraudulent accounts, and the interplay with AML requirements regarding transaction screening, which ASPSPs must already conduct, etc.
• We are supportive of the language around ‘customer device used’. Mobile applications (like mobile banking or person-to-person payment apps) can be specific to the device they are installed onto – such that if a different device was used to attempt a log-in to the app using the genuine PSU’s credentials, it would be refused. Where this protection is absent, they often also involve the use of data that tightly binds the application to the device, adding an extra layer of security. The ability of firms to consider the risk of the customer device used is important.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
10. Do you consider the clarifications suggested regarding the protection of users personalised security credentials to be useful?We do not believe that the aims of PSD2 to (i) give customers control over what information they make available or (ii) create a multifactor authentication environment, can be properly met by customers making their credentials accessible to TPPs who will log in on their behalf. Instead, we believe that by using an API approach there are technological solutions that mean credentials are only used between the ASPSP and customer and yet TPPs will get the full functionality and information they need.
As a key principle, ASPSPs and TPPs should own and control the method by which they authenticate their own users. So when a customer is required to authenticate itself to the ASPSP in order to grant a TPP access to its information, this authentication should happen directly between the customer and ASPSP, in whatever way they currently use. We do not believe that ‘screen-scraping’/ ‘impersonation’ type approaches are secure or appropriate (they also do not allow customer to have a granular degree of control over what information is shared).
There are technical means available that already exist and are in use that mean customers don’t need to make their credentials available to any other parties. Overall we recommend an approach of ‘delegation’ rather than ‘impersonation’.
These technical means now available (e.g. Oauth 2.0 and Open IDConnect, which are predominantly used in the API environment) make it unnecessary for other parties to have access to credentials. These solutions are used securely by some of the biggest companies in the world like Facebook, Google and Amazon.
As an example, using the scenario of an API utilising OAuth 2.0, when the customer is on the TPP website they would simply be presented with a pop-up window that allows them to authenticate directly with the issuer of the credentials (in this case the ASPSP). Once this has been done, authentication ‘access tokens’ are exchanged between the ASPSP and the TPP enabling the service to be carried out. This approach is one that customers will be familiar with (e.g. ‘login with Facebook’, and it will not require unhelpful mixed messages to customers about the use of their credentials. Importantly, this does not affect the retail experience for TPPs as customers don’t have to be re-routed between websites.
This API approach enables a customer-driven experience. The customer is in control of what can and cannot be shared with a third party, as the API is consent and permission-driven. With ‘screen-scraping’, or making credentials accessible, the third party has the ability to access and change any information the customer is able to see and edit, thereby removing the ability for customers to have granular control over what information is shared and for how long. By using encrypted access tokens to authenticate the customer, this removes the burden and security risk from the TPP, making it easier for new entrants without an existing security infrastructure to provide payment services.
Finally, and just as importantly, the EBA should recognise that ‘credentials’ as we currently understand them are already changing. Lots of credentials being used by customers are not capable of being accessed, used and stored by other parties (for example fingerprints or behavioural-based characteristics). The API approach to authentication is therefore a positive move for TPPs as it will enable them to continue to have access to customer information without needing to rely on credentials in the future.
• Accepting the caveat above about the scope of the clarifications (see our answer to question 12), we think the clarifications are generally helpful.
• As noted in para 51D, one of the biggest threats to internet payments is criminals using social engineering techniques over the phone to dupe customers into divulging their authentication codes, PIN, Passwords etc and/or duping the customer to make a fraudulent payment (https://www.youtube.com/watch?v=6yGvO-FefUc). The security recommendations from the EBA won’t ever fully address this issue. Instead, firms (both ASPSPs and TPPs) must play an active role, alongside national authorities, in providing education and ensuring that the system is both simple and safe. Elsewhere in this response we discuss the challenges and risks around customer education and mixed messages where customers are told not to share their credentials but that they can make credentials accessible to certain other parties. We don’t see how it is possible to develop a consistent and coherent message on this basis.
• Although not directly a responsibility of the EBA we believe there remains a requirement for further clarity on liability, specifically in the space of TPPs having access to customer data and (potentially) credentials. For example, whilst there are existing compliance standards for Merchants and Acquirers in handling card and customer data which falls under PCI DSS, one member reported that 70% of all their E-commerce fraud is attributed to data and compliance breaches – yet no action / liability shift is available (i.e. they take the full loss). This cannot be the case for the TPP environment also.
• However, some of our members have the view that allowance should be made for the fact that some credentials can only be used for a specific purpose and therefore the risk of misuse is lessened somewhat. For example, an electronic signature can only be used to authorize a specific account/value transaction. If it was compromised, only the intended transaction could be carried out. Therefore, in this case as the overall risk is lower an argument can be made that there should be more flexibility (if desired) in how these –personalised security credentials are protected. In terms of the reference to sensitive payment data in 52iii, we note that the EBA’s Guidelines on the Security of Internet Payments already defines that access to sensitive payment data must be protected by strong customer authentication. PSD2 Art 4(32) excludes name and account number for AISP’s and PISP’s only, so should these pieces of data still be regarded by ASPSP’s as sensitive information to be protected by strong authentication? The definition of ‘sensitive payment data’ is important and may need further clarification. A default requirement for strong authentication might be acceptable if there is a sufficiently clear framework to allow exceptions where a clear rationale can be given based on assessment of the risk and mitigation processes.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?Introductory comments:
We acknowledge that the PSD2 text is set as regards making credentials ‘accessible’ to TPPs (though it’s not clear what this means in practice). However, we do not believe that the aims of PSD2 (i) to give customers control over what information they make available and (ii) to create a multifactor authentication environment, can be properly met by customers providing their credentials to TPPs who will log in on their behalf. Instead, we highlight that by using an API approach there are technological solutions that mean authentication takes place between the ASPSP and customer without introducing friction to the process and yet TPPs will get the full functionality and information that they need.
• ASPSPs and TPPs should own and control the methods by which they authenticate their own customers: PSD2 states that TPPs will ‘rely’ on the authentication methods of ASPSPs for accessing customer account information. As a key principle, ASPSPs and TPPs should own and control the method by which they authenticate their own users. So when a customer is required to authenticate itself to the ASPSP in order to grant a TPP access to its information, this authentication should happen directly between the customer and ASPSP, in whatever way they currently use.
• There are technical mechanisms that already exist and are in use that mean customers don’t need to make their credentials available to any other parties. Overall we recommend an approach of ‘delegation’ rather than ‘impersonation’: To achieve the aims set out by the Commission we do not believe that TPPs (or any other party) need access to a customer’s personalised security credentials. We do not believe that ‘screen-scraping’/ ‘impersonation’ type approaches are appropriate or necessary (crucially they do not allow the customer to have control over precisely what information is shared) (4). We believe that our approach is in line with the PSD2 text under Articles 66 (3b) and 67 (2b) which state that: The payment initiation service provider/ account information service provider shall … (b) ensure that the personalised security credentials of the payment service user are not, with the exception of the user and the issuer of the personalised security credentials, accessible to other parties and that [when] they are transmitted by the [payment initiation service provider/ account information service provider][, this is done] through safe and efficient channels”. Our position also reflects comments made by the European Data Protection Supervisor in their report on the PSD2 proposals in 2013, stating that “the EDPS underlines the importance of implementing the principles of "privacy by design" and "privacy by default" in all data processing systems developed and used under the proposed Directive” (5). We also believe this approach is more appropriate in the context of the new General Data Protection Regulation which was recently agreed.
The technical means now available (e.g. Oauth 2.0 and Open IDConnect, which are predominantly used in the API environment) make it unnecessary for other parties to have access to credentials. These solutions are used securely by some of the biggest companies in the world like Facebook, Google and Amazon. This API approach also enables a customer-driven experience. The customer is in control of what can and cannot be shared with a third party, as the API is consent and permission-driven. With ‘screen-scraping’, or making credentials accessible, the third party has the ability to access and change any information the customer is able to see and edit, thereby removing the ability for customers to have granular control over what information is shared and for how long.
• Once authentication has occurred between the customer and the issuer of the credentials (i.e. the ASPSP) encrypted ‘access tokens’ are exchanged between the ASPSP and the TPP enabling the service to be carried out. This approach is one that customers will be familiar with, and it will not require unhelpful mixed messages to customers about when they can and can’t share their credentials. Importantly, this does not affect the customer experience for TPPs (and any underlying merchants) as customers don’t have to be re-routed between websites.
• Finally, and just as importantly, the EBA should recognise that ‘credentials’ as we currently understand them are already changing. Lots of credentials being used by customers are not capable of being accessed, used and stored by other parties (for example fingerprints or behavioural-based characteristics). The API approach to authentication is therefore a positive move for TPPs as it will enable them to continue to have access to customer information without needing to rely on credentials in the future.
Comments:
• New risks will emerge all the time as criminals adapt their techniques and targets, this is why firms need to be free to innovate and adapt their own security.
• By making customers personalised credentials “accessible” to other parties new attack vectors will be opened up, especially as the market begins to mature. This is why we believe the RTS should require that personalised security credentials are transmitted directly between the customer and the issuer of the credentials for authentication purposes. It is the resulting access tokens that are produced (when using APIs) that can be exchanged between the TPP and ASPSP.
• In the UK in 2014, 47.9% of fraud related to identity fraud and Facility (account) Takeover Fraud (6). We would expect that the use of credentials by TPPs could significantly increase instances of facility (account) takeover fraud (even if that is not happening yet).
• A ‘Cifas 2014 UK Fraud Trends’ report also noted the following:
o With data driven fraud like Identity Fraud dominating, it is unsurprising that technology played a major role in 2014. While the internet offers a fantastic opportunity for fraudsters to attempt fraud on an industrial scale, technology is also the reason behind several successes in preventing fraud.
o The introduction of enhanced security procedures has made it far more difficult for fraudsters to take over existing accounts – demonstrated by the reduction in Facility Takeover Fraud (7), which is down by 38%.
o When fraudsters are being successful they are most commonly using online channels, often facilitated by a phone call. Banks and plastic card issuers have reported that some fraudsters have accessed customer accounts by phoning the customer directly and talking them through the logon process. They purport to be calling from the bank or card issuer, and claim that in order to be able to verify that they are talking to the right person; they need them to confirm their customer number, and so on. The fraudster will then be logging onto their victim’s account as they are talking to them and entering the security details as they are read out.
o In this way, the fraudster can even obtain one time only passcodes from card readers.
o Fraudsters adapt their methods – as one becomes more difficult, a number of other avenues open up. The increased difficulty in gaining access to existing accounts has occurred at the same time that Identity Frauds are increasing. This suggests that as fraudsters find it more difficult to access existing accounts they have focused on opening new ones instead. Additionally, their attention has been turning to convincing their victims to just give them the money directly. This kind of fraud is often called ‘vishing’.
The Payments and Financial Services industries have worked very hard at reducing instances of Facility Takeover Fraud, which has shown to be effective in relation to plastic cards and bank accounts. There is a definite risk of a sharp increase in this specific type of fraud if conflicting messages are given to customers, especially that they can make their personalised security credentials accessible to other parties.
(4) Technology clearly offers an opportunity to provide flexible, tailored financial services, However it is clear that customers are generally considered more financially included, and more confident when they have more ‘cash-like’ control over their financial services. This is also true of control over their data; research shows that consumers clearly have concerns over the misuse of their personal data. Consumer control of their financial services and what data is shared is imperative to the success of PSD2 - http://www.financialinclusioncommission.org.uk/pdfs/fic_report_2015.pdf
(5) Opinion of the European Data Protection Supervisor, 5 December 2013
(6) Cifas, Fraudscape – UK Fraud Trends, 2014: 2: https://www.cifas.org.uk/secure/contentPORT/uploads/documents/External%20-%20Fraudscape%20main%20report%20for%20website.pdf
(7) Facility Takeover Fraud, also known as Account Takeover Fraud, is an identity crime which occurs where a person (the facility hijacker) unlawfully obtains access to the details of their victim (namely an existing account holder or policy holder) and fraudulently operates the account or policy for his or her (or someone else’s) benefit."
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?
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?• First, as a point of clarification: Our reading of paragraph 52i is that the EBA is considering providing guidance on the full end-to-end process of credential management, including “creation”, “issuance” and “delivery to” the customer”. This would seem to go beyond the remit actually intended for in PSD2 and would impact e.g. how banks issue their PINs to customers, which in many cases is already defined elsewhere, for example, scheme or industry rules. We had understood that the EBA’s remit was around the use of credentials by customers in the context of AIS and PIS.
• As noted elsewhere the RTS should be principles-based in this area to allow for developing technology which may create new, safe methods of enrolment.
• Generally speaking, for the full life cycle of the PSC all processes should be performed by the ASPSP using secure processes.
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?
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?• As a general point we believe that appropriate security measures are a vital part of ensuring integrity and wide customer adoption. As demonstrated by the recent Ipsos MORI analysis (see introduction) customers place reliance on all actors in the payment chain to have high levels of security.
• Self-certification of technical components or devices hosting, providing access to or transmitting PSCs is not sufficient. While there is some external inspection of certain key components of the payments chain today (e.g. PIN security), in most cases evaluation of these components by third parties is clearly an enhancement to what is required today, but we think this is necessary. Any AIS/PIS solution should be certified and evaluated by third parties analogous to pre-existing processes like GBIC (German Banking Industry Committee) under EMVCo. ASPSPs are already regulated and therefore alternatives for evaluation and certification, like internal assessments, already exist.
• We do not believe that ASPSPs should be responsible for certifying/auditing TPPs.
• However, we believe that the solution implemented by the industry around open standards of communication can be designed to minimise the points at which PSCs are transmitted. For example, through the use of APIs and methods like OAuth, the customer can authenticate through a secure ‘pop-up window’ directly with their ASPSP. For TPPs using this approach, any external audit would only need to confirm that this aspect of their API connection is secure, rather than auditing their whole system where any credentials might be stored.
• Any external evaluations should be based on commonly agreed criteria (agreed openly with a variety of stakeholders at industry level). The RTS should set characteristics only, e.g., define the minimum encryption algorithm requirements.
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?
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?• Generally speaking, there is high risk in the customer/device segment because customers are the easiest part of the chain for criminals to target.
• However, while it is useful to identify problematic segments we note that the problem has historically been that segmentation of responsibility has taken place. The entire end-to-end system should be considered in relation to protection of PSCs.
• Third parties that collate and store data on behalf of users are likely to become a primary target for criminals. A popular “main player” in this area could potentially hold a significant amount of customer data across multiple ASPSPs. Compromising this single entity could be easier and more lucrative than attacking multiple ASPSP targets. For this reason we remain very concerned about any proposal to give third parties access to customer credentials.
• As a new technology and method of gaining access to customer data, it is likely that cyber-criminals will specifically focus on a more open banking environment as a new attack vector in the future. The ability to amend or make payments will be a specific driver. Attacks are likely to include both exploiting any technical weaknesses that may exist in implementations of the open communication standards, supporting applications and services, or through social engineering of customers who will be unfamiliar with the more open environment.
• Details obtained may be leveraged to effect an account takeover or commit fraud through other channels. This may also provide opportunities for bad actors to exploit users’ naiveté or lack of familiarity with the processes surrounding the new environment to conduct phishing or social engineering attacks.
• In addition to embedding the appropriate structural safeguards including protocols, processes, controls and governance, there is the additional challenge of increasing awareness and “digital literacy” among users (i.e. individuals and businesses).
• The EBA RTS will set high level principles, however they must be capable of recognising, reacting and adapting to emerging risks and threats. We believe that as this ecosystem develops, there should be principles requiring that TPPs and ASPSPs share information on security incidents and fraud. However, this should be done via a central governance authority and possibly anonymised to reduce the risk of further compromise to a particular firm. This will facilitate recognition and help to ensure that any risks can be dealt with in the proper manner.
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?
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?• We broadly agree with the clarifications under paragraph 63. We especially welcome 63.f which requires each ASPSP to support at least one interoperable interface; rather than mandating the support a myriad of different regimes.
Card-based Payment Instrument Issuers:
• We note that although Card-based Payment Instrument Issuers (PIIs) are mentioned in paragraph 58. However, they are not mentioned in the questions or clarifications of this section. We would welcome further thought and clarification regarding the EBA’s treatment of these players, as they may require an alternative approach which hasn’t yet been articulated fully by the PSD2 text. From our initial analysis of the provisions relating to PIIs there are numerous challenges, costs, risks, and possible shortcomings with the model.
• Ultimately, following the development of principles under the EBA RTS, the industry will need to develop a standardised communication protocol.
• We would welcome clarity on what extent some of the issues concerning consent, communication and liability will be addressed through the EBA RTS or through the framework contract established between the card-based payment instrument issuer and the PSU. There is potential for an API delivered solution.
• With PIIs, the service the ASPSP is providing is a “confirmation” rather than a typical payment service. It is unclear how the PSU will be prompted to notify the ASPSP of his or her consent when signing up to use a payment instrument issued by another provider (e.g. will it be covered in the PIIs terms and conditions?) Is provision of such consent made directly to the ASPSP or could/should it be conveyed via the PII? The extent to which the latter would be feasible or appropriate may also depend on the ASPSP’s willingness to accept consent received in an indirect manner.
• Our interpretation is that any confirmation requests and responses between the parties should be seen as distinct from both the card-based payment transaction (between the PII and the PSU) and the subsequent payment order used to settle i.e. to debit the PSU’s account. This distinction will also have an influence on the relevant responsibilities of the different parties in terms of e.g. authorisation, authentication and liability.
• According to Article 65(2) point (a), the PSP needs to have the payer’s explicit consent before it may request the confirmation. Assuming a continuous authority is given by the PSU when the payment instrument is issued, we think there would still be a need for the ASPSP to verify on a transactional basis that the PSU has given consent.
• In conventional card payments the payee (retailer) receives a payment guarantee when the transaction takes place in contemplation that it will subsequently receive deferred settlement. In many circumstances this would involve generation of an authorisation request that the issuer would approve or decline. Furthermore, in a conventional card payment transaction where the issuer receives and approves an authorisation request transaction they will earmark funds in the account to meet the future transaction, because once approved it is guaranteed. It is clear it is not the intention of the directive to replicate this process.
• Our understanding is that ‘earmarking’ of funds on the PSU’s account is not permitted. We also take this to mean that the ASPSP should treat receipt of a subsequent settlement payment order in the same way it would deal with any other payment order. Thus it would apply its usual AML/sanctions and/or checking/financial crime assessment processes and would also be able to return/refuse the payment if sufficient funds are no longer available at the time the payment order is received even if the ASPSP gave a ‘yes’ response to the original request for confirmation.
• There are no provisions in PSD2 on the security of the payment instrument the PII chooses to offer the PSU. As previously discussed, the ASPSP is required to apply its usual AML and fraud checks. The ASPSP therefore needs to be able to rely on the security of the payment instrument.
• We assume that the EBA Register will need to list authorised PIIs.
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?
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?Introductory comments:
• We believe that at a high level the EBA RTS should be principles-focused, centring around openness, transparency, accessibility, usability, user control, security, extensibility and interoperability.
• Once the EBA has defined its principles, it should be for the market to implement these at a technical level. Our view is that the market can best achieve the aims of PSD2 through the use of open APIs (Application Programming Interface). The EBA should support the industry to create and adopt open API standards. Overall our view is that the interaction between customers, PISPs, AISPs (which we refer to collectively as Third Party Providers i.e. TPPs) and ASPSPs as described in PSD2 is most effectively achieved via an open API infrastructure. API technology is the accepted norm for secure data-sharing and embedding functionality in an online environment. The use of APIs is widespread and today there are more than 14,000 public APIs available. Alternative technologies for sharing data exist, but are less robust and less secure than APIs.
• We believe that the API standards should be ‘open standards’, developed and maintained collaboratively and transparently. Two main types of standard will need to be developed by the industry: data standards (rules by which data are described and recorded) and API standards (specifications that inform the design, development, security and maintenance of the API). But it is important to understand that API standards are not rigid and unchanging. They can be highly open, flexible, and adaptable, with the ability to be used differently by stakeholders depending on their business model and needs. They will not prevent variation and innovation of new models, but rather enhance and encourage them.
Where possible and practical the industry will seek to reuse existing standards, taxonomies, etc. The open API standards will facilitate the delivery of the Commission’s aims for increased access and innovation. A good ‘developer’ / TPP experience will be an important aspect of ensuring that the new ecosystem works well. To agree this approach an industry body where all types of industry participants have a voice will be required.
• Importance of standardisation and interoperability: Any successful network business depends on common standards. To create a strong network effect the users must be able to interoperate – to communicate in a standardised way. For example, the collaborative payment and clearing infrastructure is a network business which is dependent upon technical and business interoperability. Industry standards are essential for the efficient and resilient operation of the payments industry as well as ensuring that participants and end users interact in a safe, dependable and predictable manner.
o In a global economy of rapidly emerging new technologies, standards help set the rules. Standards can help set a baseline framework that can act as a springboard for quick innovation, commercialisation, continuous change and innovation at less cost and risk.
o If implemented well, standards can improve industry interoperability between counterparties both within a particular jurisdiction as well as cross-border, both in other markets and currencies.
o Standards also reduce the complexity, cost and risk of data manipulation and conversion in the inter-bank space and between banks and their customers. Standards enable competition and have been used as the basis for developing new products and entering new markets (both domestic and external).
o Standards further enable competition by reducing barriers to entry to infrastructure as they provide a common, level playing field for all participants. The implementation of standards does not mean that it forces all participants to conform identically. It creates a landscape that enables flexibility but also consistency.
• Avoiding fragmentation: There will always be a potential for fragmentation in the market. However, we support the aim of reducing fragmentation as far as possible for the benefit of consumers, businesses and providers. It will be a challenge for the market (i.e. all stakeholders, including fintechs, banks and consumer bodies) to come together to design common open standards that work on a pan-European basis, but it can be done with the right support and backing of the regulators and authorities. Ideally, standards should be Europe-wide, but if this proves difficult or slow to agree, it would be preferable to develop national standards with a separate agreement on inter-operability between them.
Comments:
• Broadly speaking we agree that the areas of clarification suggested by the EBA are the right ones. These are areas we covered as part of the work of the in the UK to design an open API in UK banking (see introductory comments for background on this).
• In terms of missing areas of clarification, the main one is the topic of ‘governance’. Logically, if the RTS require common standards of communication, there will need to be a layer of governance around this. This governance is not designed to limit or constrict the ecosystem but rather to help it to flourish. Further details on this are provided below.
• In terms of what each area of clarification should contain, we have provided an Appendix at the end of our response detailing this (based on the work in the UK). Much of the detail relates to the technical implementation of the API solution by the industry (rather than the principles the EBA will set), nevertheless, we feel it is useful for the EBA to get a sense of this in order to better shape the principles in the RTS. As previously mentioned, we strongly encourage the EBA to read the Report that was published on the proposed open API framework for the UK.
a) Define what makes a standard ‘common’ and ‘open’.
• There is no universally accepted definition of an open standard. The definition we have worked to in the UK in the context of the Open Banking Working Group (OBWG) is that an open standard is one developed and maintained collaboratively and transparently, and that can be accessed and used by anyone. We believe that the standard should be made available under a CC014 (8) licence (effectively public domain) to promote its use, reuse and distribution. Failing this, CC-BY15 (9) (attribution) would be recommended.
• The standard should be designed according to the following principles:
o Openness – ensuring accessibility for all interested parties, across a wide range of participants, thereby incentivising adoption, distribution and participation.
o Usability – facilitating ease of implementation and a smooth user experience for participants.
o Interoperability – promoting and progressing towards an environment where data can be exchanged between parties in a frictionless manner across organisational and technological boundaries.
o Reuse – adopting and leveraging existing standards, taxonomies and data lists wherever possible and practicable to avoid duplicative efforts and maximise interoperability.
o Independence – promoting competition among and avoiding dependencies on vendor solutions and technologies; preserving optionality in delivery models and implementation technologies.
o Extensibility – establishing flexibility and encouraging adoptees to build upon the standard and innovate locally, while providing governance mechanisms to subsequently bring extensions “back to the core”.
o Stability – ensuring the provision of a stable environment for all participants where change is communicated, actioned and governed in a transparent and consistent manner.
o Transparency – providing visibility and clarity on issues pertaining to the standard and the environment it operates in (for instance its design, specifications, and governance).
b) The way AIS, PIS providers will have to identify themselves towards the ASPSPs for access to payment account information (e.g. exchange of electronic certificates, see as well chapter 4.5), and every time a payment is initiated including the purpose for which the AIS and/or PIS is authorised by the PSU and requesting access to the ASPSP upon each connection. Such requirements could clarify whether or not trusted third-parties need to provide assurance (e.g. in the form of security assertions) about the identification of entities involved in such communication.
• Authentication is an integral element of any communication standard. We envisage that there are four key authentication scenarios:
o The user authenticating themselves to a TPP;
o The user authenticating themselves to an ASP (in order to authorise a TPP);
o The TPP authenticating themselves to an AS PSP (in order to access a user’s account);
o The TPP authenticating themselves to a user.
• As previously argued, we believe that ASPSPs and TPPs should own and control the method by which they authenticate their own users. The methods by which a TPP authenticates itself to an ASPSP, and a user may identify a TPP, should indeed form part of the guidelines/principles devised by the EBA. As noted in our opening remarks, we believe that as well as authentication, the ASPSP should have a way of confirming, in real-time, that the TPP is appropriately authorised (please see our comments on the EBA Register (or other suitable alternative) in the ‘overarching comments section’). In addition, having the ability to verify that each request is authorised by the TPP is essential for auditing and accountability – using something called Message Authentication Codes (MACs) is a way to achieve this. This helps to provide evidence for situations when each party has a different view of what a transaction intended (e.g. transfer 1k vs transfer 100k).
• In terms of what a solution might look like, we have described this below, in the context of using an API.
• The process by which a user authenticates themselves to an ASPSP in order to authorise the granting of permissions to a TPP will be a tripartite process, which should be designed in a way that minimises digital friction, to avoid discouraging or confusing users. It will potentially involve a hand-off (e.g. pop up window) of user interaction from the TPP to the ASPSP for the authentication to be carried out; the user remains on the TPPs website and continues their interaction with the TPP once the authentication is completed. This approach has the benefit of allowing the ASPSP to continue to own and control the method for authenticating its users (thereby minimising the risk that a TPP could obtain permissions without explicit approval by the user – something required by PSD2) and avoids any complications associated with parties other than the user or ASPSP using the credentials.
• Separately of course, users may also need to identify and authenticate themselves to TPPs in order to gain access to the services or functionality being provided (e.g. signing in to the TPP website). The method used by both ASPSPs and TPPs to authenticate users should be appropriate to adequately protect the data and functionality in question and meet any separate requirements laid down by the EBA RTS in this respect.
• In our view, the tripartite approach outlined above can be facilitated through use of the ‘OAuth 2.0 protocol’ (10 & 11). The OAuth 2.0 protocol supports a variety of different interpretations and styles of interaction, with different security implications, and is used widely by digital companies across the world. The open API standard (to be designed openly and collaboratively by all interested stakeholders) will prescribe how authentication and authorisation aspects of the standard are implemented, so the appropriate levels of consistency, interoperability and security are achieved. For example, something like the OpenID Connect authentication protocol (which provides an identity layer on top of the OAuth 2.0 protocol) be considered as part of this process. More information on OAuth is available in the UK Open API report.
• Having been granted permission to access a customer’s account information and act on the customer’s behalf, there must be a method whereby the TPP can authenticate themselves to the ASPSP during subsequent interactions. OAuth 2.0 solves this through the use of an encrypted access token that is provided by the ASPSP to the TPP at the point at which permission to access an account is granted. The TPP then presents the token to the ASPSP each time it wishes to access the account (this would be beneficial for TPPs as they would not need to rely on re-using a personal credential, which may have changed). ‘Permissions’ are the user’s informed consent for a TPP to obtain data stored by the ASPSP (e.g. an account balance or a list of transactions) or to instruct the ASPSP to carry out some function (e.g. make a payment). The access granted to TPPs should be defined in terms of specific permissions to access data or functionality via the API (this aligns with the overall PSD2 aim to ensure customers have full control over what data they make accessible). Permissions should be mapped to one or more API calls so that, given a specific permission (or set of permissions), it is clear to TPPs which API calls may be accessed.
• It must be remembered that there is a distinction between authentication and authorisation. The OAuth 2.0 model would apply as follows:
o In the course of an interaction with the TPP, the user communicates intent to grant the TPP access to account information held at an ASPSP:
1. The TPP requests access to the user’s account information from the ASPSP;
2. The ASPSP authenticates the user (using its own methods);
3. The ASPSP reviews whether the TPP is authorised to receive the access it is requesting (e.g. via an API call to the EBA Register of by assessing a digital certificate presented by the TPP);
4. The ASPSP displays to the user the access being requested by the TPP;
5. The user reviews the access being requested by the TPP and authorises the ASPSP to grant the requested access to the account information and act on the user’s behalf;
6. The ASPSP grants the TPP the requested access.
• Steps 5 and 6 should not involve the TPP; doing so would provide opportunities for a bad actor to conceal the extent of the access being requested from the user, leading the user to authorise more access than they intended.
• The ASPSP must ensure that no permissions are granted to a TPP without first being displayed to and authorised by the user. The user must have the opportunity to opt not to grant the TPP any or all of the permissions being requested, or to apply relevant limits to any permission (the AS PSP may opt to apply default limits but these should not be overly restrictive).
c) The way PIS, AIS and AS PSPs communicate between themselves and with the PSUs in a secure manner.
• Again, we will describe here how this could be facilitated via an open API approach.
• The use of an open API to facilitate communication between parties is in our view an ideal solution to address the challenges laid out by PSD2. As discussed in our opening remarks, APIs are a mature technology and used widely in most other digital industries.
• In terms of security for the API, again this is fairly mature and there are several means of doing this. In the UK framework report, we recommend the use of HTTP Strict Transport Security (to ensure that API connections should only be made using HTTPS, thus ensuring that all data in transit is encrypted), and Perfect Forward Secrecy (to minimise the impact if session keys are compromised). We also recommend that TLS v1.2 should be used as a minimum, with a defined set of strong cipher suites.
d) The minimum functionalities requirements that the future common and secure open standards of communication will have to provide. This includes for example what kind of information/services can be requested via the standard of communication (e.g. information on the availability of funds or initiation of a payment), how the identification of the account to be accessed and consent of the PSU should be conveyed.
• We do not believe that the EBA should define the detailed functionality of the communication standards (i.e. an open API). Instead, this should be left to the industry to implement through a broad-based governance mechanism. However, the EBA could set a high level view of the functionality requirements for an open standard for secure and open communication between players (i.e. the API) that assures the requirements of PSD2 are met as a de minimis. This would include for example principles regarding:
o The technical functionality of the standard itself
o The data that can be accessed via the API
o Identifiers to be used
The UK open API report made the following recommendations in respect of technical functionality and data:
Technical functionality
• The framework report provides a lot of detail about how an open API standard should be designed and how it should function technically. The report states that the API should comprise the following:
o Use of REST as an architectural style and HTTPS as the transport;
o Use of JSON as the resource format;
o Achievement of Level 2 from the Richardson Maturity Model;13
o Adoption of a vendor and technology independent definition.
o The API standard should comply with the following versioning requirements:
Support for major and minor releases;
Backwards compatibility for all minor – and as far as possible – major releases;
Prescription of minimum support time periods for major releases;
Embedded flexibility/response speed for security or functional errors.
• The API standard should be designed with the following features:
o A controlled core – hosting shared resources should be established and this should represent the slowest-changing part of the standard;
o Local extensions “at the edges” should be permitted, allowing for API provider innovations with subsequent potential incorporation back into the core;
o Specific characteristics allowing API providers to address scalability challenges.
Data
• We believe that an agreed data standard will be required (a reference data model). This is vital to ensuring that common data is made available in a uniform and consistent manner.
• A multi-stakeholder effort will be required to ensure that the data to be accessed is described and defined appropriately.
• Where possible, pre-existing data standards, such as the ISO20022 Financial Repository, should be re-used.
e) The minimum security controls that the future common and secure open standards of communication will have to provide related to the potential unauthorised or fraudulent access to payment accounts or initiation of a payment transaction.
• The UK framework report on an open API in UK banking suggested that further security would be required to protect this new ecosystem. In particular, a new security standard would be required for the server-side (i.e. the protection of customer data at rest). The report recommended a security standards approach be adopted based on the ISO/IEC 27000 series of standards, with a tiered risk-based approach. The report determined that independent auditing against this standard would be required.
• The ISO/IEC 27000 series of standards has achieved widespread adoption, with wide availability of qualified auditors. This approach has the advantage that there is no need for the regulatory authority to conduct audits; instead, it can define the standard that must be met and take advantage of the existing ISO/IEC 27000 ecosystem.
• The servers and infrastructure operated by TPPs and ASPSPs must be protected against cyber-attack. Security standards should mandate security controls that are commensurate with the nature of the data and functionality that is provided (in the case of AS PSPs) or sought (in the case of TPPs). The EBA should define the principles that server-side security should meet rather than any specific technological requirements.
f) the minimum technical requirements that could apply to the common and secure open standards of communication, the minimum reachability requirements for each ASPSPs to provide at least one interoperable interface serving all requirements of the RTS and compliant with PSD2, while AIS and PIS would have to adapt their services to the respective standardised interfaces used.
• As we have previously argued, we believe that, given the requirement for ASPSPs to provide at least one interoperable interface serving all requirement of PSD2 and for PIS/AIS to adapt their services to the respective standardised interface, the best solution is an open API standard. The EBA should provide the principles for this in the RTS.
• The open API report published in the UK provides a detailed view of the technical requirements of such an API. We strongly urge the EBA to review this report.
• The EBA does not need to focus on how the API would technically be designed – the market will solve this. Instead, it should provide the principles required to ensure that API is open, safe and secure, delivers the functionality required under PSD2 and can continue to evolve in order to allow innovation and to keep up with customer needs.
Missing areas - Governance
• In the UK, the open API Framework report proposed that a system of governance would be required. This would ensure the needs of all participants are adequately and equitably addressed and that trust and confidence in the ecosystem is established and maintained. Where personal data, and potentially commercially competitive data, is involved, it is particularly important that all parties understand their rights and obligations in the context of that data. This applies not just at the point of transfer or receipt, but subsequently when that data is retained, reused or even redistributed.
• We believe that the new ecosystem created by PSD2 will require governance. While this may not be something the EBA explicitly opines on (as flagged in paragraph 61, the EBA is not mandated to create the standards or appoint a body to do so) we do believe it is vital that the regulators and authorities publicly acknowledge the need for it and recognise the importance of multi-stakeholder efforts to create an ecosystem that works for all. Clearly there will be challenges, not least as a result of the short timescales and the complexity of pulling together the views of all stakeholders in a comprehensive but practical way. But we believe that effective pan-European governance is absolutely integral to successful implementation of PSD2. In an ideal world, there would be a central EU body which would be able to establish the independent and effective governance model to take account of multi-stakeholder views, which would enable this ecosystem to take effect on a pan-European basis. The next best option would be for a national level governance body with appropriate arrangements for interoperability.
• In our view, at a high level the governance of this new ecosystem should include:
o An overarching mechanism (an “independent authority”) to help to ensure the rights and responsibilities of all participants. Higher standards will mean better outcomes for new entrants and certainty will allow better planning. This body should also help to manage disputes and claims. This is already a complex area and will become more complex with the introduction of TPPs. We do not believe an appropriate body exists at a pan-European level and therefore the industry should seek to stand one up, representing all stakeholders, with the support of the authorities. It would operate according to the following principles:
Be independent of TPPs and data providers (e.g. ASPSPs) to ensure their and customers’ confidence in the ecosystem;
Act transparently;
Enable innovation and participation from participants of all sizes;
Promote the interests of customers in all of its activities;
Facilitate evolution of the ecosystem in line with new technologies and customer needs;
Adopt a risk-based approach.
o The Independent Authority would
Oversee but not define the data, technical and security standards that apply to the ecosystem;
Oversee but not define the standardisation of open data in the UK banking sector;
Create a clear process for issue resolution between participants and an escalation and appeal process;
Establish a process through which interested parties can participate in an advisory capacity to ensure the effective evolution of the ecosystem.
o A multi-stakeholder body to define the open standards, which fairly represents all types of participants. Again, we are not sure that there is a body that is ideally suited to this role at present, though we note that a body like ISO (the International Standards Organisation) may have a role to play.
o A certificate authority/PKI infrastructure to manage the digital certificates that each firm should use to demonstrate their authorisation, and possibly role/status etc. This could be linked to the EBA Register or managed at a national/European level by another independent body (see above (point C) for more information).
o [Please refer to the UK API report for more explanation of the governance proposals].
• While PSD2 states that contracts are not required between TPPs and AS PSPs, the number and variety of obligations that will exist between players, on a pan-European basis, will require coordination. We believe this is something that will greatly benefit customers, new players and incumbents in terms of providing clarity on rights and responsibilities, as well as greatly simplifying the number of bilateral relationships that will need to exist.
• We cannot overstate the importance of TPPs adhering to appropriate security standards. This is by no means intended to act as any kind of barrier to entry, but ensures protections for customers, commensurate with the level of risk associated with the data.
• We welcome the provision in PSD2 for PISPs/AISPs to hold professional indemnity insurance. The overall success of the ecosystem will depend on high quality insurance which is sufficient to cover PISP/AISP liabilities (these could be significant). We suggest this is closely monitored by, for example, requiring PISPs/AISPs to provide evidence of valid insurance cover to be listed as approved, and/or placing an obligation on insurance providers to notify the competent authority in the event that insurance cover lapses. Consideration should also be given to the possibility that the PISP/AISP’s insurer declines to pay out. The consequence would be that a blameless ASP could be left without recourse, though they will have already compensated the customer.
• With any delivery mechanism, we note that further consideration should be given to how business customers will give consent for a third party to make a payment on their behalf, given that there is often more than one payment authoriser (and often a complex matrix of a number). We would be pleased to give this further thought.
(8) See https://creativecommons.org/about/cc0
(9) See https://creativecommons.org/licenses/by/4.0/
(10) http://oauth.net/2/
(11) Wikipedia: “OAuth is an open standard for authorization, commonly used as a way for Internet users to log into third party websites using their Microsoft, Google, Facebook or Twitter accounts without exposing their password. Generally, OAuth provides to clients a 'secure delegated access' to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server”.
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?
17. In your opinion, are 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?Recent related UK experience might be of interest to the EBA as it develops its thinking in this area.
• In Autumn 2014 a report (12) titled “Data sharing and Open Data for banks” was published by the UK Government (HM Treasury) to explore how competition and consumer outcomes in UK banking could be affected by banks giving customers the ability to share their transaction data with third parties using external Application Programming Interfaces (APIs). As part of the work, the report also reviewed how these outcomes would be improved if banks published non-personal data as ‘open data’. The Report set out a number of recommendations:
o That banks should agree an open API standard for third party access.
o Independent guidance should be provided on technology, security and data protection standards that banks can adopt to ensure data sharing meets all legal requirements.
o An industry wide approach should be established to vet third party applications and publish a list of vetted applications as open data.
o Standard data on Personal Current Account terms & conditions should be published by banks as open data.
o Credit data should be made available as open data.
• In February 2015 HM Treasury published a consultation on the Report. In the March Budget, HM Treasury published its statement on the consultation and next steps:
o The Government committed to deliver an open API standard in UK banking;
o It proposed to set out a detailed framework for the design of the open API standard by the end of 2015;
o It believed the development of an API standard that meets the requirements around data protection and security, with reasonable cost, could be feasible in 1 to 2 years.
• Following this, three trade associations (including Payments UK), working with Government, set up a multi-stakeholder group (the Open Banking Working Group – ‘OBWG’) to come up with the framework for the design and delivery of an open API standard in UK banking. The OBWG included a wide range of market participants including Government, TPPs, other fintechs, consumer organisations, businesses and banks.
• The final framework report, which was published on 9 February 2016, provides a high degree of detail on precisely the challenge that is posed by PSD2, namely how to create an ecosystem utilising API infrastructure where customers can permission TPPs to access account data and initiate payments.
• We believe that the role of the EBA RTS is to provide the principles needed to ensure that a standardised ‘communication’ ecosystem between all players (including ASPSPs and TPPs) can emerge. The purpose of this standardised approach is not to force every player to do business in the same way but to provide the common basis that enables differentiation and innovation but with a clear view of rights and responsibilities.
• In the UK our view is that this is best achieved via the implementation of an open API infrastructure.
• This work should also help to support the requirements of the Network and Information Security Directive.
• In the UK, the work that has taken place to create a framework for an open API has taken a big step towards understanding how an ecosystem based on standardised access to bank data and for making payments would work. The report that was published 9 February 2016 is yet to be fully peer reviewed but we expect that the recommendations put forward will form the basis of the implementation of this ecosystem in the UK ahead of the deadlines for PSD2.
• The open API report was written with full consciousness of the emerging requirements of PSD2 and the need to develop a view that would enable UK PSPs to meet their obligations under the Directive, although the scope is wider than PSD2. Furthermore, the recommendations were designed with more than just the UK market in mind, with a European and potentially global outlook. Finally, we note that the OBWG was a fully multi-stakeholder body, involving more than 100 representatives from FinTechs, banks, building societies, consumer bodies, and business.
• We suggest that work in the UK could be used as a template for the wider implementation of the PSD2 ecosystem. The framework report, whilst not a fully comprehensive view, made some significant inroads to understanding how to design and implement an open API in banking and we suggest that the EBA make use of this work as far as possible.
• Please also note that some very valuable research on consumer and small business attitudes to data-sharing was recently published by IPSOS MORI. While nearly 40% reacted positively to the concept of sharing financial data (and aggregation was particularly popular), 30% were wary of the idea, and the remaining nearly 30% were uncertain of the merits. One of the main sources of consumer concern is around security and redress. Consumers demand bank-grade security around their finances, expect some means of financial compensation for security breaches and their bank to be involved in the administration of such claims. Finally, consumers overwhelmingly (77%) believe that third parties accessing their financial data should be regulated (13).
Identification of PSPs
• As well as the TPP authenticating itself to the ASPSP (a requirement of PSD2), there must be a means for ASPSPs to verify the license/authorisation of that TPP in real time. This would also be of benefit to customers.
• As laid out in PSD2 the TPP has a requirement to authenticate itself to the ASPSP. As well as authentication, the ASPSP also needs to be able to verify that the TPP is indeed licensed and able to carry out the services it is requesting access to. We therefore think it is vital that the EBA Register is not a simple text description of accredited companies, but that it has interactive functionality (that could be accessed via e.g. an API).
• This functionality should include a ‘digital certificate’, which can also be attached to communication messages between the TPP and ASPSP. Having a technical mechanism in place to allow the API implementation to verify that the requestor is legitimate is essential. In addition, having the ability to verify that each request is authorised by the TPP is essential for auditing and accountability (using Message Authentication Codes (MACs) is a way to achieve this). This helps to provide evidence for situations when each party has a different view of what a transaction intended. If the EBA Register won’t support Digital Certificates (PKI infrastructure) then something else (that is legally binding) needs to exist that will (this links to the wider governance point below).
• The register will need to be updated in real time and accessible to PSPs with instant response functionality, so that e.g. an ASPSP receiving a request for a payment from its customer and a PISP can immediately verify the PISP holds a current authorisation without delaying the transaction. As such, a real time update of PISPs removed from the register will be just as important an addition if liability is to be distributed, as the PSD2 text envisages.
• In an API environment there is other information that can usefully be stored in such Registers. This could include for example descriptions of the ‘role’ of the firm. This information would provide a description (against agreed parameters) of what that firm does (e.g. accounting software) and what they are authorised to do. Such ‘roles’ can be another powerful tool when used in conjunction with the granular ‘permissions’ that are possible through APIs. When the information about a firm’s role is supplied digitally and in real-time (via a secure digital certificate) to the holder of the data (e.g. an ASPSP) then the data holder is able to have further confidence about the validity of the data/action being requested on behalf of the customer (and importantly relay this information to the customer as part of the permissions-granting process).
• If the Register needs to be housed within another independent body, then this body could act as a central point for dispute resolution/ liability claims which will otherwise be cumbersome and expensive to administer.
(12) https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/382273/141202_API_Report_FINAL.PDF
(13) Ipsos MORI Open API - Exploring the views of consumers and small businesses: https://www.ipsos-mori.com/researchpublications/publications/1769/Open-API-Exploring-the-views-of-consumers-and-small-businesses.aspx
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)?
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)?• As mentioned above, we believe technologically it is not necessary for customers to make their personalised security credentials (i.e. their username and password/pin, etc) accessible to anyone. The work in the UK on an open API suggests that through the use of protocols like OAuth and Open IDConnect, customers can authenticate directly with the issuer of the credentials. Based on this work, we believe that there is strong support for designing the open standards such that making credentials available is not required and in fact is gradually phased out as the functionality of the API improves.
• We believe that over time new business models are likely to emerge. It is difficult (and not advisable) to try to predict what these new models might be. Instead, we believe that the approach we have outlined (see Appendix) regarding the development of an open standard that is flexible, with a clear change management framework, will help to ensure that as new innovations and models gain traction and consensus there is a means by which they can be reflected in the standard.
• Nevertheless, we are not asserting that the open API solution is the only solution (only that it appears to us to be the most suitable approach). We respect that other solutions may emerge. Regardless of this, however, the EBA principles should create an environment that is safe and secure yet modern and forward-looking.
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.
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, authentication, notification, and information? If yes, please explain how. If no, please explain why.• As a general introductory point we think it is important that the EBA is clear on the distinction between electronic identity and electronic authentication (e-IDAS Article 3.1 and Article 3.5). Identification and authentication are two distinct processes and solutions suitable for one are not necessarily interchangeable. Furthermore, distinction needs to clearly be made between the different topics in the discussion paper i.e. strong customer authentication", "protection of the confidentiality and integrity of the PSC" and "secure communication between participating service provider (AISP/PISP/ASPSP)".
• The introduction of the e-IDAS Regulation has been valuable however we question whether it is fully relevant to the implementation of PSD2. For example, we do see value in the standardisation of levels of assurance (implementing act 2015/1502) and believe this to be a positive and necessary step towards interoperability and pan-European integration of digital identity services.
• However, we believe that e-IDAS is not sufficiently equipped to provide an efficient solution for customer authentication in its current state as required by PSD2. As far as we understand, only four member states have so far signed up to e-IDAS. Also, e-IDAS is aimed at public services and government. For example, in the UK, the Government has launched a federated digital identity framework (GOV.UK Verify). Government has defined the rules by which a number of providers can verify a citizen’s identity to an acceptable level of assurance for use to gain access to Government department’s online services. The scheme is not currently intended for use in the private sector.
• The electronic identification mechanisms/schemes regulated by e-IDAS are not useful for the realisation of strong customer authentication within payment services or account information services. As proven by some industry evaluations in Germany the effort and investment for the integration in banking services is very high without any significant advantages. From the point of view of the PSU the usage is also not very convenient. Furthermore, these identification mechanisms/schemes are not generally flexible, i.e. it is not possible to enhance the authentication by elements that are dynamically linked to transaction data.
• Strong customer authentication based on "qualified trust services" like electronic signatures may have some benefits, however, the decision to support/accept electronic signatures should be made by the ASPSP based on its risk management and its business requirements. The use of electronic signatures for strong customer authentication should not be mandated by the RTS."
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.
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 PSC s between AIS, PIS providers and ASPSPs? If yes, please identify which services and explain how. If no, please explain why.• As stated previously, we believe the RTS should require that personalised security credentials are transmitted directly between the customer and the issuer of the credentials (i.e. the ASPSP) for authentication purposes. Any resulting access tokens that are produced will be exchanged between the TPP and ASPSP. We therefore think it is more helpful to answer this question by alluding to ‘sensitive payment data’ (PSD2 Article 4 (32), instead of just personalised security credentials.
• We believe that the definitions and principles from e-IDAS behind the use of ‘qualified trust services’ (as distinguished from ‘trust services’) could be considered to address the risks relating to the confidentiality, integrity and availability of sensitive payment data. For example, the use of qualified electronic seals and qualified electronic registered delivery services. In addition, the Qualified Certificates for Website Authentication could be useful for a TPP user to identify that a website offering these services is genuine.
• As we have previously mentioned, we believe that for the future ecosystem to function effectively, firms will need to be assured digitally and in real time about the ‘status’ of TPPs (whether this means their authorisation status under PSD2 or their status as regards to utilisation of a common communication standard). The most obvious solution for this is the use of some kind of ‘digital certificate’.
• In order to establish a secure communication between an AIS/PIS provider and an ASPSP, the firms have to be authenticated securely by each other. As part of this authentication it has to be proven that the AIS/PIS provider has been registered/approved by EBA and that this registration/approval is still valid. In addition, the status/role of the provider should be demonstrated, i.e. whether it is an AIS provider or a PIS provider (since the services an ASPSP has to provide depends on its status). The authentication of PIS/AIS-Provider and ASPSP should be based on electronic seals based on qualified certificates issued by qualified trust service providers under the e-IDAS regulation. For this the EBA should define a policy to be implemented by the qualified trust service provider. Compliance with this policy should assure that:
(a) only a PIS/AIS provider registered/approved by EBA will get a corresponding certificate,
(b) that a parameter contained within the certificate states the role of the certificate owner (i.e. AIS provider or PIS provider or ASPSP),
(c) if the registration/approval of a PIS/AIS provider is withdrawn by the EBA or a national supervision authority the certificate is then cancelled immediately (i.e. in addition to the certificate owner also EBA (or a national supervision authority) has got the right to cancel a certificate). For all other services the use of qualified trust services under the e-IDAS regulation should be optionally and therefore not regulated by the RTS to be prepared by EBA.
• Overall we do not believe that e-IDAS should be wholly relied on by the RTS. However, some elements, for example, qualified trust services, trust marks, etc, could be concepts referred to at a principles level. We do believe however, that as highly regulated entities needing to conduct AML and KYC, PSPs are interested to play a role in understanding how a more consistent approach to identity can be encouraged, which will benefit customers and PSPs.