__MAIN_TEXT__
feature-image

Page 1

THE TRICKY ENCOUNTER A Norfico whitepaper about the new connection between banks and third-party providers under PSD2

By  Michael Juul Rugaard, Partner, Norfico Kristian T. Sørensen, Partner, Norfico

A NORFICO PSD2 WHITE PAPER MAY 2017


CONTENT Foreword Identifying and authenticating the TPPs The EBA register Whose responsibility? National or European coverage A matter of security Digital certificates More practical questions Who should issue the certificates? Is yet another list needed? Who to appoint the issuers? How do the TPPs get the certificates? What if a certificate must be revoked? Conclusion About NORFICO

3 4 4 5 5 5 6 6 7 8 8 8 8 9 10

A NORFICO PSD2 WHITE PAPER APRIL 2017


Foreword 1. D  ue to delays it will probably be somewhere between October 2018 and April 2019.

According to the new Payment Services Directive 2 (PSD2) - Article 66 and 67 - all European banks (or ASPSPs) must comply with the directive’s requirement for Access to Account (XS2A) no later than 18 months after the approval of the final Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA).1 When this finally happens, the banks should have their APIs ready and they should be able to grant the Third-Party Providers (TPPs) access to their customer’s payment accounts, provided that the TPP is approved as a TPP and that the bank customers have allowed the TPPs to act on their behalf. This might sound relatively simple, but a closer look into the implications of these requirements and the timeline for complying with them, reveals a high degree of complexity. The encounter between the ASPSPs (the banks) and the TPPs raises a lot of complex questions, and in this white paper produced by Norfico, we intend to shed some light on these questions. We find it necessary to point out the challenges associated with this encounter between the banks and the TPPs as nobody else seems to have given this interesting and problematic corner of PSD2 much (or any!) attention, and with approval of the RTS expected imminent, time is now a scarce resource. The question is how these new encounters between banks and the TPPs will play out in practice? How will the banks be able to authenticate in a sufficiently secure way that the TPPs are who they claim to be, and that they have the rights to gain access to a certain bank customer’s account? The banks carry a heavy security obligation and the liability towards their customers (the bank account holders), when opening up for the access to account. The European Banking Authority (EBA) is obliged to establish a register of TPPs for the banks to use, but apparently, the EBA is dependent on national registers for input, and those registers probably do not exist. Furthermore, a register with TPP names does not assure the banks that the TPPs knocking on their doors are the ones listed in the register, even though they claim to be so. Something more is needed, probably a kind of digital certificate (on eIDAS level) – and perhaps also a whole new player in the PSD2 ecosystem ensuring coordination and regular security controls. These might seem like technicalities, but looking further into these questions it becomes clear that they touch on somewhat basic, and yet unsolved, problems. In this short whitepaper, we hope to initiate a discussion about how to answer these important questions.

>>back to content

A NORFICO PSD2 WHITE PAPER MAY 2017 PAGE 3


Identifying and authenticating the TPPs One of the questions we intend to discuss in this whitepaper is the unsolved problem of how the European banks can make an easy and secure identification of Third Party Providers wanting to obtain access to bank customers’ payment accounts in accordance with PSD2’s Article 66 for Payment Initiation Services (PIS) and Article 67 for Account Information Services (AIS): Article 66. Rules on access to payment account in the case of payment initiation services. 1. Member States shall ensure that a payer has the right to make use of a payment initiation service provider to obtain payment services as referred to in point (7) of Annex I. The right to make use of a payment initiation service provider shall not apply where the payment account is not accessible online.” And:

2. h  ttp://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015L2366&from=DA p. 92 and p. 93

Article 67: Rules on access to and use of payment account information in the case of account information services. 1. Member States shall ensure that a payment service user has the right to make use of services enabling access to account information as referred to in point (8) of Annex I. That right shall not apply where the payment account is not accessible online.”2

The EBA register Article 14 of the directive requires the member states to establish a public register of “authorised payment institutions and their agents”. And Article 15 appoints overall responsibility for the register on a cross-European level to the EBA:

