I. Introduction
Both the Payment Services Directive (PSD2) and the Digital Markets Act (DMA) are aimed at fostering competition and innovation in digital markets. The PSD2 creates specific rules for payment service providers, aiming at fostering competition, choice, security and innovation in the retail payment services sector.Footnote 1 The DMA, in turn, aims at increasing contestability and fairness in digital markets and creates across-the-board obligations for gatekeepers.Footnote 2 In both cases, the interventions aim at enabling innovative service providers to plug-in to the value network of incumbent gatekeeping players, largely by facilitating their access to data held by gatekeepers. For example, Articles 66 and 67 PSD2 set conditions for banks to give third-party service providers access to bank customer payment accounts data. In the DMA, Article 6(10) establishes that gatekeepers must give business users access to data deriving from the use of the relevant core platform services.Footnote 3
In both the PSD2 and the DMA the Commission sees competition and innovation as mutually reinforcing. Provisions that are particularly relevant in this regard are the ones concerning interoperability, as these favour a specific type of competition and innovation, i.e., within the existing value network of the dominant players. However, these provisions carry potential costs for competition for innovation and differentiation, as they affect the incentives of market players. Given this trade-off, the way these obligations are implemented will have consequences for the regulations’ impact on competition and innovation in the relevant markets.
In the PSD2, the framework relies on minimum requirements and industry standards to account for rapid technological developments and evolving risks as well as the need for service providers to offer secure and user-friendly payment services. In particular, the PSD2 creates a technical framework for customer data access and sharing by third-party open banking service providers and incumbent banks. The implementation of this approach required the regulator to engage in continuous multi-stakeholder regulatory dialogue, revisions and adaptations, with technical interoperability continuously presenting one of the key obstacles to its successful implementation. The Commission will face similar challenges in applying the DMA to dynamic markets, where the framework aims at facilitating third-party service providers’ access to user data kept by gatekeepers and interoperability between their software and service features.
In this paper we compare the approaches of the PSD2 and the DMA, with a focus on interoperability obligations. We begin by exploring the relevant obligations on banks as “data gatekeepers” towards third-party providers under the PSD2 and discuss the challenges that came with their implementation and how these have been tackled. We then look at comparable obligations vis-à-vis digital gatekeepers under the DMA and options the Commission has to shape their enforcement. Finally, we discuss how the lessons from the PSD2 may contribute to preventing or overcoming difficulties the Commission might run into when enforcing the DMA.
II. The Payment Services Directive (PSD2)
In this part we look at interoperability requirements under the PSD2 framework. The open banking framework in the EU rests on a 3-level structure: the PSD2 Directive,Footnote 4 the regulatory technical standards (RTS) adopted by the Commission as a delegated regulation,Footnote 5 and industry-led standardisation.Footnote 6
1. Interoperability under PSD2
Interoperability is at the core of the open banking framework because it is crucial for the provision of open banking services – payment initiation service (PIS) and account information service (AIS)Footnote 7 – by third parties. The PSD2 highlights the need for “the interoperability of different technological communication solutions.”Footnote 8 Interoperability is therefore a condition indispensable for third-party providers to offer open banking services “without being required by the account servicing payment service provider to use a particular business model, whether based on direct or indirect access, for the provision of those types of services.”
By their nature, PIS and AIS business models require service providers to have access to transaction data of their users irrespective of the bank where the users have their payment accounts.Footnote 9 Such access, known as the access-to-account-rule (XS2A), has been introduced under Articles 66 and 67 PSD2. Lack of interoperability, however, would make third-party services less attractive to users, making PSD2 XS2A provisions obsolete, eventually undermining competition and hampering innovation.
With the PSD2 framework, third-party payment initiation service providers can rely on the XS2A rule to offer banking customers cheaper payment options and more convenient interfaces, thus unbundling online retail payment services. Although the bank (account servicing payment service provider) would remain in charge of users’ deposits and the actual execution of payments (movement of funds), payment initiation service providers would enable additional accessibility of online payments (e.g., on merchants’ webpage) and a cheaper alternative to credit cards. Account information service providers, in turn, offer users an overview of all their bank accounts across multiple banking and financial service providers in one app. The main services offered by account information service providers to individual users are aggregation and categorisation of transactions (from different bank accounts in one place). For business users, services range from credit scoring (based on aggregated customer account data) or personal finance management tools that can be in-built into their apps (e.g., online banking apps).
The PSD2 framework thus aimed at unbundling the previously established status quo with banks effectively acting as “data gatekeepers” with respect to their customers’ payment account data. Despite the framework’s relative success in increasing the number of open banking service providers, the PSD2 has largely failed at facilitating an EU-wide uptake and use of open banking services. Today, third-party service providers largely emerge within national boarders, and compete with banks and bank consortia-led national open banking platforms.Footnote 10 The low adoption and fragmentation of the open banking services is due to the lack of uniform and interoperable standards for communication between third parties and banks, and poor quality of communication interfaces offered by the latter.
2. Interoperability obligations
a. Data access interfaces
The XS2A rule enables third-party payment service provider access to customers’ payment account data on the condition that they a) identify themselves to the bankFootnote 11 and b) communicate securely.Footnote 12 According to Article 98(1)(d), the regulatory technical standards (RTS) on authentication and communication developed by the European Banking Authority (EBA) shall include:
the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, as well as for the implementation of security measures, between account servicing payment service providers, payment initiation service providers, account information service providers, payers, payees and other payment service providers.
To comply with the requirements relative to the communication session for access and transmission (sharing) of data between account servicing payment service providers (banks) and third-party service providers, the PSD2 requires the former to offer interoperable communication interfaces. According to the RTS, banks may choose to either make available a “dedicated” interface, developed for the purposes of providing access to accounts for third-party service providers, or to make available their standard interfaces used for authentication and communication with their users.
A dedicated interface constitutes a secure communication channel between a user’s bank and a third-party service provider offering open banking services. Article 30 RTS requires dedicated interfaces to have a minimal set of functions. These are (i) the authentication of the third-party service provider; (ii) uninterrupted communication between the service providers involved; and (iii) integrity and confidentiality of consumer data transmitted via this channel.Footnote 13 The RTS (Art 31) also allow banks to opt for making available their standard interfaces to third parties, so that the users can engage with third-party open banking services by authenticating and providing consent via the same interface that they use for online banking. However, citing security reasons, most banks to date have opted for a more expensive and complex option of dedicated interfaces based on open application programming interfaces (APIs).Footnote 14
Open APIs allow third-party providers’ software to interoperate with that of the users’ bank for the purposes of channeling users’ transactional data. Such open standard APIs allow third-party service providers to offer their services across the sector (i.e., to the customers of different banks) in the absence of a specific contractual arrangement with banks and at lower costs, thus benefiting from economies of scale.Footnote 15
b. API standards and interoperability
The API technology emerged as a substitute to screen scraping that came effectively under prohibition with the new PSD2 framework.Footnote 16 Although neither the PSD2 nor the RTS explicitly refer to the use of APIs, there is a consensus within the industry and policy makers that APIs are the best available technology for secure communication in open banking.Footnote 17
APIs thus got the leading role as the most appropriate technology capable of enhancing synergies between the service providers within the open banking ecosystem. Moreover, to ensure regulatory intervention does not impede further innovation, the higher levels of EU open banking framework – the Directive and the RTS – have not specified the standard, leaving it to the industry to define.
At this moment there are several standards that have been developed and offered to service providers across the EU. One of the most common standards is NextGenPSD2, developed by a coalition of EU banks called the Berlin Group, comprising around twenty-five institutions. Several national aggregators exist, offering solutions within one jurisdiction, as is the case in Spain, Italy and France.Footnote 18
3. Challenges and shortcomings
a. Lack of interoperability (API fragmentation)
Lack of interoperability has been particularly pronounced in online payments, involving clusters of banks that do not offer interoperable communication interfaces across borders. Lack of standardisation and interoperability between functions and technical standards of banks’ APIs hamper third-party providers’ ability to scale up and offer competitive value proposition to their users. Third-party open banking service providers continuously face the need to establish a separate connection to every bank, which is resource-intensive and significantly limits their reach.Footnote 19
The impact assessment accompanying the proposal for the revised framework – Payment Services Regulation (PSR) – sums up the sources of inefficiencies that undermine innovation and competition in open banking. For one, the inefficiencies stem from the legal issues, including the complexity of the legal framework (different interfaces, including fallback obligations, possible fallback exemptions etc.) and divergent implementation and enforcement of the PSD2 requirements at national level. These legal issues led to technical problems due to insufficient detail and clarity about the expected performance level, and about API functionalities to be provided by banks to third-party providers.Footnote 20
According to the impact assessment, the absence of a single API standard under the PSD2 and the RTS has been justified precisely by the considerations relative to promoting competition and innovation.Footnote 21 However, due to the lack of a clear standardisation mandate and eventually of a single standard,Footnote 22 banks in the EU may adhere to a different API standard that have emerged to date, with different ways of connecting. As mentioned above, this fragmentation impacts the API quality and delivery cycles, and it constrains third-party open banking service providers ability to cater for the needs of their users. According to the study on the application and impact of the PSD2, third-party providers of account information and payment initiation services are of the view that although the PSD2 model of XS2A via an open API model has enabled many new companies to enter the market, the implementation of the XS2A rule by EU banks has mostly been poor (with very few exceptions).Footnote 23 As a result, a significant number of obstacles have now been built into the framework. The stakeholders observe that the APIs vary greatly from bank to bank, despite the fact that the latter claim to use the same standard.
b. Poor quality of API
The quality of APIs is conditioned upon three core characteristics. First, their availability, i.e., accessibility and responsiveness. Second, API performance, characterised by their latency (the time between the initiation of a request and the receipt of the response) and throughput (the number of requests an API can handle at any given moment in time). Finally, API security, i.e., their confidentiality and integrity.Footnote 24
Some third-party providers submitted that they often do not receive the correct status feedback for their scheduled payment initiation service payments. According to these submissions, the availability of APIs remains patchy, the scope of the data being accessed remains unclear and the reliability of eIDAS certifications is inconsistent across the EU.Footnote 25 This has resulted in increased costs and resources, which constitutes a major obstacle for open banking innovation in the EU.
In addition to the enforcement powers granted to national competent authorities under Article 30(6) RTS,Footnote 26 the PSD2 framework introduced an EU-level mechanism for stakeholder dialogue. The efforts aimed at establishing the stakeholder dialogue have been important in addressing the insufficient implementation of interoperability obligations under PSD2. The EBA industry Working Group on API’s under the PSD2 was aimed at addressing the obstacles to open banking services connected to insufficient implementation of interoperability requirements.Footnote 27 Active between 2019 and 2021, the working group held several stakeholder meetings in preparation for the implementation of the RTS (discussing API standardisation and the introduction of dedicated interfaces). In addition, the EBA issued a number of clarifications in response to the stakeholders’ questions and concerns, as well as the EBA Opinion on supervisory actions to call on national competent authorities to ensure the removal of obstacles to account access under the PSD2.Footnote 28 Despite these efforts to bring more clarity into implementation and to enhance supervisory convergence, a number of interoperability-related issues persisted.
4. Revision of the PSD2
a. Lack of interoperability (API fragmentation)
Key changes introduced under the Commission’s proposal for a Payment Services Regulation (PSR)Footnote 29 include the imposition of a dedicated interface for open banking data access and the removal of the requirement on account servicing payment service providers to maintain permanently a “fallback” interface.Footnote 30 The proposal introduces additional requirements on dedicated interfaces concerning their performance and functionalities.Footnote 31
A number of implementation issues resulted from the flexibility given to banks by the “fallback” interface option as alternative to dedicated interfaces for secure communication. First, Article 30 RTS does not detail specific API standards, which has led to the emergence of multiple API standards and differences in application of these standards across the industry (API fragmentation).Footnote 32 As discussed above, this has resulted in increased costs and resources for the industry, with obstacles remaining to the seamless provision of open banking services across the EU.Footnote 33
The fallback option was introduced under Article 31 RTS to accommodate the likely challenges that running uninterrupted API-based dedicated interfaces would cause. Thereby, the banks are required to make their standard online banking interface available for the purposes of providing third-party services, in case the dedicated interface is not available or malfunctioning. In its essence, the requirement aimed at ensuring that no obstacles are created for the provision and use of third-party services. In practice, however, banks’ underperforming APIs, paired with the flexibility in relying on fallback interfaces, led to inconsistent implementation and weak enforcement of the RTS requirements.Footnote 34
Moreover, despite the API fragmentation, there is no unanimity amongst various stakeholders as to the need for a uniform API standard. Stakeholders are citing primarily potential negative effects on innovation and additional (significant) costs for the industry.Footnote 35 The innovation-related argument here is a nuanced one. Many claim that further ‘top-down’ as opposed to industry-led standardisation would slow down or even prevent industry from innovating. Part of the argument concerns banks’ incentives to come up with additional API functionalities and features. That, the opponents of further standardisation suggest, would prevent banks from innovating and improving APIs, even upon third-party providers’ request. This is due to the requirement “that a certain use case must first be included in the API standard in order for it to be implemented in their interface.”Footnote 36 The Commission appears to agree with these views, suggesting that the API standardisation remains industry-led, with the new PSR retaining minimum requirements for open APIs.Footnote 37 Instead of amending the standardisation mandate, the Commission’s proposal focuses on removing currently existing obstacles to interoperability. This is the aim of a number of new explicit prohibitions under the PSR. For instance, under the revised framework it will be prohibited to provide a dedicated interface that does not support all the authentication procedures made available by banks to their users, or to impose a “redirection” or “decoupled” approach that adds additional steps in the user journey.Footnote 38
b. Quality of API
Third-party service providers and a number of national authorities raise concerns about the fact that third-party providers continue facing significant obstacles with accessing accounts via the APIs developed by banks. Different stakeholders have stressed that there are poor quality APIs that have not been reviewed by national authorities in accordance with Articles 30(6) and 32(2) RTS, and that there are large differences in APIs across Member States. This resulted in limited cross-border activity and less choice for payment service users. Many stakeholders have been advocating for more API standardisation and better supervision and enforcement of banks providing the necessary conditions to ensure third-party access to user accounts.Footnote 39
The proposed revised framework (under the PSR) aims at reducing regulatory complexity by constraining the flexibility given to banks in relying on their standard customer interfaces as a fallback option. This, however, only addresses part of the issue, as banks would remain in charge of further API standardisation and ensuring that these offer sufficient quality. With respect to the latter, the current proposal does not seem to add more detail to the minimum requirements to the open API performance that existed previously.
The above viewpoint is in line with the views shared by many in the industry that the reason for poor APIs lies in the lack of incentive for banks to invest in well-performing APIs, and not because of the lack of standardisation. In other words, not the absence of a single standard (as initially mandated under the PSD2) but the poor implementation of existing API standards poses the main problem. Hence the shift of the focus should be not on facilitating the emergence of a single standard (as was upon the launch of open banking), but on enhancing the quality of APIs based on several existing standards.
c. Lessons from PSD2
The API-related interoperability issues under the PSD2 can be attributed to three main shortcomings of the legal framework: insufficient incentives for payment “data gatekeepers” (i.e., banks), weak enforcement, and ambiguity with regard to regulatory requirements.Footnote 40
The Commission’s response to these shortcomings focuses on better implementation through stricter enforcement, instead of a (renewed) standardisation mandate. The reason is that it appears to be “too late” to steer industry towards a single standard.Footnote 41 For one, mandating a single interoperability (API) standard at this stage would be too costly – the Commission concluded in its impact assessment that the development and transition to a new single standard would require an “excessively high implementation cost for banks (ASPSPs).”Footnote 42 Additionally, emerged standards are competing, and although the lack of a single standard has slowed the development of open banking, it did not halt it.Footnote 43
One lesson from the PSD2 implementation of interoperability, therefore, is the importance of timing in regulating fast-evolving markets. Now, confronted with a new market reality, the efforts aimed at removing obstacles to interoperability in open banking are primarily aimed at improving the quality of APIs. The revision of the PSD2 offers another lesson on the available regulatory options to tackle the obstacles to interoperability. From the legal perspective, these options amount to clarifying minimum requirements to the functioning of dedicated interfaces, adding more detail to the required performance of APIs and narrowing down exemptions.
III. The Digital Markets Act (DMA)
The objective of the DMA is to improve market contestability and fairness of digital markets “with a view to promoting innovation… .”Footnote 44 While the emphasis of the DMA is clearly on contestability and fairness,Footnote 45 the link between contestability and innovation is emphasised repeatedly, as in the following recital: “weak contestability reduces the incentives to innovate and improve products and services for the gatekeeper, its business users, its challengers and customers and thus negatively affects the innovation potential of the wider online platform economy.”Footnote 46
In order to achieve its goals, the DMA imposes a number of obligations on designated digital gatekeepers. While some obligations are designed to be self-executing (Article 5), others are subject to further specification (Articles 6 and 7). In this paper we focus on interoperability obligations, which belong to the latter category. While the addressees of these obligations are gatekeepers, the intended beneficiaries include a number of third-party service providers, such as software and app developers including messaging, payment wallets, web browsers and search providers and other business users. For these obligations both competition and innovation consideration are highly relevant and for their implementation we can rely on lessons learned from the experience with the PSD2 in terms of achieving more competition while safeguarding and fostering innovation.
1. Interoperability obligations
a. Data-related interoperability obligations
There are two complementary obligations that regulate the way gatekeepers may use data vis-à-vis third-party business users, and which are designed to create a level playing field.
One particular problem emerges when gatekeepers have a dual function in providing a core platform service and operating themselves on that service, in competition with business users. In that situation, they might take advantage of that dual role, to use data generated by their business users while exercising their activities on the core platform service (recital 46). To tackle this problem, Article 6(2) prevents gatekeepers from using, in competition with business users, data generated or provided by those business users while using the gatekeepers’ service that is not publicly available. This includes data deriving from customers of those business users.
Besides making sure that gatekeepers do not obtain an unfair advantage by using data generated by business users that is not publicly available, the DMA goes a step further and demands that gatekeepers share data, when requested by business users. This includes data provided or generated by the business user and their end users. In this regard, Article 6(10) establishes that:
The gatekeeper shall provide business users…, at their request, free of charge, with effective, high-quality, continuous and real-time access to, and use of, aggregated and non-aggregated data, including personal data, that is provided for or generated in the context of the use of the relevant core platform services…
When personal data is involved, according to recital 60 of the DMA, users must have given consent, where consent to such sharing is required under the General Data Protection Regulation.Footnote 47 In order to implement this obligation, recital 60 also states that gatekeepers should put in place appropriate technical measures, for example high quality APIs or integrated tools for small volume business. Hence, this obligation entails some interoperability elements, which are further discussed in the section below.
b. Interoperability with third-party software applications and hardware and software features
Interoperability is a key component of contestability in the digital market. Gatekeepers may have an incentive to restrict the ability of end users to utilise third-party software on their hardware or operating systems. To ensure market contestability in this respect, Article 6(4) targets operating systems and sets outs that “the gatekeeper shall allow and technically enable the installation and effective use of third-party software applications or software application stores using, or interoperating with, its operating system.” Furthermore, it must be possible for users to access them through means other than the gatekeeper’s core platform services. Besides being able to run third-party software, users must be allowed to set them as their default. This must be technically enabled and facilitated by the gatekeeper. Gatekeepers do keep the right to implement technical and contractual measures necessary and proportionate to protect the integrity of their hardware or operating system. This includes design options needed to prevent unauthorised access and end users’ security.Footnote 48
Article 6(7), applies to both operating system and virtual assistant gatekeepers and stipulates that they must ensure effective interoperability for service and hardware providers. In September 2024, the Commission opened proceedings under Article 20(1) of the DMA in view of specifying the measures Apple must put in place to effectively comply with its interoperability obligations under Article 6(7), concerning interoperability between iOS and connected devices, such as smartwatches, headphones, and virtual reality headsets.Footnote 49 In December 2024, the Commission published its preliminary findings setting out the proposed measures that Apple should implement to ensure effective interoperability with iOS for connected devices and opened a public consultation on the proposed measures. The measures proposed are designed to ensure that “the interoperability solutions for third parties will have to be equally effective to those available to Apple and must not require more cumbersome system settings or additional user friction.”Footnote 50
c. Number-independent interpersonal communications services
A further problem that the DMA tackles through interoperability obligations is the weak contestability of number-independent interpersonal communications services (NI-ICS). Article 7 of the DMA imposes on gatekeepers the obligation to ensure interoperabilityFootnote 51 of their NI-ICS with other providers. To achieve interoperability, gatekeepers need to provide “the necessary technical interfaces or similar solutions that facilitate interoperability, upon request, and free of charge.”Footnote 52
The “basic functionalities” that need to be made interoperable, provided that the gatekeeper itself offers those functionalities to its own end users, are specified in Article 7(2). Following designation of gatekeeping status, interoperability must be provided for end-to-end text messaging between two individual end users, including the sharing of images, voice messages, videos and other attached files. In a second step, within two years from designation, this interoperability must be extended to groups of individual end users. In a last step, within four years, also end-to-end voice and video calls between two individual end users and between a group chat and an individual end user must be made interoperable.
The way the interoperability obligation in Article 7 is put into practice is the following: the gatekeeper publishes a letter of reference, in which it lays down the technical details and general terms and conditions of interoperability (including the level of security).Footnote 53 The Commission may consult the Body of European Regulators for Electronic Communications to determine the compliance of the technical details and the general terms and conditions published in the reference offer.Footnote 54 Other providers may then make a request for interoperability of some or all the functionalities, which the gatekeeper needs to comply with within 3 months, by making the requested functionalities operational.Footnote 55 The gatekeeper may receive an extension from the Commission for the deadlines under Articles 7(2) and (5), if justified for effectiveness or security reasons.Footnote 56
Now that we have looked at relevant obligations under the DMA, we will explore the tools the Commission has to shape their implementation.
2. Specifying and updating obligations under the DMA
a. Entering into dialogues
Under Article 8(3) DMA, at a gatekeeper’s request, the Commission may engage in a dialogue with a gatekeeper. The dialogue’s objective is to determine the adequacy of the measures that the gatekeeper intends to implement or has implemented to ensure compliance with relevant obligations. The dialogue allows the Commission to take into account the specific circumstances of the gatekeeper and to specify some of the measures that the gatekeeper concerned should adopt in order to effectively comply with obligations.Footnote 57
Crucially, a dialogue can only be requested for implementation concerning obligations under Articles 6 and 7, and not Article 5. The reason for this is that the obligations under Article 5 are designed to be self-executing, leaving less discretion as to their implementation.
Whether or not the Commission decides to engage in such a process is at its discretion and is decided in line with the principles of equal treatment, proportionality and good administration. Furthermore, the Commission retains the ability to adopt a non-compliance decision and to reopen proceedings, including where the specified measures turn out not to be effective.Footnote 58
b. Specifying through implementing acts
The Commission may adopt an implementing act, specifying the measures that the gatekeeper concerned is to implement in order to effectively comply with the obligations laid down in Articles 6 and 7.Footnote 59 Implementing acts can be adopted for specifying the “form, content and other details of the technical measures that gatekeepers shall implement in order to ensure compliance with Article 5, 6 or 7” and the “operational and technical arrangements in view of implementing interoperability of number-independent interpersonal communications services pursuant to Article 7.”Footnote 60
Furthermore, an implementing act can be adopted in order to exceptionally suspend, entirely or partially, an obligations under Articles 5, 6 or 7, if compliance with the obligation would endanger the economic viability of a gatekeeper’s operation in the EU.Footnote 61 Exemptions from specific obligations can also be granted via implementing act, if they are justified on public health or public security grounds.Footnote 62
Finally, the Commission may use implementing acts to make commitments that have been offered by gatekeepers, in the context of a market investigation into systematic non-compliance, binding.Footnote 63
c. Updating through delegated acts
The Commission may adopt delegated acts to supplement the obligations contained in Articles 5 and 6. The scope of a delegated act is limited to extending or specifying existing obligations.Footnote 64 Delegated Acts should follow a market investigation into new services and new practices under Article 19.Footnote 65 This can be used to determine whether new services should be classified as core platform services or to detect new practices that limit the contestability of core platform services or that are unfair. In order to add new services to the list or include new obligations, the Commission can submit to the European Parliament and to the Council a draft delegated act supplementing the DMA, or a legislative proposal to amend the DMA. For example, while Article 7 is currently limited to NI-ICS, the DMA creates the opportunity for the Commission to “evaluate if the scope of Article 7 may be extended to online social networking services.”Footnote 66 Furthermore, it may propose to remove existing services from the list of core platform services or remove current obligations.Footnote 67
IV. Applying the lessons from the PSD2 to the DMA
The PSD2 and DMA frameworks contain comparable obligations relating to interoperability. They also rely on comparable instruments and regulatory design aimed at implementing interoperability requirements.
The experience from the PSD2 shows that two main technical issues may arise in connection with their implementation under the DMA: the fragmentation of API standards and interfaces (IV.1) and the poor quality of APIs (IV.2), posing obstacles to the effective implementation of interoperability.
In this part of the paper we will look at the options the Commission has in relation to their implementation under the DMA and how the lessons from the PSD2 may help in preventing and overcoming challenges to interoperability.
1. API fragmentation
The DMA is open-ended as to the way interoperability between NI-ICS shall be ensured. All it says is that gatekeepers must provide the necessary technical interfaces or similar solutions that facilitate interoperability.Footnote 68 The most straightforward way to achieve interoperability between NI-ICS is through the provision and use of APIs.Footnote 69 APIs specify the availability of functions, the format data is transmitted in, and who can communicate through it. Through the access to proprietary APIs, providers can exchange data and communicate with each other.Footnote 70 When it comes to an API approach, this can either mean that gatekeepers implement the APIs of competitors requesting interoperability, or competitors implement the gatekeepers’ APIs.Footnote 71 Since the gatekeepers are the ones applying the DMA, it would seem more likely that they would opt for the latter approach. The downside of this is that, since gatekeepers are likely to have different APIs, competitors would have to support potentially different technical requirements for each gatekeeper they want to interoperate with.
While the gatekeepers will decide how to comply with the DMA, the Commission may decide to specify the application of this obligation by means of an implementing act. In particular, it may lay down “operational and technical arrangements in view of implementing interoperability of [NI-ICS] pursuant to Article 7.”Footnote 72
An alternative to proprietary APIs is full standardisation, meaning that all NI-ICS would implement the same standardised API for interoperability. This type of approach is, for instance, what allows users to communicate via email regardless of their provider. Standardisation is not currently prescribed by the DMA, but may play a greater role in the future. Article 48 establishes that “where appropriate and necessary, the Commission may mandate European standardisation bodies to facilitate the implementation of the obligations set out in this Regulation by developing appropriate standards.” Recital 96 indicates that the implementation of the obligation related to interoperability is among the ones that could be facilitated by the use of technical standards.
Whether the Commission should limit itself to specifying the application of interoperability obligations or pursue the full standardisation path is early to say. In light of the experience under of the PSD2 framework, a decision in favour of full standardisation should be considered in a timely manner.
For one, such solution in the context of NI-ICS would have significant impact on innovation by third-party providers that seek to enhance their value proposition to users by means of interoperability with gatekeeper services. Timing is important here, if we look at the status quo and the ongoing discussion in the context of open banking. The two arguments against a single standard (as potentially undermining innovation) are based on the costs already incurred by the industry in developing the existing competing standards,Footnote 73 and the potential detrimental effect of a single standard on data access enabling providers’ (banks under PSD2/PSR and gatekeepers in case of DMA) incentives to offer additional, “premium,” functions. In other words, innovating beyond the minimum requirements laid down by the regulatory frameworks. In regard to the former, the cost-related consideration can be avoided under the DMA by pro-active engagement of the Commission in the standardisation efforts. In relation to the latter, innovation-related considerations require further analysis of the NI-ICS market.
In any event, achieving interoperability under DMA by means of APIs will require some level of harmonisation, to ensure an efficient and effective implementation of the obligation. In line with the PSD2 experience, the Commission should engage in stakeholder collaboration while exploring options for harmonisation. Similarly to the PSD2 framework, the DMA introduces broad and largely technology agnostic minimum requirements for interoperability. As illustrated by the example of open banking, in the absence of additional guidance and enforcement, an interoperability framework based on minimum requirements may lead to ambiguity with regard to the scope of the regulatory mandate, and inconsistent implementation. Under the DMA, such guidance can be provided as part of a dialogue with gatekeepers under Article 8(3) DMA or, for instance, by organising roundtables or inviting interested parties to comment on proposals.
Interoperability also requires a new interface design for gatekeepers and services interoperating with them. For example, a data portability interface will be required, that will allow users to download and integrate data with other providers. The type of interface design is significant for the success of interoperability and, thus, gatekeepers may be tempted to choose a suboptimal design to undermine interoperability’s effectiveness. As consent management will become more complex with the increase of interoperable providers and in particular in the context of group chats, gatekeepers might make use of dark patterns to discourage interoperability.Footnote 74 From the PSD2 experience we can derive that it would be indeed beneficial for the Commission to prescribe the interface that gatekeepers need to use, instead of leaving gatekeepers with flexibility to implement interoperability under the DMA. This will reduce regulatory complexity and contribute to uniformity, increasing user transparency and trust and preventing attempts to undermine the obligations’ effectiveness. The Commission can again rely on its power to adopt implementing acts under Article 8 DMA.
2. Poor API quality
Besides the issue of fragmentation, another concern arising from the implementation of interoperability by means of standardised APIs is ensuring sufficient and consistent quality of the open APIs offered by gatekeepers. The quality of APIs is key, for instance, with respect to the APIs offered to third-party NI-ICS interoperating with gatekeeper services, crucial for innovation and competition in messaging. As discussed in the context of the revisions of the PSD2, obstacles to innovation and competition would arise even in the case a single API standard was adopted, if the open API made available was of poor quality in terms of its availability, performance and security.Footnote 75
Based on the lessons from open banking, the Commission should engage with the implementation of the DMA interoperability requirements by ensuring the APIs offered for data access and exchange are of high quality. It should also ensure that these APIs correspond to the needs of innovative service providers and newcomers.
The experience from the implementation of the PSD2 suggests that the Commission should explore the possibilities to provide as much detail as possible about the required quality of APIs and additional technical interfaces necessary to ensure interoperability. This is crucial to avoid the problems prevailing in open banking, where the lack of detail as to the implementation of minimum interoperability requirements led to obstacles to competition and innovation by third-party providers.
The text of the DMA supports such proactive approach, exemplified by recital 60, which refers to the obligation of gatekeepers to provide high-quality interoperability tools, such as APIs. The recital moreover emphasises that gatekeepers should not use any restrictions to prevent business users from accessing relevant data and that the access should be continuous and in real-time.Footnote 76 This would be the case, for instance, if a marketplace only updated sales or ad performance data once per day/week, denying business users from seeing real-time click-throughs and adjusting prices or ads accordingly. Another example can be found in Article 7(1), which imposes requirements on gatekeepers to provide “the necessary technical interfaces or similar solutions that facilitate interoperability.”Footnote 77
The Commission appears to be well-equipped to ensure due implementation of interoperability under the DMA. As discussed above, interoperability requirements (those in the context of Article 7(1) in particular) may be further clarified by means of a dialogue (Article 8(3)) or by adopting implementing acts to specify operational and technical arrangements (Article 46(1)(b) and (c)).
V. Conclusion
Both the PSD2 and the DMA represent regulatory efforts aimed at fostering competition and innovation in their respective domains. In this paper we have shown how the PSD2’s experience relating to interoperability obligations could provide valuable lessons for the effective implementation of comparable obligations in the DMA. While the two frameworks operate in different contexts, they exhibit parallels and have shared goals.
The PSD2 has experience with implementing interoperability obligations imposed on banks and provides examples of the challenges that come with them, and how to tackle these. Three main reasons for the inability of the PSD2 framework to adequately address these challenges have been identified: 1) broadly defined, often ambiguous requirements; 2) lack of a clear standardisation mandate; and 3) weak enforcement of the interoperability requirements despite the evidence of obstacles to the effective implementation of interoperability by banks as “data gatekeepers” of open banking.
The discussion of the interoperability requirements under the DMA suggests that the Commission might face similar challenges in implementing the new framework. Similarly to the PSD2, interoperability obligations under the DMA, such as the introduction of APIs for the interoperability between NI-ICS, rest on minimum requirements (Article 7). Under the PSD2, offering service providers additional guidance has been crucial. As experience showed, these efforts have not been sufficient without stricter enforcement and supervisory convergence between national competent authorities that would ensure that technical obstacles do not undermine interoperability. In the revision of the PSD2 (the PSR proposal), the emphasis is on introducing rules akin to ex ante prohibitions of certain conduct (“prohibited obstacles”) and on narrowing exemptions from fulfilling the interoperability mandate, thus reducing banks’ flexibility in complying with the PSD2 requirements. Under the DMA, the Commission – as a single enforcement authority – seems to be better positioned to enforce the requirements should its guidance to the gatekeepers not prove sufficient for its contestability and fairness objectives.
Another important lesson, but also an inevitable challenge, is the timeliness of the interoperability implementation measures in the context of competition and, in particular, innovation. The experience from the PSD2 showed that implementing interoperability is time consuming and may lead to unintended and irreversible impact on the competition and innovation landscape. Under the PSD2 framework, the lack of a clear standardisation mandate led to the emergence of numerous (API) standards. As a result, the high costs and potential impact on competition and innovation of reversing the status quo led the Commission to agree on pursuing interoperability based on harmonisation of the competing standards. Whether a single API standard would be a preferred option for interoperability under the DMA, such as in the case of NI-ICS, is an open question that would require an investigation into the NI-ICS market. The lessons from the PSD2 emphasise the need for a pro-active approach and offer insights into the aspects of the market development (e.g., persistent obstacles to competition and innovation), underscoring the importance of a continuous dialogue with regulatees and relevant stakeholders.
Competing interests
The author(s) have no conflicts of interest to declare.
Open access
