The EU open banking regime under the Payment Services Directive (EU) 2015/2366 (“PSD2”) and the accompanying Regulation (EU) 2018/389 for Regulatory Technical Standards on Strong Customer Authentication (“RTS”) will go live on 14 September 2019. Under the new regime, an account servicing payment service provider (“ASPSP”) must grant a third party service provider (“TPP”) direct access to certain payment accounts of the ASPSP’s customers so that the TPP can, as requested by that customer, provide its own services to that customer. While this presents opportunities for both the ASPSPs and TPPs, there are also difficulties and challenges in the practical implementation of the rules. We have previously discussed some potential issues in relation to the allocation of liabilities between the ASPSP and the TPP should something goes wrong (see the previous article at In this article, we explore some further issues that may be worth attention from both sides.

When a TPP requests access to a customer’s in-scope accounts through the relevant interface put in place by the customer’s ASPSP, the TPP is required to identify itself to the ASPSP by using certain digital certificate (the “eIDAS certificate”) issued to it by a qualified trust service provider (“QTSP”) under the eIDAS Regulation (EU) No 910/2014 . There are, however, a number of issues relating to the use of the eIDAS certificate, in particular: whether an ASPSP should or must verify the TPP’s identity as included in the eIDAS certificate; and if so, how an ASPSP should go about conducting such verification in practice.

Need to check?

There are no express provisions under either PSD2 itself or the RTS that legally require an ASPSP actively to check whether or not a TPP is indeed authorised to provide the payment initiation service (“PIS”) and/or account information service (“AIS”). A number of Q&As issued by the European Banking Authority (“EBA”) have stated (e.g. Question ID 2018-4432) that an ASPSP is legally required to rely on the eIDAS certificate provided to it by a TPP and does not need to carry out additional checks for the purposes of TPP identification. The EBA has also stated that where an ASPSP “chooses” to carry out additional checks, it should ensure that such checks would not amount to an “obstacle” for purposes of the open banking requirements.

This seems to suggest that an ASPSP has no responsibility to ascertain whether the information contained in a particular eIDAS certificate is correct or not. Further, it seems that an ASPSP may even be better off if it does not make any additional checks, i.e. to avoid inadvertently creating any ‘obstacle’. On that basis, the position seems to be, at least for the purposes of PSD2 open banking regime, that an ASPSP should not incur any liability if something goes wrong as a result of a TPP’s eIDAS certificate being incorrect or invalid. However, this has not been expressly confirmed by either the EBA nor the UK Financial Conduct Authority (“FCA”); and we are not aware of any such confirmation from any other EU national regulator.

It should be noted that ASPSPs are typically credit institutions (essentially, banks and building societies). As such, ASPSPs tend to be subject to a multitude of regulatory regimes in addition to PSD2. Even if an ASPSP may not be liable in this respect under PSD2, it is less clear whether or not the ASPSP could possibly  incur liabilities under other regulatory regimes if it fails to make such checks or its checks are considered inadequate. By way of one example in this respect, UK credit institutions are subject to the general Principles for Business in the FCA Handbook. Principle 2 requires firms to carry out their business with skill, care and diligence and Principle 3 requires them to have adequate internal controls and risk management systems. If an ASPSP relies solely on the eIDAS certificate and that certificate turns out to be incorrect/invalid, would the ASPSP be in breach of such Principles?

For UK ASPSPs that are not credit institutions, these general Principles for Business will also apply to them from August 2019. So the same question may arise for them as well.

Even under PSD2, payment service providers (including ASPSPs) have various general obligations to mitigate fraud and other risks to their business. Could a failure to make such checks result in an ASPSP breaching these general obligations (that are not specific to the open banking regime)?

Therefore, notwithstanding the absence of express obligations to make such checks, it may nonetheless be in their interest for ASPSPs to verify the identity and authorisation status of TPPs which request access rather than solely to rely on the eIDAS certificate.

Accordingly, the next question is how ASPSPs should go about making such checks.

Registers to the rescue?

The eIDAS certificate must include the authorisation status of an TPP including its authorisation number issued by its national regulator, the payment service it provides (PIS/AIS) and the name of its regulator. The national regulator of each EU member state is required to establish a register of authorised payment institution (and certain other exempted persons) and enter onto the register the specific payment services for which each payment institution is authorised. The EBA is also required to maintain an aggregated register that covers all such payment institutions as notified to it by the national regulators. The EU Electronic Money Directive 2009/110/EC (“EMD”), as amended by PSD2, requires the national regulators and the EBA to maintain similar registers for electronic money institutions (which are entitled to provide payment services without having to be separately authorised under PSD2). Therefore, it seems logical that ASPSPs should (amongst other possible sources or databases) check these registers to ascertain whether or not a TPP is properly authorised.

However, there are a number of practical issues with using such registers. First, while the UK FCA maintains a single register for all firms authorised in the UK and passported (from other member states) into the UK, that may not be the case in other EU member states. That is, a national regulator may maintain separate registers for different firms depending on their authorisation status (e.g. one register for payment institutions, another for electronic money institutions or yet another for credit institutions). This means that, even with respect to a single EU member state, an ASPSP may need to check more than one register.

Further, the national registers as established under PSD2 and EMD do not cover credit institutions which are also entitled to provide payment services without having to be separately authorised under PSD2. The EBA aggregated register for payment institutions and electronic money institutions is effectively based on the national registers and thus also does not include credit institutions which engage in PIS and/or AIS (or any other payment services). This is because Article 15 PSD2 and the equivalent provisions in EMD (which mandate the establishment of the relevant EBA register) do not reference credit institutions that also engage in payment services. Accordingly and as also confirmed by it in the consultation process, the EBA cannot act outside its mandate under PSD2/EMD to include credit institutions in such register.

While national regulators generally do have one or more registers for authorised credit institutions as well, this is not expressly required in the Capital Requirements Directive 2013/36/EU (“CRD IV”) or the Capital Requirements Regulation (EU) No 575/2013 (“CRR”) (which are the main EU legislation for credit institutions). Therefore, the content or format of such national registers for credit institutions may vary significantly from one member state to another. Note that the EBA is indeed expressly required under CRD IV to maintain a “list” of all authorised credit institutions in the EU. However, this list (which should not be confused with the EBA register above under PSD2/EMD), as mandated by CRD IV, essentially only includes the names of such credit institutions and little else.

This means that such national register for credit institutions (where there is one) or the EBA list of credit institutions may not provide meaningful information to ASPSPs as the specific payment services being provided by a credit institution may not appear on the relevant national register (and the EBA list clearly does not have such information). For example, the FCA register does not list any payment services that a credit institution is providing. Generally, this should not be too much of a concern as credit institutions are entitled, by virtue of being so authorised, to provide payment services and they do not require to be separately authorised under PSD2. However, in the UK, a credit institution ‘must’ notify the FCA if it wishes to engage in PIS and/or AIS. This means that, if a UK TPP is also a credit institution, an ASPSP by checking the FCA register would not be able to ascertain whether or not the TPP has indeed notified the FCA to provide PIS/AIS. Given that credit institutions are regulated extensively, it may not give rise to too much of a practical issue for an ASPSP to assume that such a TPP (when it requests access) has indeed notified the FCA. However, from a principle perspective, compliance with regulatory requirements should not be based on presumptions no matter how well the counterparty is supposed to be regulated. Similar issues may arise with respect to other EU member states depending on the national implementation of PSD2.

In addition to the issues relating to the registers themselves, there are also questions as regards the potential mismatch between information on an eIDAS certificate and those on the relevant register. This is particularly problematic in the case of authorisation withdrawals. That is, where a national regulator withdraws authorisation from a TPP, there may be a time delay between the withdrawal and the revocation of that TPP’s eIDAS certificate and there is no EU-level statutory framework as regards how the national regulator and the relevant QTSP should work together to avoid that delay. The EBA has suggested a voluntary mechanism which national regulators can adopt to cooperate with QTSPs in relation to cancellation of eIDAS certificates in those circumstances.

As noted by the EBA, as of 26 April 2019: the majority of the EU national regulators (including the FCA) have indicated that they would adopt this voluntary mechanism; six national regulators have not expressed a view (e.g. Italy) as to whether or not they would adopt this mechanism; and four national regulators (Czech Republic, Germany, France and Ireland) have indicated they would not follow this voluntary process. For those latter member states, it is not clear whether this is because those member states already have an existing mechanism to deal with the issue or whether they are still in the process of considering it.

There is a further complication. A TPP’s home state may not have any QTSP. For example, according to the list maintained by the European Commission, as of 6 February 2019, Denmark does not appear to have any QTSP; as of 6 March 2019, the UK does not appear to have any QTSP either (we understand that as at the date of this article there is one QTSP in the UK). Therefore, a TPP in one member state may obtain its eIDAS certificate from a QTSP in another member state or it may choose to do so for commercial reasons. If e.g. a UK TPP has obtained its eIDAS certificate from a French QTSP and then the FCA withdraws the UK TPP’s authorisation, how would the FCA communicate and cooperate with the French QTSP to have the TPP’s eIDAS certificate cancelled?

Admittedly, such authorisation withdrawals tend to be rare occurrences. One may therefore argue that the accompanying risk for an ASPSP should not be that much of a concern in practice. However, as noted above, ASPSPs are legally required to “rely” on the eIDAS certificate. So it is crucial that the eDIAS certificate is capable of being so relied upon at any point in time, particularly given the uncertainties of the potential liabilities discussed above.

Another issue with the eIDAS certificate is that it does not include information on passporting. For example, if a UK ASPSP receives an access request from a French TPP, the UK ASPSP would not be able to ascertain from the TPP’s eIDAS certificate whether or not the French TPP has properly passported into the UK. The EBA in its Q&A has clarified that an ASPSP does not need to check if a TPP has properly passported into the host state. Again, this seems to suggest that in the event of a TPP having not properly passported, the ASPSP should not incur any liability under PSD2 open banking regime. However, there is still the issue of whether or not the ASPSP could be held liable under other regulatory regimes applicable to it. It should be noted that the EBA aggregate register includes information on passporting. The UK FCA register also contains information on passporting.

The key question in the above circumstances is this: following any additional checks, what course of action should the ASPSP take? It is generally accepted that the ability of an TPP to access a customer’s payment account cannot be contingent on anything other than the TPP having been authorised. This also has been expressly confirmed by the FCA in its Payment Services and Electronic Money Approach Document; it is reasonable to assume that the position in other member states should be the same. So, can an ASPSP deny an access request if it cannot ascertain (following the checks) whether or not the TPP is indeed authorised to provide the relevant service (notwithstanding the TPP’s eIDAS certificate indicates it is)? The question is particularly acute in the case of passporting. Because the relevant TPP is indeed authorised in its home state; only that it may not have properly passported into the relevant host state. One argument could be that there should be no ground for an ASPSP to deny access as the TPP is authorised (in its home state). Another argument could be that passporting is an integral part of the authorisation requirements and thus the TPP could be said to have not been “authorised” in the host state before it completes the passporting process and accordingly the ASPSP in the host state should be able to deny access.

Concluding remark

In summary, ASPSPs seem to be presented with a dilemma. If they rely solely on the eIDAS certificate and do not conduct any verification checks, they should be in the clear under PSD2 open banking regime (as the EBA Q&As seem to suggest) but may end up with potential liabilities under other regulatory requirements. If they do conduct additional checks which, however, provide information inconsistent with the eIDAS certificate, it is not entirely clear how and whether they can act differently without incurring any liabilities.

While the discussion here is primarily from the perspective of ASPSPs, these issues are also very much relevant to TPPs. As noted above, ASPSPs are typically credit institutions which are extensively regulated. As such, if ASPSPs are unsure of what they need to or should be doing, they may lean towards adopting an overly conservative or cautious approach to the implementation of the open banking requirements which in turn would affect TPPs that wish to connect to them. There may not be an easy solution to these issues which may need discussion within the industry as well as between the industry and regulators.