3. h  ttp://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015L2366&from=DA p. 68

Article 15 - EBA register 1. EBA shall develop, operate and maintain an electronic, central register that contains the information as notified by the competent authorities in accordance with paragraph. EBA shall be responsible for the accurate presentation of that information. EBA shall make the register publicly available on its website, and shall allow for easy access to and easy search for the information listed, free of charge. 2. Competent authorities shall, without delay, notify EBA of the information entered in their public registers as referred to in Article 14 in a language customary in the field of finance. 3. Competent authorities shall be responsible for the accuracy of the information specified in paragraph 2 and for keeping that information upto-date. L 337/68 Official Journal of the European Union 23.12.2015 EN 4. EBA shall develop draft regulatory technical standards setting technical requirements on development, operation and maintenance of the electronic central register and on access to the information contained therein. The technical requirements shall ensure that modification of the information is only possible by the competent authority and EBA. EBA shall submit those draft regulatory technical standards to the Commission by 13 January 2018.”3

>>back to content

A NORFICO PSD2 WHITE PAPER MAY 2017 PAGE 4


Whose responsibility? The register of approved TPPs, which can obtain access to customer accounts in European banks (provided the bank customer has given his or her approval), should be based on national registers in all the member states, and it should be updated instantly whenever a change occurs. These are good intentions, but in reality serious problems could arise: First, the member states most likely do currently not have any updated national TPP registers to draw from, and it will take considerable time and effort to establish such registers. Secondly, the national financial supervisory authorities rarely have experience in operating systems for handling automatic updates of a central European registry – let alone in real-time, if the requirement for updates and notifications “without delay” is to be fulfilled. The EBA has already stated that they do not have the resources needed to ensure that the central TPP register is updated instantly, which means that somebody other than the EBA must ensure that both the national registers are established and updated and that all updates are transferred to the central EBA register.

National or European coverage This is not a simple task, and it seems to call for resources and competencies from a dedicated and independent specialist body which will be able to establish consistent procedures in all member states for the collection of data and develop and maintain a Pan-European register on behalf of the EBA and all the E.U. countries. However, even if some of the member states manage to establish and maintain a national register, it is most likely to fall short very quickly since the TPPs applying for access to account may come from all over Europe and therefore will not appear on the national list no matter how detailed or updated it might be. For instance, if a Swedish TPP wants to operate on the Danish market it must inform the Danish authorities beforehand. The problem arises if the Swedish authorities decide to withdraw their permission, and nobody informs the Danish authorities, since there is no obligation to do so. These problems might just seem like technicalities, but the fact is that in a situation where the European banks are unable to perform a fast and trustworthy assurance of the TPPs wanting access to customer accounts, the banks may face serious difficulties meeting the requirements of the PSD2 directive.

A matter of security Obviously, the banks cannot jeopardise security by opening up to TPPs unless they have absolute certainty of their identity. But the case is much more complicated than this because just getting the registers in place doesn’t solve the problem of verifying a certain TPP’s identity. The register only solves one part of the problem. The banks still need to be able to ascertain whether a TPP, claiming to be one of the TPPs recorded in the register, actually is that TPP. In accordance with Article 15 in PSD2 the “EBA shall make the register publicly available on its website”, and since this means that anybody can find the names of the TPPs registered and claim that they are one of them, a secure authentication method and procedure is needed for the banks to ensure that the TPPs are who they claim to be.

>>back to content

A NORFICO PSD2 WHITE PAPER MAY 2017 PAGE 5


