Faculty of Electrical Engineering, Mathematics & Computer Science
Balanced, as all things should be:
PSD2 and cybersecurity risks
Dragos
,-Marian Chivulescu M.Sc. Thesis
July 2021
Senior Examiner:
prof. dr. A. Peter Supervisors:
dr. ing. F.W. Hahn
dr. A. Abhishta
S. Fransen
Computer Science Group
Faculty of Electrical Engineering,
Mathematics and Computer Science
University of Twente
P.O. Box 217
7500 AE Enschede
The Netherlands
The revised Payment Services Directive (PSD2, Directive (EU) 2015/2366 is now in full use in the EU. PSD2 mandates how the payment user information can be trans- ferred to and used by third parties, a measure aimed at welcoming new participants to the market. PSD2 makes use of Regulatory Technical Standards (RTS) for guid- ance on the new market processes. While many studies focused on the RTS on Strong Customer Authentication (SCA) aspect of PSD2, the Common and Secure Communication (CSC) dimension has been mostly overlooked. This exploratory re- search investigated whether the RTS on CSC increased the overall cybersecurity risk level, given the new payments ecosystem, and if PSD2 does not, in fact, make e-payments less secure (opposite of the objective of the directive).
The research used a qualitative approach to understand better the effects of a principle-based regulation on the cybersecurity of the regulation’s subjects. After placing PSD2 in the overall trend of Open Banking and analyzing the background information on the topic, an understanding of CSC is created based on the RTS of- ficial guidelines. Then, a risk assessment on the cybersecurity aspects of CSC was performed, using a methodology developed from the industry standards, ISO 27005 and NIST 800-30. After the risks have been identified, the relevant market partici- pants subject to these risks in the Dutch e-payment market have been discovered. A subset of these participants has been interviewed using a semi-structured approach to verify the previously found risks. Ultimately, CSC was deemed not to increase the overall cybersecurity risk for Dutch e-payment market participants and PSD2 to make e-payments safer and more secure, as planned by the European regulators.
ii
The present work represents the final project of my master’s studies, studies that have taken me to two foreign countries, France and the Netherlands. While more than half of my studies were online and were affected by the start of the COVID-19 pandemic, I managed to adapt, overcome challenges and, most importantly, learn in the new reality. This journey introduced me to the world of payments and showed me, once again, how important is cybersecurity for our daily lives. I am happy with the outcome of this research and grateful for everything I have learned.
Completing this work would not have been possible without the help and guidance of some extraordinary people. Firstly, I would like to thank my family, in Romania and abroad, for their unconditional love and support. Secondly, my team of super- supervisors, Abhishta, Florian and Sanne, challenged me and made me ask more of myself. Consequently, the supportive colleagues of EY Netherlands gave me the opportunity to do this thesis in an engaging work environment full of bright minds and ideas. While a large number of colleagues contributed, directly and indirectly, special thanks go to Rudrani Djwalapersad and Vanessa Sim˜oes de Azevedo. The thesis couldn’t have been completed without the interview participants who dedi- cated their time and expertise to aid understanding on the topic of PSD2. Last but not least, all my friends, inspiring and optimistic, deserve mentioning for supporting me throughout this period.
Dragos
,-Marian Chivulescu July 2021
iii
Summary ii
Acknowledgments iii
1 Introduction 1
1.1 Research Questions . . . . 2
1.1.1 Scope . . . . 3
1.1.2 Sub-questions . . . . 4
1.2 Methodology . . . . 4
1.2.1 Stage I . . . . 5
1.2.2 Stage II . . . . 6
1.3 Ethical considerations . . . . 7
1.4 Contribution . . . . 7
1.5 Document outline . . . . 8
2 Background 10 2.1 Open Banking . . . 11
2.2 Payment Services Directive 2 . . . 12
2.3 Regulatory Technical Standards . . . 13
2.4 Application Programming Interface . . . 14
2.5 Qualified certificates . . . 15
2.6 Conclusion . . . 16
3 Common and secure open communication 17 3.1 Articles . . . 17
3.1.1 Article 25 - Requirements for identification . . . 17
3.1.2 Article 26 - Traceability . . . 17
3.1.3 Article 27 - Communication interface . . . 18
3.1.4 Article 28 - Obligations for dedicated interface . . . 18
3.1.5 Article 29 - Certificates . . . 19
3.1.6 Article 30 - Security of communication session . . . 19
iv
3.1.7 Article 31 - Data exchanges . . . 20
3.2 Technical details . . . 20
3.3 Impacted assets . . . 21
4 Risk assessment 23 4.1 Context establishment . . . 23
4.1.1 Risk assessment purpose . . . 24
4.1.2 Risk evaluation criteria . . . 25
4.1.3 Impact criteria . . . 25
4.1.4 Risk acceptance criteria . . . 26
4.1.5 Scope and boundaries . . . 26
4.2 Risk identification . . . 27
4.2.1 Identification of assets . . . 27
4.2.2 Identification of threats . . . 28
4.2.3 Identification of existing controls . . . 30
4.2.4 Identification of vulnerabilities . . . 30
4.2.5 Identification of consequences . . . 32
4.3 Risk estimation . . . 39
4.3.1 Risk estimation methodology . . . 39
4.3.2 Assessment of consequences . . . 39
4.3.3 Assessment of incident likelihood . . . 45
4.3.4 Level of risk estimation . . . 60
4.4 Risk evaluation . . . 68
4.5 Conclusion . . . 69
5 E-payment market participants 70 5.1 General roles . . . 70
5.2 Dutch organizations . . . 71
6 Interviews 74 6.1 Interview approach . . . 74
6.1.1 Interview methodology . . . 74
6.1.2 Interview participants . . . 76
6.2 Interview answers . . . 76
6.2.1 Common and Secure Communication cybersecurity risks . . . 77
6.2.2 Common and Secure Communication and PSD2 opinion . . . 80
7 Discussion 86 7.1 Interview outputs . . . 86
7.2 Research limitations . . . 93
7.3 Future directions . . . 94
8 Conclusion 96 8.1 Sub-questions . . . 96
8.2 Main question . . . 98
Appendices A Appendices 111 A.1 Dutch licensed credit institutions subject to PSD2 . . . 111
A.2 Dutch licensed payment institutions subject to PSD2 . . . 115
A.3 NIST 800-30 Assessment scale - Impact of Threat Events . . . 117
A.4 NIST 800-30 Assessment scale - Likelihood of Threat Event Initia- tion/Occurence . . . 118
A.5 NIST 800-30 Assessment scale - Likelihood of Threat Event Resulting In Adverse Impacts . . . 119
A.6 NIST 800-30 Assessment scale - Overall likelihood . . . 119
A.7 NIST 800-30 Assessment scale - Level of risk . . . 120
A.8 Human threat sources . . . 121
A.9 Interview protocol . . . 123
A.10 Interview respondents . . . 125
Introduction
The revised Payment Services Directive (PSD2, Directive (EU) 2015/2366) came into full effect in the EU after the extended deadline for implementing Strong Cus- tomer Authentication (SCA) has passed on 31st December 2020 [1]. The directive replaces the original Payment Services Directive (PSD, or PSD1; from 2007), provid- ing a legal framework for the new market realities. PSD2, which was initially passed by The Council of the European Union in 2015 [2], underwent many changes, revi- sions and a substantial amount of lobbying from the parties involved [3]. The revised directive can be seen as a step towards Open Banking in the EU, a new paradigm of digital banking. PSD2 proposes three main objectives. The first objective is to strengthen the European market for e-payments. The second objective concerns the development of innovative payment services enabled by opening the market to new entrants. Lastly, it aims to make e-payments safer and more secure.
To achieve these objectives, the European Banking Authority (EBA) released Reg- ulatory Technical Standards (RTS), a legal document that offers guidance on the technical implementation of the new systems needed to comply with the PSD2 leg- islation [2]. The main standard comprises Strong Customer Authentication (SCA) and Common and Secure Communication (CSC).
SCA is authentication that uses “two or more elements categorized as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something only the user is)” [2]. This is the same approach used in multi-factor authentication schemes but presents a few exceptions when less strong authentication can be used.
CSC represents the way Account Servicing Payment Service Providers (ASPSPs) are required to open communication channels that: allow Account Information Ser- vice Providers (AISPs) and Payment Initiation Service Providers (PISPs) to identify
1
themselves ahead of transferring payment service users (PSUs)’ data; send, re- quest and receive information on one or more payment accounts and associated transactions; initiate a payment order from the payer’s payment account. This com- munication is done through APIs; if an API is not provided, the ASPSPs have to allow the use of a “customer-facing interface”. The customer-facing interface is usu- ally the standard web page of the ASPSP, used by customers in Internet banking.
This interface must use an identification process between the ASPSP and the third party (essentially screen-scraping 1 , with extra steps.). The identification process, which must be present in the API access, must use qualified certificates. These qualified certificates are special certificates used to secure the communication and digital signatures (proving an entity’s identity), and their specifications come from a European regulation called eIDAS [4].
If we focus on the PSD2 objective to make e-payments safer and more secure, we observe an apparent asymmetry. On the one hand, traditionally, financial institutions such as banks presented advanced security measures due to them being highly regulated and complying with different industry standards [5]. This was the status quo in an environment where banks had complete control over the systems the users interacted with and the data the clients used. On the other hand, new companies such as FinTechs usually lack cybersecurity maturity [6] as they focus primarily on user-centricity. The e-payment chain is now longer under PSD2, and the attack surface seems to be more prominent [7]. As cybercrime continues to be on the rise 2 , the cybersecurity implications of this asymmetry become important.
A question arises: Has PSD2 had a negative effect on the cybersecurity of e- payment organizations, despite its goal of making e-payments more secure?
1.1 Research Questions
In order to state the research question, a working definition for the key variable must be provided, not being possible without defining the crucial concepts. Cyberse- curity 3 can be defined as protecting different assets from “unauthorized access or criminal use and the practice of ensuring confidentiality, integrity and availability of information” (commonly abbreviated CIA). The first step in improving cybersecurity is to recognize the risks. The more risks are identified, and the more critical they
1
Process of collecting data displayed on the screen from one application and translating it so that another application can display it
2
https://www.accenture.com/us-en/insights/security/cost-cybercrime-study
3
https://us-cert.cisa.gov/ncas/tips/ST04-001
are, the less secure organizations are 4 .
After defining the key variable, the main research question can be formulated:
Research question:
What was the effect on the cybersecurity risks of e-payment market participants following the implementation of PSD2?
1.1.1 Scope
This subsection outlines the research scope.
Firstly, as we have seen, PSD2 proposes a number of RTS that have technological implications. Many pieces of work have been dedicated to SCA, an element of RTS, sometimes by leveraging the multi-factor authentication technical problem (as can be observed in the Background chapter). CSC has received less attention, a research gap being identified. Thus, studying the details of the common and secure communication aspect of PSD2 comes naturally.
Additionally, the RTS present many articles and paragraphs that concern the gov- ernance of the processes around the technical changes mandated by the revised directive. In this paper, the focus lies on technical cybersecurity risks and not on factors such as processes, policies, resilience, reporting or crisis management. A future expansion of the present work might include these aspects.
Lastly, this paper focuses on the e-payment market, the country where the author studies and works. There are multiple reasons for choosing this scope. Firstly, the EU comprises multiple e-payment markets with distinctive traits (such as size, growth [8]), making the overall European market non-uniform. In this reality, con- textualization is important for observing trends, and one way of achieving this is by focusing on one national market. Secondly, the Netherlands has a highly digital na- tional payment market since before PSD2 came into effect [9]. This factor can have significance when considering the new digital systems needed for the legislation, as the payment providers already use advanced technology systems. Lastly, a good collaboration can be observed in the Dutch payment market, proved by several joint initiatives (e.g., iDeal, iDin, Dutch Payments Association). These initiatives show the desire of market participants to continuously improve their offerings.
In order to answer the research question in the defined scope, a number of sub- questions have been elected.
4
Please note that there might be other definitions.
1.1.2 Sub-questions
Using the background information, the first sub-question is:
(I) What are the main technical implications of CSC?
This sub-question aims to compare and contrast the technical details that stem from CSC’s changes to organizations in the e-payment sector in the Netherlands. Under- standing these provisions is essential for assessing the risks, which is the aim of the next sub-question:
(II) What are the cybersecurity risks related to CSC?
The second sub-question builds upon the first one by using the identified technical details and knowledge from the literature as a first step in performing a risk anal- ysis of CSC. Next, it is essential to identify the organizations for which these risks are applicable, as not managing risks effectively can have negative consequences (financial, reputational and legal, to name a few).
(III) Who are the relevant stakeholders for CSC in the Dutch e-payment market?
This sub-question presents the different entities that are subject to CSC. After the relevant stakeholders have been identified, their general experience with CSC-related risks can be discovered:
(IV) What cybersecurity risks have been encountered by the relevant stakeholders in the Dutch e-payment market with regards to CSC?
The fourth sub-question’s objective is to validate the risks identified previously and possibly extend the risk model. This is relevant for understanding the difficulties that the relevant stakeholders face, in their quest to serve their clients, comply with regulators and avoid security incidents.
(V) Do relevant stakeholders in the Dutch e-payment market think CSC increased their overall cybersecurity risks?
Finally, the perception of the relevant stakeholders helps probe the cybersecurity effect of the common and secure communication technical standard and allows to answer the main research question.
1.2 Methodology
This section describes the methodology used for conducting the research. Ex-
ploratory in nature, due to the gaps identified in the research, the approach is one
of a qualitative, exploratory case study with a holistic design - single unit of analysis
at different cases [10]. Yin provides five constructing components, being addressed as the following:
• research question - defined in the Research Questions subsection;
• propositions - stemming from the descriptive analysis, detailed below;
• unit of analysis - the risks (description and severity) identified at e-payment market participants in the Netherlands, related to the systems mandated by the CSC standard;
• logic linking of the data to the propositions - a supposition is proposed after the first stage of the research, which is verified for accuracy in the second stage, allowing the possibility of extension;
• criteria for interpreting the findings - comparing the initial set of risks with the ones produced following semi-structural interviews.
For ease, two main stages of the research have been devised:
Figure 1.1: Research stages. SQ - Sub-question; RQ - (main) research question
1.2.1 Stage I
The first stage of the research has two parts. Firstly, the research uses the descrip-
tive analysis [11] of the legislation surrounding PSD2 (such as [2], [4], [12], [13]). A
descriptive analysis identifies “the characteristics of the population or situation being
studied”. This approach provides a solid understanding of the cybersecurity-related
aspects of CSC (zooming in on APIs and qualified certificates). In this part, the an-
swer to the first and third sub-questions can be formulated. The answer to the first
sub-question is provided through the study of CSC in the RTS and relevant litera-
ture. The third sub-question can be answered from the study of the PSD2 legislation,
which identifies the roles in the new e-payment ecosystem, and the background in-
formation, which discusses the relationships between actors in the market.
Secondly, relevant cybersecurity risk assessment frameworks and guidelines ( [14], [15]) used in practice by financial organizations and recommended by regulators are used to perform the risk assessment for the technical aspects of CSC. More precisely, Clause 7 and 8 of ISO 27005 (“Information security risk assessment”) and Chapter Three of NIST 800-30 (“The process”) provide the approach and steps for performing a risk assessment. Using the technical details and (organizational) assets related to CSC (the outcome of the last part) as a starting point for the risk assessment, the answer to the second sub-question can be formulated.
The outcome of this stage is a list of cybersecurity technical risks (description and severity) regarding the CSC requirements of PSD2.
1.2.2 Stage II
The second stage has two parts as well.
Firstly, using the previous stage’s output, a verification process is established through conducting semi-structured interviews with relevant stakeholders from the e-payment market in the Netherlands. This qualitative research approach is useful to provide new insights and to explain phenomena [16].
The semi-structured interviews are used to gather empirical data and build a theo- retical model. They provide flexibility which facilitates the expression of ideas from the respondents. This approach enables the respondents to use their own words and base their statements on their own relevant personal experience [16]. The inter- views are conducted in English, recorded, and then transcribed to enable a thorough analysis. A pilot interview is conducted before the official interviews to help refine the data collection plans. Access to the respondents is offered by EY Netherlands and its business network, thanks to the author’s thesis internship at EY Netherlands.
This aspect aids the process by leveraging the expertise and connections accumu- lated in the company through their FSO Cybersecurity consultancy business. An emphasis is put on the respondents’ role and the relation to the cybersecurity aspect of PSD2. Furthermore, a diverse group of respondents from different organizations is desired. This part aims to answer the last two research sub-questions.
For the second and final part of the research, the output of the interviews, a new list
of verified cybersecurity risks related to CSC, is compared to the initial list, highlight-
ing any significant differences and arguing for the underlying causes. The validation
process answers the main research question of this work.
1.3 Ethical considerations
A critical aspect of each research endeavor is its morality. True advancement of science should be undergone in an ethical manner.
Firstly, this research aims to be an open and truthful academic work. The pre- requisites, scope, limitations and findings are explicitly presented, giving any reader the possibility to verify their veridicality.
Secondly, the present paper requires the participation of human subjects; thus, their rights and liberties must be protected. In order to do so, the description of the re- search, aims, and objectives, are presented to the interview participants from the initial touchpoint, allowing them to be involved in the research or decline. The in- terviewees answer anonymously, the employee’s names and the employer are re- moved, the latter being replaced by a generic description (e.g. ASPSP).
The interview recordings have a private character, not being shared with the public, being available only to the respondent giving the interview, the author of this work and the committee supervising this research. The storing of the interview recordings is done securely and redundantly, the copies being destroyed after enough time has passed after the defense of this work or on participant request.
1.4 Contribution
In this subsection, the relevance of the research and its contribution is presented.
This research is useful for several reasons:
• Provides insights for a current theme that is PSD2, after the legislation has been finalized;
• Discusses concepts that the literature has mostly omitted in this context;
• Acts as a starting point for a discussion on the effects of the revised Payments Directive;
• Provides insights that might be valuable in future research needed for the sub- sequent directives and legislation;
• Identifies risks and challenges that might arise for a new organization that joins the e-payment ecosystem;
• Helps companies in the e-payment market with their risk assessment process
by providing a starting point for the determination of residual risk.
The resulting artifact of the research is the present academic paper, which is com- prised of different sections.
1.5 Document outline
The research findings are organized in chapters. An overview of the chapters can be seen in Figure 1.2. The arrows represent how one chapter relies on the infor- mation presented in the previous one. The last two chapters rely on the information presented throughout the whole paper.
Figure 1.2: Document outline
The first chapter introduces the reader to the research theme using a high-level overview of the PSD2 legislation. Then, a research gap is identified, which prompts the creation of the research question. Having set a scope, five sub-questions are formulated for guiding the research. The rest of the chapter concerns the chosen methodology, the research contribution and the paper outline.
The second chapter, entitled “Background”, provides the necessary background in- formation of the concepts closely related to the research: Open Banking, PSD2, RTS, API and qualified certificates, using official documents and literature work as sources.
Chapter 3 describes the articles from the RTS that make up the “Common and secure open communication” technical standard and answers the first research sub- question.
The Risk Assessment chapter presents the application of the risk assessment method- ology to the case of CSC for e-payment organizations, following the ISO and NIST standards. This chapter answer the second sub-question.
Chapter 5, which answers the third sub-question, uses information from the back-
ground study to identify the relevant stakeholders of the second Payments Directive
in the Netherlands.
The interviews chapter explains the method and the output of the interviews per- formed with relevant e-payment market participants from the Netherlands. The chapter is organized according to the main discussion topics.
In the Discussion chapter the answer to the last two sub-questions are provided.
Additionally, a critique of the research and future improvements are discussed.
Finally, the last chapter provides a conclusion of the research, highlighting the main
findings.
Background
In this chapter, relevant background information is presented. The methodology used for discovering the relevant scientific work is the snowball strategy or “cita- tion pearl growing” [17]. This strategy complements the use of a large selection of official documents and standards, the vast majority of the relevant concepts being described from legal and regulatory texts. The snowball strategy entails starting from a few relevant documents for the topic and adding works that are related, have been referenced or cited, in the initial selection. The analysis of literature ends when convergence to the previously discovered items is observed.
The repositories used for finding scientific work are Scopus, Web of Science and Google Scholar. The papers which were not offered under open access or pro- vided access using the University of Twente’s institutional login were discarded.
Since PSD2 was passed as legislation in 2015, the literature older than 2015 was discarded as well. The author does not expect to miss many relevant documents through this elimination.
The keywords used for searches (by themselves or in combinations) are, in no partic- ular order: PSD2, PSD II, payment services directive, Open Banking, API, payments security, qualified certificates, qualified signature, API, RTS, CSC, SCA, cybersecu- rity risks, ISO 27005, NIST 800-30.
The chapter is structured according to the main concepts related to the present work.
Some overlaps can be observed between closely related concepts. Definitions and references to official documents are provided, where these have not been supplied previously.
10
2.1 Open Banking
We begin the state-of-the-art with Open Banking, as the general current of which PSD2 is part of. Open Banking is defined as “an initiative which facilitates the secure sharing of account data with licensed third parties through APIs” [18]. [19] traces the origin of Open Banking to the Competence Center Electronic Markets in Switzer- land and the attempt to create an electronic market for the leading Swiss banks in the mid-1990s. This initiative failed mainly due to discussions of market influence and ownership. Today, we witness regulatory-driven initiatives like PSD2 in Australia and Hong Kong and market-driven initiatives in the US, Singapore, India, and South Korea [20]. One can already observe a certain level of fragmentation and diversity in approaches. O’Leary et al. note a lack of maturity and global standards, which act as inhibitors for developing digital systems in Open Banking. One can spec- ulate that this lack of maturity and standards can affect the cybersecurity risks in the market. However, it is worth noting that some standards emerged in Europe, the most prominent ones being The Berlin Group NextGenPSD2, a pan-European initiative [21] and Open Banking Standard from the United Kingdom [22].
[19] and [23] suggest that currently, we are moving more towards “platform banking”
than Open Banking. Platform banking entails accessing a specific “banking-mix” as named by Dratva, which are services offered by a provider’s ecosystem and not a truly open marketplace, as Dratva defines Open Banking. Zachariadis in [24]
also notices the emergence of platform banking. He also mentions the problems incumbents in the financial sector have with legacy IT systems. Solutions start to emerge in this sphere, for example, [25] proposing a technique for identifying scala- bility threats as a form of tech debt used at a Nordic FinTech company.
[26] highlight the API as the enabler of Open Banking but draw attention to how APIs represent a new attack vector for cybercriminals. [7] calls this new attack vec- tor “man in the middle”, as PSPs become an extra step in the interaction between users and traditional financial institutions, hinting at the popular class of attacks well known in the cybersecurity world. The risk of API as a new attack vector can be identified. Mansfield-Devine is optimistic that multi-factor authentication (SCA) can increase the security of payments. [27] successfully predicted, before PSD2 being in full effect, that the need for APIs might drive the market towards the emergence of “gateway service providers” 1 . As the specifications of the “off-the-shelf” gateways are not usually publicly disclosed, their security is hard to assess. Assessing the risk of such external systems and partners falls under Third-Party Risk Management and
1
Examples of these are https://www.axway.com/en/solutions/financial-services , https:
//connect.finleap.com/ and https://www.sibsapimarket.com/
is outside of the scope of this paper. However, UK’s Open Banking standard, just like the Berlin Group’s standard, is public. [28] present a formal security correctness proof of the Open Banking standard.
Lastly, Open Banking might not bring innovation only in the financial sector. [29], for example, proposes a way of calculating one’s carbon footprint by analyzing one’s transactions, leveraging the Swedish digital identity scheme and Open Banking.
We can draw a few conclusions regarding Open Banking initiatives. They are present in different geographies, usually materialize in “platform banking”, and help create innovation in terms of business models (gateway providers) or applications (carbon footprint). However, Open Banking poses cybersecurity challenges through new attack vectors and risks emerging from additional parties like gateway providers.
2.2 Payment Services Directive 2
In this section, PSD2, a regulatory-driven Open Banking initiative, is presented through the lens of recent literature. The selection presented here focused on work that emerged after the legislation has been finalized to eliminate the speculations regarding the final form of the directive and its associated documents.
In terms of the need for the regulation, [30] believes that PSD2 did not emerge from customers wishing for a more open e-payment market. [31] highlights that a more important goal from European political leaders was to challenge the US credit card scheme duopoly, Visa and Mastercard.
Observing the effects of PSD2, [32] studied the distribution of PSP licenses up to January 2020. As much as 75% of licenses were obtained by companies already operating before the regulation has been introduced. This might show that PSD2 is not yet driving innovation by creating new companies but gives new directions for existing enterprises to diversify their offering. Polasik et al. also notice that one factor determining an increase in licenses in a country is offering “regulatory sandboxes”, which provides potential entrants with an environment to test ideas before launching.
This oferring might be a result of good national market collaboration. Collaboration can be useful in other ways, too: [33] mentions that in the Netherlands, through the Dutch Payments Association, organizations actively look for ways to reduce fraud, money laundering and other financial crimes. This collaboration will continue to be helpful in the context of PSD2.
[34] look at the rationale of accessing data under PSD2 (XS2A) and advocate for a
“reciprocity clause” that would enable the ASPSPs to use the insights and analytics
obtained by TPPs from the data they provide. In this article, BigTech is frequently mentioned and how the current state of affairs might exacerbate their monopolistic practices with XS2A. [35] and [36] also mention the negative effect BigTech might have on the competitiveness of the e-payment industry in the future, however speci- fying it is too early to confirm such effect. [31] presents a similarly pessimistic angle, reminding of how Apple (one organization included in the BigTech group) exclusively decided the terms of access to their current (non-financial) APIs. Platforms, in this respect, might create more barriers for developers and, ultimately, users.
To conclude, PSD2 might not have emerged from a customer market push. Despite trying to disrupt dominant market participants such as credit card schemes, it might introduce, in the future, players that will erode the market’s competitiveness, such as BigTechs. Ultimately, a collaboration between organizations is essential for PSD2 licensing and for continuing to tackle financial crimes.
2.3 Regulatory Technical Standards
The Regulatory Technical Standards, accompanying the directive, present signifi- cant changes for the e-payment market participants. The security of these changes has come under scrutiny.
[37] highlight that privacy and security are capital for the competitiveness on the market following PSD2. A study in South Korea shows that the reliability (which is one aspect of security) of mobile payment services is capital for user adoption [38], further adding to the argument that security is essential in an e-payment context.
[6] agrees that PSD2 (and RTS through extension) will pose security challenges for companies, mentioning different causes. Firstly, the author mentions how the “mind- set” of TPPs might not prioritize security to the same level banks do. [39] illustrate Noctor’s point with a security assessment of N26, a growing FinTech digital bank, which lacked many security controls. Secondly, APIs fragmentation and the need to integrate with multiple architectures might create complexity difficult to manage. A cybersecurity risk can be identified here.
[40] zoom in on the access to accounts (XS2A) component, mentioning the screen
scraping debate and how ultimately the advancement of the market is a more impor-
tant goal of the directive compared to security and privacy. This idea is reinforced
by [41], who present five different attacks for a proposed PSD2 architecture. While
most of these security vulnerabilities are being addressed by companies, it shows
that the new status quo is vulnerable if proper due care is not ensured.
[3] discuss how the RTS were debated and lobbied by companies in the financial sector who pushed for screen scraping not to be totally forbidden. The EBA currently accepts screen scraping as a fallback mechanism and demands authentication be- tween the scraper (TPP) and the information source (ASPSP). The fallback mecha- nism can be omitted if specific reasons to exempt are met. One can observe that the existence of the fallback mechanism increases the fragmentation in the data transfer sphere, which is already affected by the fragmentation created by the different API architectures.
[42] analyze PSD2 (SCA) and other similar regulations and standards through the lens of multi-factor authentication compliance. Their work is valuable as market participants must pay attention to more than one set of regulatory requirements. [43]
mention transaction manipulation attacks when the 2 factors of authentication rely on a single device. This is an important implication that developers of SCA systems must be aware of. [44] gives a warning sign regarding companies using SMS one- time passwords (OTPs) as a means of complying with SCA, as these have proved to be easy to abuse by hackers 2 .
In summary, the RTS have important cybersecurity implications, and organizations must prepare for challenges such as lack of maturity at TPPs, data transfer fragmen- tation leading to complexity, screen scraping and different inherent vulnerabilities of systems.
2.4 Application Programming Interface
In this section, APIs, one of the crucial aspects of the CSC regulatory technical standard, is presented from the literature.
At a basic level, an API is “a way for two computer applications to talk to each other over a network using a common language that they both can understand” [45].
Despite being around for some time, APIs present themselves as a novelty to many existing players in the e-payment industry. [36] state that banks should see the APIs and the emerging digital platform as opportunities, warning at the same time that the benefits will be observed in the long term. Zachariadis et al. compare this to Amazon, which needed several years to build excellent IT systems to become a global giant that offers user-centric services. [46] come to aid with an agile reference model for large barks to adopt APIs. [47] provide an overview of translating business needs of interoperability and data transfer to a FinTech API gateway. Their study
2
https://www.europol.europa.eu/newsroom/news/sim-highjackers-how-criminals-are-
stealing-millions-highjacking-phone-numbers
features a real-world implementation from a Turkish bank. On the other end of the process, [48] show an integration on an example technology stack and assess its security using OWASP’s Top 10 Web Application Security risks [49]. Their work highlights TLS and the communication channel’s security, an aspect explored later in this paper. [50] offers a systematic approach for PSD2 API testing and validation, with a focus on XS2A. An automated approach in the same context is presented by [51], which draws knowledge from [52] and OWASP’s Top 10 API Security issues [53].
Issues that were identified by [54] regarding APIs in a PSD2 context are function- ality and availability. Functionality is a challenge as integrations might be done in a
“watered down” fashion just to comply with the requirements or only with specific, large-enough partners, thus not achieving an ideal data exchange. This goes back to the idea of platforms and “banking-mix” of services, contrasting a truly open mar- ketplace. Availability is an inherent technical challenge that requires participants to build robust, scalable services, including the APIs and the fallback screen scraping mechanism, if present.
To conclude, much research has been done in the area of APIs for financial or- ganizations and in a PSD2 context, highlighting security risks and implementation advice, making use of reputable vulnerability sources such as OWASP.
2.5 Qualified certificates
In this section, qualified certificates for PSD2 will be discussed, from the legal grounds to what advancements the literature proposes.
[4] provides the framework for the legality of electronic transactions in the EU. Fol- lowing this regulation (eIDAS), different eID (digital identity) schemes have been developed or adapted to the standard. [55] analyzes the security of such schemes, finding 7 out of 15 of them being vulnerable. TLS is a common theme in these vul- nerabilities, a relevant aspect as TLS is used across the Internet for secure commu- nication. As the authors described it, “the insecurity of one component can bypass the security of the entire system, even if all the other components are secure”.
According to [4], a qualified digital certificate is a PKI certificate that ensures the data integrity and authenticity of an electronic signature and its related data (such as a message). It is issued by a qualified trust service provider (QTSP). The qualified certificate must present the following information:
• Details of the qualified trust service provider that produced the certificate, such
as: (EU) member state, name and registration number;
• Validation data, to be used electronically to validate the certificate;
• Validity of the certificate (starting and ending date).
The qualified certificates have different applications in e-governance: [56] show an integration of qualified electronic signatures with blockchain transactions for verifying academic diplomas; [57] employs homomorphic encryption for preserving privacy in the context of the Dutch eID scheme.
In a PSD2 context, the specifications for the qualified certificates are defined by [13]; [12] specifies their specific use cases for the different parties involved in the data transfers:
• QWAC - qualified certificate for website authentication - used for confidential communication and identification of PSPs to ASPSPs (without being able to verify the origin of the data present in the communication on its own);
• QSealC - qualified certificate for electronic seal - used for identifying PSPs to ASPSs (without ensuring the confidentiality of the transfer on its own).
In terms of literature focusing on PSD2 qualified certificates, [51] provide an example of how QWAC uses TLS to ensure the security of the communication and incorpo- rate TLS as a step in their testing framework. In general, one can observe a lack of focus of works discussing QWAC and QSealC in the current literature, this gap being explored in the present paper.
In summary, the specifications, technical details and use cases of qualified certifi- cates for digital signature stem from a legal basis from entities such as the European Parliament and EBA. The research around the subject mainly concerns applications in e-governance such as eID and less on PSD2 and the e-payment market.
2.6 Conclusion
In this chapter, an overview of the necessary background information has been pre-
sented in a structured way: starting from the top-level concept of Open Banking
towards the regulatory framework of PSD2, its technical aspects represented by
RTS and the systemic components APIs and qualified certificates.
Common and secure open communication
The term CSC was coined and originated in the RTS. The first section of this chap- ter is dedicated to a descriptive analysis of the CSC articles from the Regulatory Technical Standards. The second section summarizes the main technical aspects extracted from the articles and identifies cybersecurity requirements through their connection with CIA. The final section uses the previous two for observing the tech- nological assets that are needed or must undergo changes for CSC.
3.1 Articles
[2] discusses CSC in Chapter 5, “Common and secure open standards of com- munication”, covering articles 25 to 31. This section is structured according to the articles, providing a commentary for each of them.
3.1.1 Article 25 - Requirements for identification
The first CSC article stipulates that the PSPs must ensure secure communication between a payer’s device and a payee’s acceptance devices when making electronic payments. The article does not express how “secure” must be interpreted here.
3.1.2 Article 26 - Traceability
The Traceability article explains what traceability should be in the present context:
“ensuring knowledge ex-post of all events relevant to the electronic transaction in the
17
various stages”. Additionally, the article mandates a unique session identifier, times- tamps based on “a unified time-reference system”, and detailed logging of transac- tions data, including the transaction number.
3.1.3 Article 27 - Communication interface
Article 27 is the most extensive article concerning CSC from the RTS.
In paragraph 1, the reader is presented with requirements such as identification and secure communication between ASPSPs and TPPs. These detail entail that identification must also happen in the case of screen scraping.
In paragraph 3, the article requires that the “integrity and confidentiality of the per- sonalized security credentials” must be ensured, a more concrete explanation of secure communication than the previous parts.
Also, in this article, a distinction is made between a “dedicated” interface (API) and the interface users typically use for direct interaction with the ASPSP (which can be screen scraped). Both have to follow “standards of communication which are issued by international or European standardization organizations”. This detail is essential, as it shows how CSC relies on unnamed supporting standards, which can create confusion.
Lastly, testing facilities and support must be provided by ASPSPs for the interface(s) they make available.
3.1.4 Article 28 - Obligations for dedicated interface
This article provides additional rules for the dedicated interface. Firstly, it must have
“the same level of availability and performance” as the standard interface used by the users. Its availability and performance must be monitored. Lastly, the dedicated interface must use “ISO 20022 elements, components or approved message defini- tions, for financial messaging”. A high-level explanation of the ISO 20022 elements is given below.
ISO 20022 elements ISO 20022 [58] is a standard for message exchange be-
tween financial institutions. It aims to provide a common understanding of inter-
preting the data used in financial operations. The main provision of the standard
is the use of XML as the common syntax for messages. As XML is more verbose
than other syntaxes and the volume of data increases as technology becomes more
used, ISO 20022 mandates ASN.1 for encoding the data in XML for compactness
and improved encoding/decoding speed. These two elements, XML and ASN.1, are used for the definition of data structures. A “dictionary” which provides semantic descriptions for business components and types of messages is managed by ISO 20022 Registration Authority 1 . It is worth noting that in [59], a translation model is offered as an effort to adapt ISO 20022 concepts to the use of JSON syntax and RESTful APIs, which provides more freedom in adopting the standard.
3.1.5 Article 29 - Certificates
This article gives guidance on the use of digital certificates. The certificates that are to be used for CSC are qualified certificates for electronic seals (QSealC) and qualified certificates for website authentication (QWAC) as defined by eIDAS. Some changes to the eIDAS specifications are in place:
• The registration number specified by the certificate must be the authorization number given by a home member state to the PSP following the licensing process;
• An extra data entry in the certificate must be the role of the PSP, for example, PISP or AISP;
• An extra data entry in the certificate must be the “name of the competent au- thorities” where the PSP is registered, for example, the Dutch National Bank.
3.1.6 Article 30 - Security of communication session
In the first paragraph, Article 30 stipulates that secure encryption (“strong and widely recognized encryption techniques”) must be used during the communication be- tween all the PSD2 parties to safeguard the confidentiality and integrity of the data.
The subsequent paragraphs discuss how the communication access sessions must be “securely linked to the relevant sessions” of the PSUs to prevent “misrouting”
(other users or actors seeing details not belonging to their sessions). Furthermore, the sessions must be kept as short as possible and be terminated after the “re- quested action has been completed”.
The last paragraph of this article presents a restriction to the transferred data. The security credentials of users or authentication codes cannot be readable, directly or indirectly, by any staff.
1
https://www.pwc.dk/da/publikationer/2017/strong-customer-authentication-common-
secure-communication-psd2-nutshell-4.pdf
3.1.7 Article 31 - Data exchanges
The last article for “Common and secure open standards of communication” spec- ifies mostly functional requirements for the communication participants. One detail related to security is that if an interface does not function properly, the other ex- change participants must be notified; if there are problems with the API, this must give notification messages about the issues.
3.2 Technical details
After describing the CSC articles, a summary can be created from the essential points. The findings are presented in Table 3.1:
Technical details Article(s)
Secure communication (integrity and confidentiality) 25, 27, 30
Traceability 26
Unique, short-lived session which is linked to the right user 26, 30
Use of APIs 27
Testing facilities and support 27
Using ISO 20022 messaging concepts 28
Identification through (extended) QWAC & WSealC certificates 29 Strong and widely recognized encryption techniques 30 Participants notification in case of failure 31
Table 3.1: CSC technical details
The list can be refined in order to identify concrete cybersecurity requirements. The approach used for this is to tie a technical detail identified before to a direct way of preserving CIA (Confidentiality, Integrity or Availability) in information systems. For example, “Participants notification in case of failure” does not have a direct impact on CIA, the notification happening after the loss of CIA, not helping to prevent the loss. On the other hand, “strong and widely recognized encryption techniques” help preserve the confidentiality of communication, being selected as a concrete cyber- security requirement.
The results are listed in Table 3.2.
Cybersecurity requirements Article(s) Secure communication (integrity and confidentiality) 25, 27 Unique, short-lived session which is linked to the right user 26, 30 Identification through (extended) QWAC & WSealC certificates 29
Strong and widely recognized encryption techniques 30 Table 3.2: CSC cybersecurity requirements
3.3 Impacted assets
As shown in the previous sections, the RTS on CSC mandates changes to sustain the function of communicating PSU data. The assets affected by these changes are found in this section, completing the descriptive analysis of CSC. For identify- ing the organizational assets related to CSC, a working definition of “asset” must be provided. An asset is “anything that has value to the organization and which therefore requires protection” [14]. CSC essentially requires a (business and techni- cal) process of transferring data between ASPSPs and TPPs. Using the ISO 27005 exemplification of assets from the standard’s Annex B.1.1, we can classify this as follows:
• PSU data sharing process (between ASPSPs and PSPs; used for both AISPs and PISPs) - business process/activity (“necessary for the organization to com- ply with contractual, legal or regulatory information”)
• PSU data (customer details and transactions) - information (“vital information for the exercise of the organization’s mission or business”)
The supporting assets that enable the primary assets have been identified using An- nex B.1.2 of [14] for a more granular view. The selection process involved checking if a supporting asset mentioned in the standard supports the CSC primary assets.
An example of inclusion is hardware, which is comprised of devices such as routers that enable connectivity between parties in the PSD2 architecture. An example of exclusion is the organization, as, within the scope of the research, organizational aspects are not analyzed. An outlier is the support asset “Qualified certificates”.
Despite certificates not being mentioned in the ISO 27005 standard, the qualified
certificates are valuable and a strict requirement of the RTS on CSC. The selected
assets are listed in Table 3.3.
Supporting asset Supports PSU data sharing process
Supports PSU data
Hardware (servers, data storage) Yes Yes
Databases Yes Yes
APIs Yes Yes
Communication network Yes No
Qualified certificates Yes No
Personnel Yes Yes
Website (normal interface) Yes Yes
Table 3.3: Selected supporting assets
While all supporting assets contribute to the existence of risks, PSD2 or CSC did not introduce assets such as hardware, databases or personnel to organizations.
These assets were already present and assessed in terms of risk using standards such as [60], or [61]. Furthermore, they were regulated under NIS Directive [62]
or GDPR [63]. Because of these considerations, the current work will not use all the supporting assets for the next steps of the research. Only the specific assets introduced by CSC are taken into consideration. APIs and qualified certificates are novelties mandated by PSD2. Also, all the CSC articles mention conditions and rules for communication, prompting the introduction of “Communication network” as an asset. The assumption here is that the PSD2 communication network is separated from the already existing communication networks present in an organization. In reality, they can also be the same. In summary, the assets to be studied are:
Supporting asset Supports PSU data sharing process Supports PSU data
APIs Yes Yes
Communication network Yes No
Qualified certificates Yes No
Table 3.4: Identified CSC-specific supporting assets
Risk assessment
In this chapter, a cybersecurity risk assessment is performed on the CSC aspects of PSD2. The output is a prioritized list of risk scenarios and their level of risk, representing the answer to the second sub-question. The methodology used is adapted from Clause 7 and 8 of ISO 27005 (“Information security risk assessment”) and Chapter Three of NIST 800-30 (“The process”), which are parts of industry- recognized standards for cybersecurity risk assessment. The two approaches are combined in a similar fashion to [64] and [65] (which exemplified the technique pro- posed by Setiawan et al.). In essence, ISO 27005 is used as the main framework, providing the steps and approach for conducting the assessment. The output of one step serves as an input for the next one. The chapter is structured according to these steps. NIST 800-30 (Revision 1) provides proper concrete directions and tools for performing the assessment, such as assessment scales (for likelihood and im- pact). Throughout the chapter, the origin of concepts or examples is provided. The value in using such a methodology is ensuring that “repeated information security risk assessments produce consistent, valid and comparable results” [60].
For a top-level understanding of the method, together with the corresponding sec- tions, a schema is provided in Figure 4.1.
4.1 Context establishment
The first step in performing cybersecurity risk assessment (the standards use the term “information security” 1 ) is establishing the context. The context establishment is an important step because the decisions taken here influence the final result of
1
While some differences exist, in practice, there is a large overlap between cybersecu- rity and information security ( https://cloudacademy.com/blog/cybersecurity-vs-information- security-is-there-a-difference/ )
23
Figure 4.1: A combined methodology based on ISO 27005 and NIST 800-30. Un- derlined steps have input from NIST 800-30.
the process. At this stage, the purpose, risk evaluation criteria and impact criteria of the assessment are decided.
4.1.1 Risk assessment purpose
[14] gives examples of potential purposes. The applicability of each of them is discussed. “Supporting an ISMS” (information security management system) repre- sents a purpose tied to an organization’s internal strategy. “Preparation of an inci- dent response plan” and “Preparation of a business continuity plan” focus mainly on the processes needed for dealing with a cybersecurity incident and how to maintain the business processes available. “Legal compliance and evidence of due diligence”
makes the assessment more focused on the applicable regulations and how the or- ganization complies with them. For this research, the purpose loosely falls under
“description of the information security requirements for a product, a service or a
mechanism”. The purpose of the risk assessment for this research is to describe
the information security requirements for a generic CSC system where an ASPSP
shares PSU data with a licensed TPP.
4.1.2 Risk evaluation criteria
The risk evaluation criteria must be set at this stage of the context establishment.
This step is valuable as the criteria can be used to “specify priorities for risk treat- ment”. In our case, the criteria are selected from the list provided in [14] Section 7.2.
The selection is based on how applicable are the criteria to the defined purpose.
As an example, “legal and regulatory requirements” are applicable, as the ASPSPs and PSPs have to comply with regulations such as PSD2, NIS Directive [66] and GDPR [63]. Also, they all have reputations to maintain, and the public can have negative attitudes towards the brand following a cybersecurity incident 2 .
As the current research provides a general, top-level view, some criteria have been omitted as an accurate estimation is not viable at this analysis level. While all cri- teria involve some organizational knowledge, the study omitted criteria that involve in-depth knowledge about the organization, such as the stakeholders’ expectations, strategy or structure. The implication can be a loss of precision in performing the assessment (the introduction of “uncertainty”, as expressed by [15]). However, con- sidering the study is exploratory in nature, value is still captured despite the omis- sions. The research can act as a starting point from which organizations can include internal information to refine the criteria and perform a more accurate assessment.
The criteria that have been selected are listed below.
• The criticality of the information assets involved
• Legal and regulatory requirements
• Operational and business importance of confidentiality, availability and integrity (CIA)
• Negative consequences for the reputation
4.1.3 Impact criteria
Another aspect that must be developed is the impact criteria. The impact criteria are essential as they are used to evaluate the damage or costs to an organization for a cybersecurity event. In Chapter 7.2 from [14], a list of considerations is provided.
Like before, some criteria have been discarded based on granularity and insights into specific companies. “Level of classification of the impacted information asset”
cannot be known without having inside knowledge from organizations. The same reasons apply to the discard of “Disruption of plans and deadlines”. “Impaired op- erations” is applicable, as the payment user data cannot be transferred anymore in
2
https://tdwi.org/articles/2018/10/29/biz-all-impact-of-equifax-data-breach.aspx
case of disruptions (for example, availability), and some services might become un- available (e.g. paying a merchant from a TPP’s application). The applicable criteria to the CSC risk assessment are:
• Breaches of information security (e.g. loss of CIA)
• Impaired operations
• Damage of reputation
• Breaches of legal, regulatory or contractual requirements
Despite providing ideas about the crucial factors for considering impact, the ISO 27005 guidelines are not enough in practice. [15] aids at this step by providing an assessment scale for quantifying the impact of threat events. Table A.3 in the Ap- pendix shows the concrete categories of impact.
4.1.4 Risk acceptance criteria
The next part of context establishment is defining the risk acceptance criteria. [14]
stipulates that risk acceptance criteria “depend on the organization’s policies, objec- tives and the interests of stakeholders”. In this study, such information is not avail- able as the research focuses on the generic risks. In contrast, the risk acceptance criteria are determined by each organization individually, considering their internal situation and risk appetite. In conclusion, no criteria can be set for what risk treat- ment action should be undertaken (for example, what constitutes an acceptable risk or what risks require immediate remediation).
4.1.5 Scope and boundaries
Setting the scope and boundaries is crucial to understanding what is and what is not included in the risk assessment. The scope of the present risk assessment is comprised of the information assets specific to CSC: the APIs used for customer data sharing under PSD2; the communication network used for this data sharing;
the qualified digital certificates used for secure communication and identification of licensed parties, together with the process around securing the communication and identifying parties. This risk assessment focuses on particular areas, while a comprehensive risk assessment would incorporate much more assets, processes or functions.
Additionally, situations where multiple parties are involved are outside the scope due
to the added granularity, making the analysis infeasible. Examples here include a
PSP using a gateway provider in charge of the data transfer and the co-existence of APIs and standard interface (website).
Lastly, depending on the internal organizational infrastructure, some inter-dependencies might exist. The PSU data might originate from the same database or data storage used by other business functions. A successful threat event at this level would have increased significance and damage. Due to the increasing complexity in accom- modating edge cases and scenarios, the assumption is that the PSD2 systems are stand-alone.
4.2 Risk identification
After the context has been established, the next stage, according to [14], is risk identification. Per [14], a risk is “a combination of the consequences that would follow from the occurrence of an unwanted event and the likelihood of the occurrence of the event”. More concisely:
Risk = Likelihood ∗ Impact
This section describes the identification of assets, threats, existing controls, vulner- abilities and consequences.
4.2.1 Identification of assets
The assets to be used in the risk assessment have been identified in the previous chapter in Table 3.4. The supporting assets are APIs, Communication network, Qualified certificates. [14] specifies the need to identify, for each asset, an asset owner. This person helps determine the asset’s value and is responsible for its
“production, development, maintenance, use and security as appropriate”. At a high level of analysis, identifying these stakeholders is not possible, as it requires knowing the internal organization of companies.
The final part of asset identification is assigning each asset a value to rank and establish priorities. Considering the small set of assets (3) and the fact that PSD2 regulates their use through the RTS and stipulates fines in case of non-compliance 3 , their value can be judged as equal.
3
