Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
We therefore believe that exemptions from SCA should be limited as far as possible. First, this provides a high level of security and transparency, and second this avoids complexity. If bank systems differentiated between a variety of different cases to propose a variety of different authentication methods, systems would become more complex – and thus more costly and less secure. Once customers are used to SCA (SCA already is state-of-the-art in online banking, so most customers are used to it), it no longer creates a significant inconvenience. SCA therefore should be used for any communication with ASPSPs – in line with recommendations of the SecurePay Forum.
PIS provide a software to the payer that he can use to contact and handle his account (Recital 27 PSD2 refers to a “software bridge”). It is therefore always the consumer who is acting and who applies the security procedures of his ASPSP (based on SCA). This is why PIS necessarily rely on the authentication provided by ASPSPs.
PIS should be able to rely on each procedure a bank is offering, regardless of the various procedures of different banks in different countries. If the current solution of the bank meets the requirements of strong customer authentication, the bank should not be pushed to issue new methods of SCA. From a risk perspective, there is no difference between a transaction initiated in the original online banking or via a PIS. EBA should clarify that it is prohibited to introduce new SCA methods at bank that would exclude PISPs.
Our intention is not that banks have to change their online-banking infrastructure and invest hundreds of millions, if the current technical set-up applies to SCA and enables PIS the access to the bank-account.
Examples for strong-customer-authentication:
• A static password for the login, a dynamic password for the transaction (e.g. mobile TAN)
• A one-time password for the login, a one-time password for the transaction (strong-strong customer authentication, mainly used by Belgian banks)
• Solutions where the one-time password is transmitted via a mobile device (SMS TAN)
• Solutions where the one-time password is generated by a TAN generator owned by the customer
• Some banks offer their customers the choice between different procedures (SMS tan, TAN generator etc.)
It will be important that the elements can be conveyed via non-bank PIS or AIS. They need to rely on the authentication the bank has chosen. Therefore, mechanisms based on “inherence” elements or behaviour based characteristics must not be designed by ASPSPs in a way that excludes the use of non-bank AIS or PIS. This is part of the legal requirements under PSD2 for CSOSC, which need to be open for the use of and the communication with PIS and AIS.
There are several technical ways to ensure the independence of two separate elements also where mobile devices are being used, e.g. to not send mobile TAN to the same (but a different) mobile device or using a separate TAN-generator or card. As an example, Belgian banks have opted for a TAN-generator to generate two separate one-time TAN. Consumers are used to this SCA procedure and can rely on it for e-payments via PIS, generating a high level of certainty for all players in e-commerce. Sweden introduced a mobile BankID (www.bankid.com).
Future innovation will certainly provide a host of additional solutions (amongst which could also be firewalls on mobile devices). Banks should retain a margin of appreciation to develop and test such solutions. PIS and AIS have an interest that the system chosen by ASPSPs remains consistent for all situations, as this reliability engenders security and alleviates interoperability with non-bank systems. PIS, therefore, have an interest that SCA can always be used when in contact with the bank, because SCA provides a sound and secure basis for e-commerce - not only for consumers and banks, but also for PIS and AIS, as well as for shop-owners, all of which have the same interest in ensuring they communicate with the correct owner of a banking account. The market trend is towards mobile" - banks will take this into account and will develop appropriate solutions."
This link provides a useful additional aspects of security: Most importantly, the one-time code linked to a specific amount and recipient cannot be misused, even if it was stolen. Thus, even unauthorized access to this code does not enable fraud. And additionally, if amount and recipient are disclosed to the payer before he submits the code to the bank, he can double-check and detect deviations and stop the transaction if he is in doubt. This creates an additional check to protect against potential manipulation with the transaction data received by the bank.
We believe that these additional security features for remote transactions are an important part of the security design of PSD2. If all remote transactions use SCA and dynamic links, online-banking will become more secure – with a direct positive security improvement. Indirectly, this will also protect AIS and PIS, which rely on banks’ security designs. We believe that on the security provisions for banks of PSD2 will make online banking finally just as secure as PIS already are today (thanks to their multi-layer security design, which provides effective protection for conventional online-banking). In our view, PSD2 implements a sound and safe package that should not be weakened.
Exemptions issued by thousands of different ASPSPs (banks) will lead to complexity. Notably, a simple and consistent system will be better understood and implemented by consumers. Once they are used to the SCA system with dynamic links (as most of them already are), this no longer contains inconveniences but, instead, will improve the security of online-banking and e-commerce as a whole.
The challenges described in para. 35 may need to be addressed for direct debit e-mandates, where the amount cannot be specified in advance (e.g. in recurring payments). Payers are protected by their right of revocation, and the payee needs to take the risk of default/non-payment. In this setting, it may seem appropriate to not insist on a dynamic link; but Art. 97 (1b), (2) PSD2 may not even apply to direct debit, in the first place.
Another proven solution is the TAN-generator, which is a separate device designed to produce a one-time TAN often linked to the recipient and the amount. Belgian banks, for example, rely on a SCA system with two one-time TAN, one of which is linked to the amount and recipient. The system works reliably and has been well received by consumers. It also allows for the use of PIS, which helps to make safe and reliable e-payments an important part of e-commerce.
Also the use of so called photoTAN (cryptographic QR-code) seems to fulfil both objectives.
Basically exemptions issued by thousands of ASPSPs in Europe will lead to complexity and to a lack of transparency. Please take into account that the decisions regarding exemptions will be made on the level of each independent bank or banking cooperation and will also lead to a technical fragmentation. Fragmentation then has the capacity to hinder further innovation such as in “instant payments”, which are strongly supported by the ECB and other authorities.
PIS offer a solution where consumers are able to use their trusted bank-account to initiate a payment to a merchant. PIS provide a very secure and reliable payment method. Exemptions from SCA should not lead to a lower security level and any exemptions should equally apply to PIS and AIS. It should be ensured that ASPSPs won’t use exemptions to discriminate against PIS and AIS to gain an unfair advantage for bank-owned providers.
It is important for EBA to stress that according to Art. 97 (5) PSD2, ASPSPs are obliged to allow PIS and AIS to rely on the authentication procedures provided by the ASPSP. This is in line with Recital 30: “Regardless of the business model used by the PIS providers, the ASPSP should make it possible for PIS providers to rely on the authentication procedures provided by the ASPSPs to initiate a specific payment on behalf of the payer”. This rule applies in any case, both where the ASPSP uses SCA and where he uses an exemption from SCA. It is therefore important to stress that exemptions do not mean that PIS and AIS would be excluded from authentication. Instead, it always needs to be ensured that PIS and AIS can rely on the authentication procedures agreed between bank and payer. Art. 66 (4c) PSD2 obliges ASPSP to no discriminate against payment orders submitted via PIS, so they need to be subject to the same rules.
Otherwise, exemptions would create a possibility for ASPSPs to block the use of PIS and AIS. This would foreclose a part of the market and would most probably provide a very strong incentive for banks to use exemptions where possible, because this would protect them against competition. It is therefore important to uphold symmetry: PIS need to rely on the authentication procedures at hand, be it SCA or not. In fact, using PIS increases the security for ASPSPs in case of exemptions, as it provides an additional “firewall” for online-banking, e.g. because of its integration with approved shops/merchants and due to its multi-layer security design that delivers outstanding security.
EBA should consider that security often depends on efficiency and simplicity because the more complex a system, the more likely it includes failures. As para 45 shows, an individual case-by-case risk analysis engenders high transaction cost, because it is complex. It also increases a risk of failure, i.e. the risk that fraud cannot be as effectively excluded as with SCA. Hence, opting out from SCA produces inefficiencies. The more exemptions apply, the higher transaction costs will be. On the other hand, if SCA could be relied upon for any case, this would reduce doubt and complexity, fraud and default risk. This would contribute to an overall reduction of transaction cost and consumer prices. This can be shown in practice: The payment schemes with the highest level of security tend to be the cheapest, because there is less need to pay insurance premiums.
HTTPS is a common and open standard of communication that offers security measures to protect confidentiality and integrity of the data being transmitted, and that offers communication channels resistant to tampering and unauthorized access. Most notably, this worldwide standard relies on the verification by independent third parties (e.g. Symantec) that issue certificates to identify servers and clients, thereby enabling an open communication in a secure channel including the ability to identify and authenticate towards each other.
We believe that HTTPS fulfills the requirements for a CSOSC and therefore has to be accepted as a common and open standard in compliance with PSD2. The advantage of HTTPS, as far as independent third-parties are concerned, cannot be underestimated. It is well established and proven in practice, no isolated application, not controlled by financial market players. It is being developed by the world internet community, a “plug-in” solution of the Internet, there are many independent trust-service providers that make secure communication work. It is globally ready for use at virtually no extra cost to the banking community, and in fact it has already become the omnipresent standard of the banking community. No other CSOSC exists today.
PIS produce outstanding security (low cost, efficiency) for more than ten years. PIS have effectively created an additional security layer or “firewall” for ASPSPs to enter e-commerce. PIS constitute a filter against fraud, achieving a level of security that single ASPSPs on their own will hardly be able to achieve.
The business model of PIS is based on security:
- In the beginning, most PIS started their business models in industries where merchants were suffering from high fraud rates (e.g., electronic goods, digital goods, high-value-products). Merchants were looking for secure payment methods, because they were not able to cover these risks by themselves and were no longer prepared to accept the weak security of credit cards.
- The risk of “card not present” transactions and a low coverage of consumers with many other payment options (due to sometimes complex and exclusive risk profiling) were pushing merchants to integrate PIS solutions.
- Common open and international standards like HTTPS provided a proven and accepted way to communicate over the internet (note that PIS also offer services to international customers outside the EU, relying on HTTPS worldwide).
- SOFORT added an additional layer of encryption for security credential upon entry, resulting in a double encryption via SSL/HTTPS and RSA. This may be a model for secure communication in addition to HTTPS.
We therefore believe that there always needs to be the possibility to obtain certification and evaluation from independent third parties. Moreover, there should be competition between these independent third parties, in the sense that there must not be only one designated trust-service, but this activity should be open to competing trust-providers and ideas. This ensures that standards are being developed and that market access, which depends on these standards, remains open and non-discriminatory.
For example, SOFORT has relied on the technical expertise of the German TÜV to evaluate and certify IT-systems. TÜV does not have an interest in foreclosing bank markets and therefore was prepared to provide an objective evaluation. In contrast, bank-affiliated service providers had been called back by their owners and were obliged to not service SOFORT. It is therefore tantamount for any standard that controls access to market access that is not controlled by one of the market players but by independent third parties.
As pointed out above, this is one major advantage of HTTPS: It does exist and offers a wide range of independent trust-services. This worldwide standard cannot be twisted in a way to exclude particular business models or competitors. Any player has access to the standard and can be certified.
The same third-party certification should be available for AIS and PIS (and combinations), as all will rely on the same CSOSC, SCA and infrastructure. From a technical point of view, there is no objective reason for any distinction.
SCA and dynamic linking do not change the way PIS and AIS work. They simply enforce the state-of-the-art technology for online-banking, already widely implemented throughout the market. PSD2 forces banks to follow through on technological development. These measures make e-payments more secure and reliable. Therefore, indirectly they are also important for PIS, which rely on secure e-payments. EBA should be critical of any attempt to weaken this simple trust-system.
One of PSD2’s major aims is to protect market access of existing PIS and AIS against unwarranted obstruction or restriction. PSD2 therefore has enshrined the right of account holders to use non-bank PIS and AIS – that right of the consumer must not be obstructed, unless there is a demonstrable risk of fraud. Hence, access to account and account information must remain open, which is one of the core requirements that apply to CSOSC. A standard that generally limits the access to account information and/or restricts the use of AIS or PIS, cannot be accepted. Any restriction needs to be limited to precise threats – and has to be lifted once that risk has been removed.
Therefore, direct and indirect access to bank accounts must not be excluded and can only be limited on a case-by-case basis. Standards that do not follow these rules must not be proposed. Overly restrictive standards would violate PSD2 as well as antitrust law (Art. 101 TFEU).
In its proposed clarification, EBA does not mention the requirement to enable and protect market access, but one important requirement for standards set by PSD2 is to be “common and open”. EBA should evolve in its clarification that “common” means commonly available and used throughout the market and that “open” means not restricting access unless for exceptional cases as defined by Art. 68 (5) PSD2.
The current market standard used by ASPSPs throughout the European Union and worldwide, is HTTPS. HTTPS already fulfills all the functions and requirements of PSD2 and therefore needs to be accepted also as future CSOSC.
Because there already is this well-established and secure infrastructure, controlled by independent third parties and existing without a need for substantial investment, enabling open access as intended by PSD2, we are sceptical of any proposal to create new bank–infrastructure that would become obligatory to use instead of HTTPS. Such new standards would have to provide the same functionality, reliability, neutrality and openness, and the same common availability, as HTTPS does. It is hard to conceive that this will be possible, given that in fact there is no reason to develop a second infrastructure, if the current infrastructure already is fully sufficient. It is also hard to imagine that banks themselves would be prepared to switch their online banking from HTTPS to a new standard yet to be developed (and most probably limited to a small world of European banking). And while HTTPS will most likely remain the omnipresent standard for online banking worldwide, there is no reason to deny that standard to PIS and AIS (in the EU). After all, this would constitute discrimination in breach of PSD2, violate basic EU freedoms and antitrust law.
We therefore fear that proposals to produce a new interface, API, intermittent layer, service, infrastructure etc., only serve the one aim to create a new “wall” between PIS and AIS on one side and the payers’ account on the other side. It is the very aim of PSD2 to tear down any such wall, artificially erected as banks feared competition. So PSD2 cannot become a reason to put up exactly this kind of intermittent layer.
Such middle layer would be unsound also from an economic perspective, as it provides false incentives: Banks do not have an incentive to build and service such a wall apart from avoiding competition. And PIS and AIS, who do have all the incentives to create and run efficient services, will have no control over this wall. We therefore believe that the criteria of commonness and openness will be decisive in any future discussion. Proposals of ASPSPs to force PIS and AIS to use a new infrastructure should be rejected where that infrastructure is not as efficient, not as secure, not as transparent, not as commonly in use, and non-discriminatory and not as open as HTTPS is. It will be the role of EBA to defend the market against foreclosure by the means of these new infrastructures. We therefore believe that EBA needs to include in its requirements for CSOSC a well-functioning and secure standard already in use i.e. HTTPS. Above all, EBA has the function to avoid a new standard that would be used as a pretext to block access to the existing, common, open and secure standard of HTTPS.
Recital 33 of PSD2 highlights that protective role of EBA: “[…] without prejudice to the need to ensure the security of payment transactions and costumer protection against demonstrable risk of fraud, the Member States, the Commission, the ECB and the EBA should guarantee fair competition in that market, avoiding unjustifiable discrimination against any existing player on the markets.” Recital 33 emphasizes the role of regulators, and notably of EBA, to protect market access against obstruction and restriction. And it draws the line in balance with the aim of security: Unless there is a “demonstrable risk of fraud”, access must not be restricted. The binding rule is Art. 68 (5) PSD2.
A blockade can be avoided, if HTTPS is recognized to constitute a CSOSC in line with PSD2. Because then this channel, which virtually every bank already uses for its online banking, will remain open, and the incentive for ASPSPs to create new obstructive “walls” would be smaller. Therefore, a decisive discussion will be to ensure that HTTPS cannot be blocked in the future. Any new tools, intermittent layers, API, other infrastructure to be created (“pie in the sky”) can be an option for users, but must not become obligatory if that would exclude the use of the well-established worldwide market standard of HTTPS.
Moreover, if the European Union was to decide that HTTPS is not sufficiently secure for online banking, it would splinter its e-commerce economy from the rest of the world and would have to develop its own solution, which inevitably cannot be as efficient as a worldwide standard. There is no reason to do so, especially as the aim of PSD2 is to create a level playing field openly accessible for e-commerce. This must not be abused as a platform for special interests in creating a monopoly infrastructure.
a. Define what makes a standard “common” and “open”
a.1 Commonly available language
A market standard is “common” if it is commonly available and in common use. Any interested party needs a reasonable ability to find and use the standard, and this standard needs to enable communication with the majority of market players. A bank offering a niche solution incompatible with the market would have to offer a second, more commonly available solution in order to comply with PSD2.
The ability to serve the market (opening and protecting market access) is important to consider when discussing “national champion” solutions sometimes proposed by incumbent players. For example, a Polish “Sonderweg” would not be “commonly available”, since e-commerce is not limited to Poland. It would be still a niche market solution astray of what is the market standard. In our view, the problem even applies to a European “Sonderweg”, which still would go astray from the well-established worldwide market standard.
In any case, offering a “common standard of communication” is not a formality. It has to be a standard that truly does enable to link bank accounts via a “software bridge” with the other players in the market in a meaningful way, i.e. a language shared within the community, including online shops, payers, payees, banks, third parties and others. The solution is available and omnipresent: HTTPS. It is because of that common standard of HTTPS that PIS and AIS have come to exist, in the first place.
a.2 Open access
“Open” means that the standard must be openly available for PIS and AIS in order to access the account and account information. Based on the two types of service defined in the PSD2, PIS and AIS, there are many mixtures and new services yet to be invented. All of these services need to be able to rely on the one standard, i.e. information on the bank account that payers intend to share with these new services need to be readily accessible via the “common language”. For example, AIS services often provide full access to account information. Therefore, a CSOSC needs to enable delivery and cannot be limited to one particular piece of information. What is more, to enable the development of new alternative services and a mixture of them, the necessary information cannot be defined beforehand. A standard, therefore, must not reduce the amount of available input, as this would pre-chose and preclude technologies and business models (and also further innovation). In other words, an open standard really needs to grant open access to the payment account, as defined in Art. 66 and 68 PSD2. An interface, API or other piece of infrastructure that would be designed to provide only one particular digit (such as “yes or no” and nothing else) is not open, as it does not give full access, and therefore cannot be in line with PSD2.
This does not mean that PSD2 would prohibit the development of an intermittent interface or “middle layer” that offers particular pieces of information. PSD2 obliges, however, a bank to not reduce access to the account to this kind of very limited output. This is explicitly set out in Recital 32: “PIS are based on direct or indirect access for the PIS provider to the payer’s account and ASPSP, which provides a mechanism for indirect access, should [therefore] also allow direct access for the PIS providers.”
This kind of direct access is protected by Art. 68 (5) PSD2: It must not be restricted unless for individual cases of demonstrable risk, and any restriction has to be removed immediately as soon as the risk is gone. Therefore, any obligatory standard that limits the amount of information that can be received by a particular service, would violate Art. 68 PSD2 Instead, any tool that gives limited access, would have to remain an optional tool, while the overall way for direct access on behalf of the PSU needs to remain open. This is exactly why HTTPS is so important, because it does enable direct access for any tool already today on a most secure basis.
In addition to these requirements of PSD2, antitrust law. Under Art. 101 TFEU, it would be illegal to impose the obligatory use of a “standard” instrument that restricts access to information necessary to provide competing services. A new standard to be created relies on an agreement between market players. And if that standard restricts access to information, it would constitute an impediment to competition to the extent the information is necessary to provide services such as PIS and/or AIS. Where such impediment cannot be justified with Art. 68 PSD2, i.e. based on a concrete threat, the restriction would not be indispensable in the sense of Art. 101 (3) TFEU and hence anti-competitive and illegal.
An attempt to limit access to an account based on CSOSC needs to be dismissed by EBA, because a standard designed to restrict access to the market is not “open”. Such restrictive tools would only be acceptable, where they remain optional.
A new bank-owned “middle layer” would lead to a situation, where non-bank PIS become resellers of a monopoly infrastructure - in a worst case scenario forced to buy the results from bank-owned competitors such as iDEAL or giropay. Non-bank PIS currently compete with the bank-owned PIS notably on the market of generating and providing information, where they generate a competition based in innovation, security designs, efficiency, reliability, costs, fees etc. This competition and open access to market is what Recital 32 has in mind when it obliges to also always grant direct access. From an antitrust perspective, ASPSPs cannot be allowed to fence off that upstream market from non-bank competitors, as they must not be afforded “the possibility of eliminating competition in respect of a substantial part of the products in question”, Art. 101 (3) TFEU.
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
There is a body of rules creating the HTTPS protocol, which is secure, common and open. It is being used for online-banking as well as PIS and AIS, and it should remain open to use in the future.
HTTPS relies on independent “certification authorities (CA)” (such as Symantec or StartCom) that sign cryptographic certificates – both for clients (client certificates) and servers (server or website certificates). These functionalities seem to be broadly in line with the e-IDAS Regulation No. 910/2014.
AIS and PIS today identify themselves towards banks by the way of their IP address, which can be agreed between parties (provided banks do not use this to block access). A so-called three-way-handshake enables to check that the client contacting the bank is the same, whose address had been deposited with the bank. These tools provide a reliable standard to identify PIS and AIS towards the bank. They can be easily integrated with HTTPS, as is already the case in practice.
In addition, client certificates can be used to amend the identification process in a “Public Key Infrastructure” (PKI). Those certificates are issued by an independent CA (such as Symantec) and allow identifying the client based on the SSL-encryption. Client certificates are widely used in practice and, for example, form part of e-identities such as electronic ID cards.
We would like to highlight that PSD2 obliges AIS and PIS to identify themselves towards ASPSPs. There is no qualification as to the way this identification has to be provided. Considering the obligation imposed by PSD2 to enable open market access for PIS and AIS, banks cannot impose a regime that would limit access to the account.
Given there is the ability to identify PIS and AIS via HTTPS, there is no reason to create new systems that impose extra hurdles and complexities. Such restrictions cannot be justified, because they are not indispensable, given that there already is an existing standard that can be used. Therefore, ASPSPs are not free to design any system. Instead, the criteria of commonness and openness limit their choice: Identification tools must not limit access and need to be commonly available. ASPSP’s are therefore under an obligation to accept the identification offered by AIS and PIS via standard HTTPS systems. Refusing that identification would violate Art. 68 (5) PSD2 (and Art. 101 TFEU) as long as there is no other mechanism that is just as easy, simple, reliable, commonly available and open as HTTPS.
c. The way PIS, AIS and ASPSPs communicate between themselves and with the PSUs in a secure manner
EBA cannot designate which technology is secure, but it may describe what it requires to be secure. In our view, as set out before, HTTPS is the very definition of secure online communication, and therefore fulfills this criterion.
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,
EBA should not define an exhaustive list of functionalities, because this would always limit future innovation. Openness to innovation can be achieved by not limiting the number of functionalities, because otherwise business model neutrality would be lost.
It is important to keep in mind that PIS and AIS in many cases will be provided as part of the same service. Services such as “Starmoney” or “Starmoney Web” (in Germany) offer both, the ability to check accounts and to make payments. Hence, any CSOSC needs to remain open for all services: PIS, AIS and any combination thereof, and also new services to be invented. As these services can be combined a reduction on information request for PIS would even not work because they can request the same data as an AIS.
Therefore, EBA should limit itself to requiring that the CSOSC shall be able to convey any account information that is indispensable to provide PIS and/or AIS as demanded by the payer. A CSOSC therefore needs to be a protocol or library that covers all aspects of information on the account, and that must not be limited to one or two particular pieces of information, or a shortlist of very particular functions.
HTTPS, in fact, does provide all the functionalities necessary for online banking. It is a suitable CSOSC, exactly because it is the basis of online banking as provided to the payer. Hence, if the CSOSC is the very same standard based on which online banking is being created in the first place, then there is no doubt that it is open to provide any information requested by payers. Using HTTPS for all functionalities provides perfect symmetry. In contrast, creating a new standard in addition to HTTPS inevitably will create inefficiencies and loss of information, which therefore can hardly be acceptable instead of HTTPS (but rather as additional option only).
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,
Any CSOSC needs to enable SCA and the use of dynamic links. This is the centerpiece of authentication of the payer. The aim of SCA is exactly to protect against unauthorized or fraudulent access. If SCA is followed through, we doubt that CSOSC need to provide additional layers of protection against unauthorized access. At least, PSD2 has no stipulation that in addition to SCA imposed by Art. 97 PSD2, there have to be further measures to avoid unauthorized access.
The minimum security control therefore is the use of SCA. This is the reason why exemptions should be restrictive. ASPSPs may introduce further instruments, such as device-related information to be checked (see above on para 45), but this cannot be instead of SCA. Therefore, the minimum requirement is to fulfill Art. 97 PSD2, and EBA’s role is to defend Art. 97 against exemptions.
Finally, there is a licensing regime under PSD2. Therefore, any PSP activity will have been licensed by authorities, which protects against access of potentially insecure PSPs.
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 regulation, while AIS and PIS would have to adapt their services to the respective standardized interfaces used.
ASPSPs have to offer at least one CSOSC that is common and open, enabling secure communication. A bank that does not offer such a CSOSC would be in breach of its obligation to offer direct access to the payer’s account. According to Art. 66 and 67 PSD2, every bank has the duty to allow its customers to make use of non-bank PIS and AIS. Banks may also offer additional infrastructures and services, but these must not be obligatory. The use of a common and open standard of communication must not be restricted.
As pointed out before, there currently is only one CSOSC in the market, HTTPS, which is commonly available and enables open access on a secure basis. If banks were to introduce new infrastructures, services, API’s and other intermittent lawyers or “walls” for PIS/AIS, they cannot make them obligatory.
Please note: Bank-owned providers in Europe so far only operate at the national level (iDEAL, eps, giropay, mybank). They tend to rely on closed, bank-only standards, “not open and common standards” and, therefore, were not able to expand to the European level. Only bank independent providers (SOFORT, Trustly) were able to serve customer and merchants internationally. Why should banks now be prepared or able to develop new and (truly) open and common standards, even though they have neither been able nor prepared to develop these standards for their own business models?
The German HBCI/FinTS system may provide an example of a bank-owned specialized library focused on financial transactions. It may offer an example for the development of new alternative CSOSC.
However, there is a question why this should be done, if there already is a well-functioning standard. HBCI/FinTS can also serve as a negative example of a bank-owned standard that was well-intended but never really got off the ground. Although well-documented and open, HBCI/FinTS has never been fully implemented by all German banks, and it is hardly being serviced in a reliable way by half of them. Many banks have shown limited interest, perhaps they were shying away from high implementation costs. Today, HBCI/FinTS would therefore not be a “common” standard available throughout the market. Based on HBCI/FinTS in reality, PIS and AIS would only be able to reach a small part of their customers.
What HBCI/FinTS demonstrates is that there is a lack of interest in investing in a bank-owned infrastructure. First because it is simply superfluous considering that there already is HTTPS. And second, implementing HBCI/FinTS creates new competition for the implementing bank, as it can be used by third parties such as PIS/AIS to provide the account holders with additional access options without providing any additional value to the implementing bank itself. This is why German banks started to fight access of non-banks to their systems, arguing HBCI/FinTS should be foreclosed towards new competitors. Accordingly, there are sound economic reasons why HBCI/FinTS has never become fully functional for a sufficiently large number of banks.
In theory, HBCI/FinTS does offer an example of a bank-specific library or protocol that has the potential to be commonly available and open. There could be commands defined for any role of PSPs, including PIS and AIS. In practice, however, the protocol does not stand up to the requirements of PSD2. It can therefore only be used as an option or a complement to the access via HTTPS – which is exactly the way that PIS work in Germany. As the German Federal Cartel Office pointed out, there is no reasonable concern as to the security or efficiency of AIS or PIS based on HTTPS, and PSD2 obliges EBA to take care that it remains open.
Therefore, we do not have to “reinvent the wheel” but should rely on the global standard of HTTPS. Let us not forget that some banks might provide their service only in Europe. PIS and AIS, however, will certainly need to follow the market and expand services to other regions (imagine UK or Irish shops that offer the same payment methods to EU, US and Indian customers). Therefore, any standard should also be fit for a global expansion. A European “Sonderweg” would not only be less functional but also hinder EU businesses in competing worldwide.
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.
At the moment the service of PIS is based on credit transfer. Examples for other kinds of transactions are: standing order, direct debit mandate. For any kind of transaction initiated by a PSU on his bank account via PIS, we believe that a Strong Customer Authentication (SCA) provides a sensible protection for any communication and therefore should be applied for all transactions between the bank and its customers. We believe that SCA for an online-bank account should be omnipresent because it provides the best protection; lesser systems of authentication at banks may pose a certain risk. It is hard to predict future scenarios as to how attacks could be designed, but it is safe to predict that SCA will help to protect in any case.We therefore believe that exemptions from SCA should be limited as far as possible. First, this provides a high level of security and transparency, and second this avoids complexity. If bank systems differentiated between a variety of different cases to propose a variety of different authentication methods, systems would become more complex – and thus more costly and less secure. Once customers are used to SCA (SCA already is state-of-the-art in online banking, so most customers are used to it), it no longer creates a significant inconvenience. SCA therefore should be used for any communication with ASPSPs – in line with recommendations of the SecurePay Forum.
PIS provide a software to the payer that he can use to contact and handle his account (Recital 27 PSD2 refers to a “software bridge”). It is therefore always the consumer who is acting and who applies the security procedures of his ASPSP (based on SCA). This is why PIS necessarily rely on the authentication provided by ASPSPs.
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?
The EBA standards to be developed are to provide for technological neutrality and therefore are not expected to decide in favour or against particular technologies. We do not have own experience with regard to the use of data as “possession” element. In any case, PIS adapt to and support the bank’s choice of SCA, as PIS rely on banks’ authentication. There should remain a margin for flexibility for banks’ technical choice of SCA methods to enable future innovation.PIS should be able to rely on each procedure a bank is offering, regardless of the various procedures of different banks in different countries. If the current solution of the bank meets the requirements of strong customer authentication, the bank should not be pushed to issue new methods of SCA. From a risk perspective, there is no difference between a transaction initiated in the original online banking or via a PIS. EBA should clarify that it is prohibited to introduce new SCA methods at bank that would exclude PISPs.
Our intention is not that banks have to change their online-banking infrastructure and invest hundreds of millions, if the current technical set-up applies to SCA and enables PIS the access to the bank-account.
Examples for strong-customer-authentication:
• A static password for the login, a dynamic password for the transaction (e.g. mobile TAN)
• A one-time password for the login, a one-time password for the transaction (strong-strong customer authentication, mainly used by Belgian banks)
• Solutions where the one-time password is transmitted via a mobile device (SMS TAN)
• Solutions where the one-time password is generated by a TAN generator owned by the customer
• Some banks offer their customers the choice between different procedures (SMS tan, TAN generator etc.)
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?
The choice of elements is not decisive for PIS, as they will (have to) rely on and support banks’ choice. We cannot judge whether behaviour-based characteristics may be appropriate. Banks should probably retain a margin of flexibility. EBA should allow for innovation and not exclude or propose precise technical solutions.It will be important that the elements can be conveyed via non-bank PIS or AIS. They need to rely on the authentication the bank has chosen. Therefore, mechanisms based on “inherence” elements or behaviour based characteristics must not be designed by ASPSPs in a way that excludes the use of non-bank AIS or PIS. This is part of the legal requirements under PSD2 for CSOSC, which need to be open for the use of and the communication with PIS and AIS.
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)?
Also in this regard, SOFORT adapts to the security policy of the banks, most of which already tackle the issue, e.g. where mobile TAN are being used.There are several technical ways to ensure the independence of two separate elements also where mobile devices are being used, e.g. to not send mobile TAN to the same (but a different) mobile device or using a separate TAN-generator or card. As an example, Belgian banks have opted for a TAN-generator to generate two separate one-time TAN. Consumers are used to this SCA procedure and can rely on it for e-payments via PIS, generating a high level of certainty for all players in e-commerce. Sweden introduced a mobile BankID (www.bankid.com).
Future innovation will certainly provide a host of additional solutions (amongst which could also be firewalls on mobile devices). Banks should retain a margin of appreciation to develop and test such solutions. PIS and AIS have an interest that the system chosen by ASPSPs remains consistent for all situations, as this reliability engenders security and alleviates interoperability with non-bank systems. PIS, therefore, have an interest that SCA can always be used when in contact with the bank, because SCA provides a sound and secure basis for e-commerce - not only for consumers and banks, but also for PIS and AIS, as well as for shop-owners, all of which have the same interest in ensuring they communicate with the correct owner of a banking account. The market trend is towards mobile" - banks will take this into account and will develop appropriate solutions."
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
The potential complications set out by EBA in para. 35 of the discussion paper do not apply for PIS. When using a PIS, the amount of the transfer has been agreed between seller and buyer – only on that basis a payer would be forwarded to the PIS service to transmit his transfer order to the bank. Therefore, a link between the (a) precise amount and recipient and (b) the one-time password should always be feasible.This link provides a useful additional aspects of security: Most importantly, the one-time code linked to a specific amount and recipient cannot be misused, even if it was stolen. Thus, even unauthorized access to this code does not enable fraud. And additionally, if amount and recipient are disclosed to the payer before he submits the code to the bank, he can double-check and detect deviations and stop the transaction if he is in doubt. This creates an additional check to protect against potential manipulation with the transaction data received by the bank.
We believe that these additional security features for remote transactions are an important part of the security design of PSD2. If all remote transactions use SCA and dynamic links, online-banking will become more secure – with a direct positive security improvement. Indirectly, this will also protect AIS and PIS, which rely on banks’ security designs. We believe that on the security provisions for banks of PSD2 will make online banking finally just as secure as PIS already are today (thanks to their multi-layer security design, which provides effective protection for conventional online-banking). In our view, PSD2 implements a sound and safe package that should not be weakened.
Exemptions issued by thousands of different ASPSPs (banks) will lead to complexity. Notably, a simple and consistent system will be better understood and implemented by consumers. Once they are used to the SCA system with dynamic links (as most of them already are), this no longer contains inconveniences but, instead, will improve the security of online-banking and e-commerce as a whole.
The challenges described in para. 35 may need to be addressed for direct debit e-mandates, where the amount cannot be specified in advance (e.g. in recurring payments). Payers are protected by their right of revocation, and the payee needs to take the risk of default/non-payment. In this setting, it may seem appropriate to not insist on a dynamic link; but Art. 97 (1b), (2) PSD2 may not even apply to direct debit, in the first place.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
In our experience, mobile TAN provide a high level of security, as it is sent via SMS to a separate device, where it can be read and checked.Another proven solution is the TAN-generator, which is a separate device designed to produce a one-time TAN often linked to the recipient and the amount. Belgian banks, for example, rely on a SCA system with two one-time TAN, one of which is linked to the amount and recipient. The system works reliably and has been well received by consumers. It also allows for the use of PIS, which helps to make safe and reliable e-payments an important part of e-commerce.
Also the use of so called photoTAN (cryptographic QR-code) seems to fulfil both objectives.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Please note: Our answers focus on the business model of PIS who rely on the safety of a transaction initiated via a bank account of thousands of different consumer banks. If exemptions of ASPSPs will be explicitly allowed in the RTS the fundamental principle should be: Any exemptions to the application of strong customer authentication should equally apply to PIS and AIS. It should be ensured that ASPSPs (banks) won’t use exemptions to obstruct PIS.Basically exemptions issued by thousands of ASPSPs in Europe will lead to complexity and to a lack of transparency. Please take into account that the decisions regarding exemptions will be made on the level of each independent bank or banking cooperation and will also lead to a technical fragmentation. Fragmentation then has the capacity to hinder further innovation such as in “instant payments”, which are strongly supported by the ECB and other authorities.
PIS offer a solution where consumers are able to use their trusted bank-account to initiate a payment to a merchant. PIS provide a very secure and reliable payment method. Exemptions from SCA should not lead to a lower security level and any exemptions should equally apply to PIS and AIS. It should be ensured that ASPSPs won’t use exemptions to discriminate against PIS and AIS to gain an unfair advantage for bank-owned providers.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
Yes: PIS and AIS need to retain the ability to rely on ASPSPs’ authentication also in case of exemptions.It is important for EBA to stress that according to Art. 97 (5) PSD2, ASPSPs are obliged to allow PIS and AIS to rely on the authentication procedures provided by the ASPSP. This is in line with Recital 30: “Regardless of the business model used by the PIS providers, the ASPSP should make it possible for PIS providers to rely on the authentication procedures provided by the ASPSPs to initiate a specific payment on behalf of the payer”. This rule applies in any case, both where the ASPSP uses SCA and where he uses an exemption from SCA. It is therefore important to stress that exemptions do not mean that PIS and AIS would be excluded from authentication. Instead, it always needs to be ensured that PIS and AIS can rely on the authentication procedures agreed between bank and payer. Art. 66 (4c) PSD2 obliges ASPSP to no discriminate against payment orders submitted via PIS, so they need to be subject to the same rules.
Otherwise, exemptions would create a possibility for ASPSPs to block the use of PIS and AIS. This would foreclose a part of the market and would most probably provide a very strong incentive for banks to use exemptions where possible, because this would protect them against competition. It is therefore important to uphold symmetry: PIS need to rely on the authentication procedures at hand, be it SCA or not. In fact, using PIS increases the security for ASPSPs in case of exemptions, as it provides an additional “firewall” for online-banking, e.g. because of its integration with approved shops/merchants and due to its multi-layer security design that delivers outstanding security.
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?
The transaction history of the customer and the risk profile of the payee do not exclude fraud and therefore should not function as the sole basis for a risk evaluation. Device-related criteria could be a sound amendment, but no replacement. In the interest of trust and foreseeability, and in the interest of legal certainty, exemptions based on an individual case by case risk analysis should be excluded altogether.EBA should consider that security often depends on efficiency and simplicity because the more complex a system, the more likely it includes failures. As para 45 shows, an individual case-by-case risk analysis engenders high transaction cost, because it is complex. It also increases a risk of failure, i.e. the risk that fraud cannot be as effectively excluded as with SCA. Hence, opting out from SCA produces inefficiencies. The more exemptions apply, the higher transaction costs will be. On the other hand, if SCA could be relied upon for any case, this would reduce doubt and complexity, fraud and default risk. This would contribute to an overall reduction of transaction cost and consumer prices. This can be shown in practice: The payment schemes with the highest level of security tend to be the cheapest, because there is less need to pay insurance premiums.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
We believe that the abstract criteria set out by EBA in letters 1, 2 and 3 are useful. They define abstract criteria for CSOSC. In particular, we believe it makes sense to rely on independent third parties to certify the resistance and security of technologies being employed. It is also correct to point out that EBA will not define or designate a particular standard, but will have to limit itself to general requirements. CSOSC that fulfill the criteria would then be available for usage.HTTPS is a common and open standard of communication that offers security measures to protect confidentiality and integrity of the data being transmitted, and that offers communication channels resistant to tampering and unauthorized access. Most notably, this worldwide standard relies on the verification by independent third parties (e.g. Symantec) that issue certificates to identify servers and clients, thereby enabling an open communication in a secure channel including the ability to identify and authenticate towards each other.
We believe that HTTPS fulfills the requirements for a CSOSC and therefore has to be accepted as a common and open standard in compliance with PSD2. The advantage of HTTPS, as far as independent third-parties are concerned, cannot be underestimated. It is well established and proven in practice, no isolated application, not controlled by financial market players. It is being developed by the world internet community, a “plug-in” solution of the Internet, there are many independent trust-service providers that make secure communication work. It is globally ready for use at virtually no extra cost to the banking community, and in fact it has already become the omnipresent standard of the banking community. No other CSOSC exists today.
PIS produce outstanding security (low cost, efficiency) for more than ten years. PIS have effectively created an additional security layer or “firewall” for ASPSPs to enter e-commerce. PIS constitute a filter against fraud, achieving a level of security that single ASPSPs on their own will hardly be able to achieve.
The business model of PIS is based on security:
- In the beginning, most PIS started their business models in industries where merchants were suffering from high fraud rates (e.g., electronic goods, digital goods, high-value-products). Merchants were looking for secure payment methods, because they were not able to cover these risks by themselves and were no longer prepared to accept the weak security of credit cards.
- The risk of “card not present” transactions and a low coverage of consumers with many other payment options (due to sometimes complex and exclusive risk profiling) were pushing merchants to integrate PIS solutions.
- Common open and international standards like HTTPS provided a proven and accepted way to communicate over the internet (note that PIS also offer services to international customers outside the EU, relying on HTTPS worldwide).
- SOFORT added an additional layer of encryption for security credential upon entry, resulting in a double encryption via SSL/HTTPS and RSA. This may be a model for secure communication in addition to HTTPS.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
We believe it is a centerpiece of the security design of PSD2 that PSC must not be stored by the provider of AIS and PIS. It has been a cornerstone of the security of non-bank PIS.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?
PIS will support and rely on the ASPSP’s choice.13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?
We believe that certification and evaluation by third parties of components or devices as well as channels, protocols etc. should be an indispensable element of any system, because it guarantees that no-one controls the access to the system. In particularPSD2 aims to guarantee market access for non-bank PIS and AIS. Therefore, the evaluation and certification must not be in the hands of competitors who may decide to abuse their power to foreclose markets. It should be in the hands of well-established neutral actors that do not have their own stake in the decision, e.g. third party service providers like the German TÜV or Symantec.We therefore believe that there always needs to be the possibility to obtain certification and evaluation from independent third parties. Moreover, there should be competition between these independent third parties, in the sense that there must not be only one designated trust-service, but this activity should be open to competing trust-providers and ideas. This ensures that standards are being developed and that market access, which depends on these standards, remains open and non-discriminatory.
For example, SOFORT has relied on the technical expertise of the German TÜV to evaluate and certify IT-systems. TÜV does not have an interest in foreclosing bank markets and therefore was prepared to provide an objective evaluation. In contrast, bank-affiliated service providers had been called back by their owners and were obliged to not service SOFORT. It is therefore tantamount for any standard that controls access to market access that is not controlled by one of the market players but by independent third parties.
As pointed out above, this is one major advantage of HTTPS: It does exist and offers a wide range of independent trust-services. This worldwide standard cannot be twisted in a way to exclude particular business models or competitors. Any player has access to the standard and can be certified.
The same third-party certification should be available for AIS and PIS (and combinations), as all will rely on the same CSOSC, SCA and infrastructure. From a technical point of view, there is no objective reason for any distinction.
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?
SCA and dynamic linking in accordance with Art. 97 PSD2 are important elements of the security of online-banking. They will further enhance today’s online-banking, creating trust in e-payments. As set out in response to Chapter 4.2, we believe exemptions should be standardized.SCA and dynamic linking do not change the way PIS and AIS work. They simply enforce the state-of-the-art technology for online-banking, already widely implemented throughout the market. PSD2 forces banks to follow through on technological development. These measures make e-payments more secure and reliable. Therefore, indirectly they are also important for PIS, which rely on secure e-payments. EBA should be critical of any attempt to weaken this simple trust-system.
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?
PSD2 does not only require EBA to define security requirements, but also requirements that ensure open access to market for non-bank PIS and AIS.One of PSD2’s major aims is to protect market access of existing PIS and AIS against unwarranted obstruction or restriction. PSD2 therefore has enshrined the right of account holders to use non-bank PIS and AIS – that right of the consumer must not be obstructed, unless there is a demonstrable risk of fraud. Hence, access to account and account information must remain open, which is one of the core requirements that apply to CSOSC. A standard that generally limits the access to account information and/or restricts the use of AIS or PIS, cannot be accepted. Any restriction needs to be limited to precise threats – and has to be lifted once that risk has been removed.
Therefore, direct and indirect access to bank accounts must not be excluded and can only be limited on a case-by-case basis. Standards that do not follow these rules must not be proposed. Overly restrictive standards would violate PSD2 as well as antitrust law (Art. 101 TFEU).
In its proposed clarification, EBA does not mention the requirement to enable and protect market access, but one important requirement for standards set by PSD2 is to be “common and open”. EBA should evolve in its clarification that “common” means commonly available and used throughout the market and that “open” means not restricting access unless for exceptional cases as defined by Art. 68 (5) PSD2.
The current market standard used by ASPSPs throughout the European Union and worldwide, is HTTPS. HTTPS already fulfills all the functions and requirements of PSD2 and therefore needs to be accepted also as future CSOSC.
Because there already is this well-established and secure infrastructure, controlled by independent third parties and existing without a need for substantial investment, enabling open access as intended by PSD2, we are sceptical of any proposal to create new bank–infrastructure that would become obligatory to use instead of HTTPS. Such new standards would have to provide the same functionality, reliability, neutrality and openness, and the same common availability, as HTTPS does. It is hard to conceive that this will be possible, given that in fact there is no reason to develop a second infrastructure, if the current infrastructure already is fully sufficient. It is also hard to imagine that banks themselves would be prepared to switch their online banking from HTTPS to a new standard yet to be developed (and most probably limited to a small world of European banking). And while HTTPS will most likely remain the omnipresent standard for online banking worldwide, there is no reason to deny that standard to PIS and AIS (in the EU). After all, this would constitute discrimination in breach of PSD2, violate basic EU freedoms and antitrust law.
We therefore fear that proposals to produce a new interface, API, intermittent layer, service, infrastructure etc., only serve the one aim to create a new “wall” between PIS and AIS on one side and the payers’ account on the other side. It is the very aim of PSD2 to tear down any such wall, artificially erected as banks feared competition. So PSD2 cannot become a reason to put up exactly this kind of intermittent layer.
Such middle layer would be unsound also from an economic perspective, as it provides false incentives: Banks do not have an incentive to build and service such a wall apart from avoiding competition. And PIS and AIS, who do have all the incentives to create and run efficient services, will have no control over this wall. We therefore believe that the criteria of commonness and openness will be decisive in any future discussion. Proposals of ASPSPs to force PIS and AIS to use a new infrastructure should be rejected where that infrastructure is not as efficient, not as secure, not as transparent, not as commonly in use, and non-discriminatory and not as open as HTTPS is. It will be the role of EBA to defend the market against foreclosure by the means of these new infrastructures. We therefore believe that EBA needs to include in its requirements for CSOSC a well-functioning and secure standard already in use i.e. HTTPS. Above all, EBA has the function to avoid a new standard that would be used as a pretext to block access to the existing, common, open and secure standard of HTTPS.
Recital 33 of PSD2 highlights that protective role of EBA: “[…] without prejudice to the need to ensure the security of payment transactions and costumer protection against demonstrable risk of fraud, the Member States, the Commission, the ECB and the EBA should guarantee fair competition in that market, avoiding unjustifiable discrimination against any existing player on the markets.” Recital 33 emphasizes the role of regulators, and notably of EBA, to protect market access against obstruction and restriction. And it draws the line in balance with the aim of security: Unless there is a “demonstrable risk of fraud”, access must not be restricted. The binding rule is Art. 68 (5) PSD2.
A blockade can be avoided, if HTTPS is recognized to constitute a CSOSC in line with PSD2. Because then this channel, which virtually every bank already uses for its online banking, will remain open, and the incentive for ASPSPs to create new obstructive “walls” would be smaller. Therefore, a decisive discussion will be to ensure that HTTPS cannot be blocked in the future. Any new tools, intermittent layers, API, other infrastructure to be created (“pie in the sky”) can be an option for users, but must not become obligatory if that would exclude the use of the well-established worldwide market standard of HTTPS.
Moreover, if the European Union was to decide that HTTPS is not sufficiently secure for online banking, it would splinter its e-commerce economy from the rest of the world and would have to develop its own solution, which inevitably cannot be as efficient as a worldwide standard. There is no reason to do so, especially as the aim of PSD2 is to create a level playing field openly accessible for e-commerce. This must not be abused as a platform for special interests in creating a monopoly infrastructure.
a. Define what makes a standard “common” and “open”
a.1 Commonly available language
A market standard is “common” if it is commonly available and in common use. Any interested party needs a reasonable ability to find and use the standard, and this standard needs to enable communication with the majority of market players. A bank offering a niche solution incompatible with the market would have to offer a second, more commonly available solution in order to comply with PSD2.
The ability to serve the market (opening and protecting market access) is important to consider when discussing “national champion” solutions sometimes proposed by incumbent players. For example, a Polish “Sonderweg” would not be “commonly available”, since e-commerce is not limited to Poland. It would be still a niche market solution astray of what is the market standard. In our view, the problem even applies to a European “Sonderweg”, which still would go astray from the well-established worldwide market standard.
In any case, offering a “common standard of communication” is not a formality. It has to be a standard that truly does enable to link bank accounts via a “software bridge” with the other players in the market in a meaningful way, i.e. a language shared within the community, including online shops, payers, payees, banks, third parties and others. The solution is available and omnipresent: HTTPS. It is because of that common standard of HTTPS that PIS and AIS have come to exist, in the first place.
a.2 Open access
“Open” means that the standard must be openly available for PIS and AIS in order to access the account and account information. Based on the two types of service defined in the PSD2, PIS and AIS, there are many mixtures and new services yet to be invented. All of these services need to be able to rely on the one standard, i.e. information on the bank account that payers intend to share with these new services need to be readily accessible via the “common language”. For example, AIS services often provide full access to account information. Therefore, a CSOSC needs to enable delivery and cannot be limited to one particular piece of information. What is more, to enable the development of new alternative services and a mixture of them, the necessary information cannot be defined beforehand. A standard, therefore, must not reduce the amount of available input, as this would pre-chose and preclude technologies and business models (and also further innovation). In other words, an open standard really needs to grant open access to the payment account, as defined in Art. 66 and 68 PSD2. An interface, API or other piece of infrastructure that would be designed to provide only one particular digit (such as “yes or no” and nothing else) is not open, as it does not give full access, and therefore cannot be in line with PSD2.
This does not mean that PSD2 would prohibit the development of an intermittent interface or “middle layer” that offers particular pieces of information. PSD2 obliges, however, a bank to not reduce access to the account to this kind of very limited output. This is explicitly set out in Recital 32: “PIS are based on direct or indirect access for the PIS provider to the payer’s account and ASPSP, which provides a mechanism for indirect access, should [therefore] also allow direct access for the PIS providers.”
This kind of direct access is protected by Art. 68 (5) PSD2: It must not be restricted unless for individual cases of demonstrable risk, and any restriction has to be removed immediately as soon as the risk is gone. Therefore, any obligatory standard that limits the amount of information that can be received by a particular service, would violate Art. 68 PSD2 Instead, any tool that gives limited access, would have to remain an optional tool, while the overall way for direct access on behalf of the PSU needs to remain open. This is exactly why HTTPS is so important, because it does enable direct access for any tool already today on a most secure basis.
In addition to these requirements of PSD2, antitrust law. Under Art. 101 TFEU, it would be illegal to impose the obligatory use of a “standard” instrument that restricts access to information necessary to provide competing services. A new standard to be created relies on an agreement between market players. And if that standard restricts access to information, it would constitute an impediment to competition to the extent the information is necessary to provide services such as PIS and/or AIS. Where such impediment cannot be justified with Art. 68 PSD2, i.e. based on a concrete threat, the restriction would not be indispensable in the sense of Art. 101 (3) TFEU and hence anti-competitive and illegal.
An attempt to limit access to an account based on CSOSC needs to be dismissed by EBA, because a standard designed to restrict access to the market is not “open”. Such restrictive tools would only be acceptable, where they remain optional.
A new bank-owned “middle layer” would lead to a situation, where non-bank PIS become resellers of a monopoly infrastructure - in a worst case scenario forced to buy the results from bank-owned competitors such as iDEAL or giropay. Non-bank PIS currently compete with the bank-owned PIS notably on the market of generating and providing information, where they generate a competition based in innovation, security designs, efficiency, reliability, costs, fees etc. This competition and open access to market is what Recital 32 has in mind when it obliges to also always grant direct access. From an antitrust perspective, ASPSPs cannot be allowed to fence off that upstream market from non-bank competitors, as they must not be afforded “the possibility of eliminating competition in respect of a substantial part of the products in question”, Art. 101 (3) TFEU.
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
There is a body of rules creating the HTTPS protocol, which is secure, common and open. It is being used for online-banking as well as PIS and AIS, and it should remain open to use in the future.
HTTPS relies on independent “certification authorities (CA)” (such as Symantec or StartCom) that sign cryptographic certificates – both for clients (client certificates) and servers (server or website certificates). These functionalities seem to be broadly in line with the e-IDAS Regulation No. 910/2014.
AIS and PIS today identify themselves towards banks by the way of their IP address, which can be agreed between parties (provided banks do not use this to block access). A so-called three-way-handshake enables to check that the client contacting the bank is the same, whose address had been deposited with the bank. These tools provide a reliable standard to identify PIS and AIS towards the bank. They can be easily integrated with HTTPS, as is already the case in practice.
In addition, client certificates can be used to amend the identification process in a “Public Key Infrastructure” (PKI). Those certificates are issued by an independent CA (such as Symantec) and allow identifying the client based on the SSL-encryption. Client certificates are widely used in practice and, for example, form part of e-identities such as electronic ID cards.
We would like to highlight that PSD2 obliges AIS and PIS to identify themselves towards ASPSPs. There is no qualification as to the way this identification has to be provided. Considering the obligation imposed by PSD2 to enable open market access for PIS and AIS, banks cannot impose a regime that would limit access to the account.
Given there is the ability to identify PIS and AIS via HTTPS, there is no reason to create new systems that impose extra hurdles and complexities. Such restrictions cannot be justified, because they are not indispensable, given that there already is an existing standard that can be used. Therefore, ASPSPs are not free to design any system. Instead, the criteria of commonness and openness limit their choice: Identification tools must not limit access and need to be commonly available. ASPSP’s are therefore under an obligation to accept the identification offered by AIS and PIS via standard HTTPS systems. Refusing that identification would violate Art. 68 (5) PSD2 (and Art. 101 TFEU) as long as there is no other mechanism that is just as easy, simple, reliable, commonly available and open as HTTPS.
c. The way PIS, AIS and ASPSPs communicate between themselves and with the PSUs in a secure manner
EBA cannot designate which technology is secure, but it may describe what it requires to be secure. In our view, as set out before, HTTPS is the very definition of secure online communication, and therefore fulfills this criterion.
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,
EBA should not define an exhaustive list of functionalities, because this would always limit future innovation. Openness to innovation can be achieved by not limiting the number of functionalities, because otherwise business model neutrality would be lost.
It is important to keep in mind that PIS and AIS in many cases will be provided as part of the same service. Services such as “Starmoney” or “Starmoney Web” (in Germany) offer both, the ability to check accounts and to make payments. Hence, any CSOSC needs to remain open for all services: PIS, AIS and any combination thereof, and also new services to be invented. As these services can be combined a reduction on information request for PIS would even not work because they can request the same data as an AIS.
Therefore, EBA should limit itself to requiring that the CSOSC shall be able to convey any account information that is indispensable to provide PIS and/or AIS as demanded by the payer. A CSOSC therefore needs to be a protocol or library that covers all aspects of information on the account, and that must not be limited to one or two particular pieces of information, or a shortlist of very particular functions.
HTTPS, in fact, does provide all the functionalities necessary for online banking. It is a suitable CSOSC, exactly because it is the basis of online banking as provided to the payer. Hence, if the CSOSC is the very same standard based on which online banking is being created in the first place, then there is no doubt that it is open to provide any information requested by payers. Using HTTPS for all functionalities provides perfect symmetry. In contrast, creating a new standard in addition to HTTPS inevitably will create inefficiencies and loss of information, which therefore can hardly be acceptable instead of HTTPS (but rather as additional option only).
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,
Any CSOSC needs to enable SCA and the use of dynamic links. This is the centerpiece of authentication of the payer. The aim of SCA is exactly to protect against unauthorized or fraudulent access. If SCA is followed through, we doubt that CSOSC need to provide additional layers of protection against unauthorized access. At least, PSD2 has no stipulation that in addition to SCA imposed by Art. 97 PSD2, there have to be further measures to avoid unauthorized access.
The minimum security control therefore is the use of SCA. This is the reason why exemptions should be restrictive. ASPSPs may introduce further instruments, such as device-related information to be checked (see above on para 45), but this cannot be instead of SCA. Therefore, the minimum requirement is to fulfill Art. 97 PSD2, and EBA’s role is to defend Art. 97 against exemptions.
Finally, there is a licensing regime under PSD2. Therefore, any PSP activity will have been licensed by authorities, which protects against access of potentially insecure PSPs.
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 regulation, while AIS and PIS would have to adapt their services to the respective standardized interfaces used.
ASPSPs have to offer at least one CSOSC that is common and open, enabling secure communication. A bank that does not offer such a CSOSC would be in breach of its obligation to offer direct access to the payer’s account. According to Art. 66 and 67 PSD2, every bank has the duty to allow its customers to make use of non-bank PIS and AIS. Banks may also offer additional infrastructures and services, but these must not be obligatory. The use of a common and open standard of communication must not be restricted.
As pointed out before, there currently is only one CSOSC in the market, HTTPS, which is commonly available and enables open access on a secure basis. If banks were to introduce new infrastructures, services, API’s and other intermittent lawyers or “walls” for PIS/AIS, they cannot make them obligatory.
16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?
In para 18 (iii), EBA points out that there would be a risk that new solutions would be too divergent and could become a barrier for AIS and PIS. We agree with this assessment which is why we believe HTTPS should be accepted to be in line with PSD2. HTTPS is commonly available, open and can be used with any bank. In fact, it is already used by every bank and is the omnipresent worldwide standard for online-banking. Allowing for the use of HTTPS avoids the risk of creating diverging new infrastructures.Please note: Bank-owned providers in Europe so far only operate at the national level (iDEAL, eps, giropay, mybank). They tend to rely on closed, bank-only standards, “not open and common standards” and, therefore, were not able to expand to the European level. Only bank independent providers (SOFORT, Trustly) were able to serve customer and merchants internationally. Why should banks now be prepared or able to develop new and (truly) open and common standards, even though they have neither been able nor prepared to develop these standards for their own business models?
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?
Yes, HTTPS is commonly and openly available, and secure. It provides the basis for the current outstanding security performance of PIS as well as normal online banking and has an exceptionally high acceptance by consumers (because they don’t need to do anything, it’s automatic in the background). It therefore must not be blocked or otherwise be restricted for PIS or AIS.The German HBCI/FinTS system may provide an example of a bank-owned specialized library focused on financial transactions. It may offer an example for the development of new alternative CSOSC.
However, there is a question why this should be done, if there already is a well-functioning standard. HBCI/FinTS can also serve as a negative example of a bank-owned standard that was well-intended but never really got off the ground. Although well-documented and open, HBCI/FinTS has never been fully implemented by all German banks, and it is hardly being serviced in a reliable way by half of them. Many banks have shown limited interest, perhaps they were shying away from high implementation costs. Today, HBCI/FinTS would therefore not be a “common” standard available throughout the market. Based on HBCI/FinTS in reality, PIS and AIS would only be able to reach a small part of their customers.
What HBCI/FinTS demonstrates is that there is a lack of interest in investing in a bank-owned infrastructure. First because it is simply superfluous considering that there already is HTTPS. And second, implementing HBCI/FinTS creates new competition for the implementing bank, as it can be used by third parties such as PIS/AIS to provide the account holders with additional access options without providing any additional value to the implementing bank itself. This is why German banks started to fight access of non-banks to their systems, arguing HBCI/FinTS should be foreclosed towards new competitors. Accordingly, there are sound economic reasons why HBCI/FinTS has never become fully functional for a sufficiently large number of banks.
In theory, HBCI/FinTS does offer an example of a bank-specific library or protocol that has the potential to be commonly available and open. There could be commands defined for any role of PSPs, including PIS and AIS. In practice, however, the protocol does not stand up to the requirements of PSD2. It can therefore only be used as an option or a complement to the access via HTTPS – which is exactly the way that PIS work in Germany. As the German Federal Cartel Office pointed out, there is no reasonable concern as to the security or efficiency of AIS or PIS based on HTTPS, and PSD2 obliges EBA to take care that it remains open.
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)?
In its approach, EBA should remain open for new solutions. No solution should become obligatory, apart from the fact that all ASPSPs need to offer at least one CSOSC. This is, in fact, easy: If every bank keeps open the account access via HTTPS on behalf of the account holder, they are in line with PSD2 at virtually no extra cost.Therefore, we do not have to “reinvent the wheel” but should rely on the global standard of HTTPS. Let us not forget that some banks might provide their service only in Europe. PIS and AIS, however, will certainly need to follow the market and expand services to other regions (imagine UK or Irish shops that offer the same payment methods to EU, US and Indian customers). Therefore, any standard should also be fit for a global expansion. A European “Sonderweg” would not only be less functional but also hinder EU businesses in competing worldwide.