4. h  ttps://www.eba.europa.eu/ documents/10180/1548183/ Consultation+Paper+on+draft+ RTS+on+SCA+and+CSC+ %28EBA-CP-2016-11%29.pdf, p. 21 5. h  ttps://www.eba.europa.eu/ documents/10180/1548183/ Consultation+Paper+on+draft +RTS+on+SCA+and+ CSC+%28EBA-CP-201611%29.pdf p. 21. Option 2 was: ”website certificates issued by a general Certificate Authority.” And option 3 was: “bilaterally agreed certificates.” 6. h  ttps://www.eba.europa.eu/ documents/10180/1548183/ Consultation+Paper+on+draft+ RTS+on+SCA+and+CSC+ %28EBA-CP-2016-11%29.pdf, p. 22 7. An example is the joint response to EBA from Payments UK, FFA UK and UK Cards Association: “As laid out in PSD2 the TPP has a requirement to authenticate itself to the ASPSP. As well as authentication, the ASPSP also needs to be able to verify that the TPP is indeed licensed and able to carry out the services it is requesting access to. We, therefore, think it is vital that the EBA Register is not a simple text description of accredited companies, but that it has interactive functionality (that could be accessed via e.g. an API). This functionality should include a ‘digital certificate’, which can also be attached to communication messages between the TPP and ASPSP.” http://www. paymentsuk.org.uk/sites/default/ files/EBA%20RTS%20Discussion%20Paper%20Response%20 -%20PUK,%20FFA%20UK,%20 UKCA%20-%208%20Feb%20 15%20FINAL.PDF p. 7.

Digital certificates The directive itself does not suggest any method in particular of securely establishing the identity of a TPP knocking on a bank’s door, but in its consultation paper published in August 2016 the EBA (in chapter 3.2.4) thoroughly discusses “common and secure open standards of communication for the purpose of identification, authentication, notification, and information” and as part of this considers different ways for TPPs to identify themselves towards the banks/ASPSPs. The EBA writes: In relation to the issue of how ASPSPs, PSPs issuing card-based payment instruments, AISPs and PISPs should identify themselves, the feedback received to the DP [Discussion Paper] on the section dedicated to possible synergies with eIDAS shows that there is a broad consensus for the use of certificates for ensuring identification between these providers.”4 To further dive into the issue of certificates as an identification solution the EBA organised a workshop in April 2016 with the participation of ASPSPs and TPPs (AISPs and PISPs). Three different kinds of certificates were discussed, but one was highlighted as the preferred option: Option 1: website certificates issued by a qualified trust service provider under an eIDAS policy, that would in particular include the name of the institution, its licensing number, the competent authority that has delivered the license, and the services provided by the PSP (AIS, PIS, both PIS and AIS, PSPs issuing cardbased payment instruments or ASPSP).”5 And the EBA explains the advantages and a single downside of the preferred solution: The advantages include that qualified trust service provider issuing the website certificate would verify for a legal person the name of the legal person to whom the certificate is issued and, where applicable, the registration number as stated in the official records and would take liability in case of oversight. In addition, the certification authority is itself subject to supervision by the supervisory body designated by the relevant Member State under the eIDAS framework to ensure that it performs its verification properly”. It is not yet clear, however, whether any certification authority will have applied to the supervisory body designated by the relevant Member State under the eIDAS framework for the status of qualified trust service provider under eIDAS by the time of implementation of the draft RTS (i.e. October 2018 at the earliest, and certainly not by the delivery deadline of the EBA’s RTS in January 2017).”6 And who will ensure that the issuer of a certificate blocks the certificate, if the authority decides to withdraw a permission given to a TPP?

More practical questions Amongst the parties7 who have been considering the problem of how the TPPs should identify themselves when approaching the banks/ASPSPs, there seems to be a broad consensus that the use of digital certificates is an appropriate and preferred solution. But this raises a couple of new questions about roles and responsibility – and about new registers or lists of different types of European certificates and their issuers to be added to the already discussed EBA TPP register. “Website certificates issued by a qualified trust service provider under an eIDAS policy” cover a broad range of certificates and not just one single certificate for all the EU member states. >>back to content

A NORFICO PSD2 WHITE PAPER MAY 2017 PAGE 6


Who should issue the certificates?

8. h  ttp://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32014R0910&from=EN p. 84 & p. 111. 9. “ Information provided by MSs (as of 1 January 2016): eID cards in 15 MSs (6 planned), other eID means in 24 MSs 25 MSs having either an eID card or other eID means.” http://ec.europa.eu/health//sites/health/files/ehealth/ docs/ev_20160607_co03_en.pdf 10. https://ec.europa.eu/digital-single-market/en/trust-services-and-eid

The eIDAS Regulation (EU) No 910/2014 says that ‘qualified certificate for electronic signature’ should be issued by a qualified trust service provider and meet “the requirements laid down in Annex I”8 of the regulation. And in Europe as of January 2016 25 EU member states9 already had eID schemes issued by qualified trust service providers who will be allowed to issue PSD2 certificates for the TPPs as well. Some examples of qualified service providers are the organisations behind public eID-schemes such as BankID in Norway, BankID in Sweden, NemID in Denmark, Tupas in Finland, DNIe in Spain, iDIN in Netherlands and ESTeID in Estonia. The Pan-European perspective was one of the most important aspects of the eIDAS Regulation adopted in 2014, and was meant that people and businesses were able to ”use their own national electronic identification schemes (eIDs) to access public services in other EU countries where eIDs are available.”10

EIDAS - ANNEX I REQUIREMENTS FOR QUALIFIED CERTIFICATES FOR ELECTRONIC SIGNATURES Qualified certificates for electronic signatures shall contain: (a) an indication, at least in a form suitable for automated processing, that the certificate has been issued as a qualified certificate for electronic signature; (b) a set of data unambiguously representing the qualified trust service provider issuing the qualified certificates including at least, the Member State in which that provider is established and: -for a legal person: the name and, where applicable, registration number as stated in the official records, -for a natural person: the person’s name; (c) a  t least the name of the signatory, or a pseudonym; if a pseudonym is used, it shall be clearly indicated; (d) e  lectronic signature validation data that corresponds to the electronic signature creation data; (e) details of the beginning and end of the certificate’s period of validity; (f) the certificate identity code, which must be unique for the qualified trust service provider; (g) the advanced electronic signature or advanced electronic seal of the issuing qualified trust service provider; (h) the location where the certificate supporting the advanced electronic signature or advanced electronic seal referred to in point (g) is available free of charge; (i) the location of the services that can be used to enquire about the validity status of the qualified certificate; (j) where the electronic signature creation data related to the electronic signature validation data is located in a qualified electronic signature creation device, an appropriate indication of this, at least in a form suitable for automated processing. CLICK ON THIS LINK TO READ MORE

>>back to content

A NORFICO PSD2 WHITE PAPER MAY 2017 PAGE 7


Is yet another list needed? The same goes for digital certificates approved accordingly to the regulation, but despite the fact that this is in many ways a very important innovation, it might also add even more complexity to the bank’s handling of the presumably many new TPPs approaching them for the purpose of getting access to customer’s payment accounts. Even though a Danish bank is certainly able to recognise the issuer of the Danish NemID called DanID as issuer of a digital TPP certificate, the same bank is not likely to be familiar with a Spanish or Estonian issuer. One might argue that recognising the issuer is irrelevant as long as the certificate lives up to the eIDAS requirements, and although this is true, the banks which have to open up their accounts are still likely to want a list of approved issuers of certificates to go with the list of approved TPPs.

Who to appoint the issuers? Even if we disregard the possible need for such a list, the introduction of digital certificates raises some additional and still unanswered questions. Though the EBA recommends the use of digital certificates, they have not appointed any qualified trust service providers as issuers, and they have not given any information about who should handle the appointments of service providers across Europe if not EBA themselves. This might seem trivial, but somebody needs to take responsibility for contacting the relevant service providers across Europe – like DanID in Denmark – and inform them about the task as issuers of the digital certificates i.e. when and how the task is expected to be carried out.

How do the TPPs get the certificates? Furthermore, the EBA still hasn’t provided any information or guidelines for the TPPs about how to obtain the certificates. The TPPs need to know from somebody that they are expected to obtain a digital certificate before approaching the banks. They also need a list of issuers, if the idea is, that they are responsible for contacting them, which seems logical. And they need some information about the procedures.

What if a certificate must be revoked? Finally, who is going to keep an eye on the issued certificates across Europe? The fact that a TPP qualifies for a certificate at a certain point in time does not mean that it still meets the requirements a year or two later. In case a TPP is about to close down due to bankruptcy one would expect that all certificates issued to the TPP should be revoked immediately. The issue here is – again – that neither PSD2 itself nor the EBA has delivered any guideline as to how these cases should be handled. It seems obvious that some sort of authority with a mandate to revoke certificates immediately – or at lease to initiate a revocation process - is needed to conduct controls on a regular basis. Unfortunately, no such authority has been appointed, at the questions raised here have not been addressed by the EBA yet.

>>back to content

A NORFICO PSD2 WHITE PAPER MAY 2017 PAGE 8


Conclusion As the discussion above showed we are not only missing the EBA register and a list of issuers of certificates, but there are a lot of unanswered questions and non-existing processes and procedures that need to be in place before the encounters between the TPPs and the banks make any sense at all, and the banks dare to open up their accounts as required by the PSD2. This unsustainable situation is partly due to a huge workload, especially in the EBA, and it is important to underline that nobody is to blame. Bringing PSD2 into force is a gigantic task, not at least because a lot of stakeholders have contributed with questions to the EBA, and the EBA is obliged by law to answer all of them individually. The bottom-line is that one of the most fundamental prerequisites for a successful roll-out of the new European Payment Service Directive is solid construction, particularly behind the highly important encounter between the TPPs and the banks / ASPSPs, and at this point, we find this construction to be inadequate. For these complex issues to be solved, we believe that the introduction of a new role within the PSD2 ecosystem might be necessary. The EBA cannot accomplish this task alone; some independent and dedicated service provider is needed to focus solely on the issues and questions discussed in this white paper. This new role will be of a coordinating nature, and it will aim at establishing clear communication lines between the TPPs, the ASPSPs, the national issuers of digital certificates, the EBA, and the bank/TPP customers. It will encompass a mapping of both the issuers of certificates and the TPPs – and thereby act as a direct help for the EBA. Additionally, the role could be extended further and include a service for the banks to outsource the regular checks of already issued certificates as well as regular checks of issuers, and not at least the TPPs. Whist we at Norfico are engaged with this subject, and are happy to remain involved, we we would like to invite the EBA and other relevant parties within the PSD2 ecosystem to think about how best to handle these challenges. In order to successfully cut through the complexity, we need procedures and processes as well as dedicated resources to focus entirely on making this work in practice.

>>back to content

A NORFICO PSD2 WHITE PAPER MAY 2017 PAGE 9


About Norfico Norfico is the first fintech agency in the Nordics combining strategic advisory with professional communication Services. We offer strategic advisory and communication services with a dedicated focus on fintech – including ID, payments, connected commerce regtech and insurtech. We work with clients across Europe and North America to develop strategy, markets, platforms and positioning by combining in-depth industry knowledge with efficient use of strategic and tactical communication. Norfico is one of the founding members of The Global Fintech PR Network - www.globalfintechprnetwork.com - which is the first global association of independent PR and Communications agencies solely focused on the fintech sector. For more information about Norfico, please visit www.norfico.net or https://twitter.com/Norfico.

If you want to contact the authors of this white paper: Michael Juul Rugaard Partner, Norfico michael@norfico.net +45 9399 3883

Kristian T. Sørensen Partner, Norfico kristian@norfico.net +45 2625 2065

>>back to content

A NORFICO PSD2 WHITE PAPER MAY 2017 PAGE 10

Profile for Norfico

The Tricky Encounter - A PSD2 Whitepaper from Norfico  

A PSD2 white paper about TPPs meeting ASPSPs by Norfico

The Tricky Encounter - A PSD2 Whitepaper from Norfico  

A PSD2 white paper about TPPs meeting ASPSPs by Norfico

Profile for norfico

Recommendations could not be loaded

Recommendations could not be loaded

Recommendations could not be loaded

Recommendations could not be loaded