European Commission Also Fires Up The Digital Markets Act

Having just opened multiple investigations under the new Digital Services Act, the European Commission has also announced investigations under its new Digital Markets Act (DMA). These investigations would also benefit UK businesses providing services to EU/EEA residents. This post is for information purposes. If you need advice, please let me know.

As previously explained in more detail, the DMA aims to control unfair practices of very large digital platform operators (“gatekeepers”) when providing services that other businesses use to reach their customers online. These gatekeepers effectively act as private rule-makers, and are able to create ‘bottlenecks’ and ‘choke points’ that limit access, unfairly exploit data for their own purposes and/or impose unfair conditions on participants. The DMA operates outside the scope of existing EU competition controls. Member state’s regulators cannot go further than the DMA restrictions, which must be applied consistently throughout the EU. Gatekeepers can be fined up to 20% of worldwide revenue for breaches. The DMA applied from May 2023 and any firm designated as a gatekeeper then has six months to comply with the various requirements. 

Alphabet, Amazon, Apple, ByteDance, Meta and Microsoft were designated as gatekeepers in September 2023, giving them until 7 March 2024 to comply. The European Commission believes they do not. Specifically, the Commission alleges that: 

• the 'steering rules' in Google Play violate Article 5(4) (gatekeepers must allow business users, free of charge, to make offers to and contract with end users acquired either via its core platform service or through other channels, regardless of whether they use the core platform services of the gatekeeper for either purpose);

• the self-preferencing on Google Search violates Article 6(5) (gatekeepers must not treat more favourably (in ranking and related indexing and crawling), services and products offered by the gatekeeper itself in preference to similar services or products of a third party, and must apply transparent, fair and non-discriminatory conditions to such rankings);

• the steering rules in the Apple App Store violate Article 5(4);

• the choice screen for Safari violates Article 6(3) (gatekeepers must allow and technically enable end users to easily un-install any apps on the gatekeeper's operating system (except apps essential for the functioning of that operating system or the device which cannot technically be offered on a standalone basis by third parties). Gatekeepers must also allow and technically enable end users to easily change default settings on the operating system, virtual assistant and web browser of the gatekeeper that direct or steer end users to products or services provided by the gatekeeper); and

• Meta's "pay or consent model" violates Article 5(2) (using personal data gathered by third party businesses from their customer's using the browser, without valid consent under GDPR, in addition to other direct GDPR complaints about that type of model). 

Within the next 12 months, the Commission will inform these gatekeepers of its preliminary findings and proposed orders to fix any issues.

In addition, the Commission:

• is seeking information on Apple's fees for alternative app stores and Amazon's marketplace ranking practices;
• issued document retention orders to Alphabet, Amazon, Apple, Microsoft and Meta to help it monitor their compliance with the DMA; and 
• granted Meta an extension of six months to ensure Facebook Messenger complies with the interoperability requirement in Article 7 (there's a long list of those!).

These investigations would also benefit UK businesses providing services to EU/EEA residents. 

This post is for information purposes. If you need advice, please let me know.

Legal Adventures in the Fediverse

Joining the fediverse has jolted my legal brain into gear over some esoteric questions (listed below). These largely turn on the fact that, unlike in Web 2.0 offerings, such as Blogger or Twitter, there is no central service provider hosting/operating the service on its own servers. In the fediverse, separate sites (or 'instances') can interoperate because they are running the same standardised, open software (e.g. Mastodon) which itself relies on the same standardised, open protocol (Activity Pub, in the case of Mastodon):

Mastodon websites are operated by different people or organizations completely independently. Mastodon does not implement any monetization strategies in the software. 

Some server operators choose to offer paid accounts, some server operators are companies who can utilize their existing infrastructure, some server operators rely on crowdfunding from their users via Patreon and similar services, and some server operators are just paying out-of-pocket for a personal server for themselves and maybe some friends. So if you want to support the server hosting your account, check if it offers a way to donate. 

Mastodon development is likewise crowdfunded via Patreon and via OpenCollective. No venture capital is involved.

Perhaps this is no different to independent website owners building their own websites using a standardised website template provider (e.g. Wix), but the interoperability does seem a significant additional factor to consider. That's like email, which again could be provided by a centralised email service provider (e.g. Microsoft's hotmail) or your employer. Equally, the fact that each site or 'instance' could be self-hosted is similar to websites and email, yet most users choose their site to be hosted with the operator of a server or instance that hosts many sites (e.g. mastodon.world or mastodon.social). Some instances are open to anyone, while others are targeted at, say, residents of Glasgow. 

I think this just involves a sense-check against the regulatory regime of where the relevant fediverse instance and any users that it actively solicits are based. Here's a flavour of some of the issues:

• How does a user proceed if the developer of the relevant communication software somehow fails to ensure the software runs as promised in the documentation?

• Who is responsible for the integrity of the protocol on which the software is based?

• Do fediverse instances based in the EU with UK resident users but no offices, branches or other establishments in the UK need to appoint a UK representative under UK GDPR (and vice versa!)?

• Is each 'instance' in the fediverse ready for the EU's Digital Services Act (exemptions for micro/small enterprises will help)?

• If each 'instance' in the fediverse can be an Intermediary service, online platform or e-commerce platform under the Digital Services Act (see prior post), then they could grow to be 'gatekeepers' under the EU Digital Markets Act.

• How are fediverse instances treated for the purposes of  'reverse solicitation' analysis - i.e. whether you are treated as doing business in another jurisdiction where users are based, as opposed to where the instance is based?

If you need assistance with any of these issues, please let me know.

Will It Be Practicable To Transfer Personal Data From the EEA to the UK After 2020?

From 1 January 2021, any EEA-based organisation wishing to transfer personal data from the EEA to the UK (or any other non-EEA country) will need to be able to show that the processing will have the same protection as under EU data protection law (GDPR). Many firms might consider that exercise impracticable from a cost and administration standpoint, particularly in light of certain new recommendations on which the EU authorities are now consulting. These are briefly explained below. The UK's Information Commissioner is "reviewing" the proposals, but of course has no influence. This will affect "thousands" of firms and could prove severely disruptive for cross-border services ranging from payroll and benefits, to e-commerce marketplaces to social media services. If you need assistance, either in the UK or in Ireland/EEA please let me know.

Options for transferring personal data from the EEA to the UK

An EEA-based business can only transfer personal data to a non-EEA country, if one of three situations apply: 

1. the European Commission has ruled that country's personal data protection laws to be ‘adequate’;
2. there are appropriate safeguards or 'transfer tools' in place to protect the rights of data subjects (including 'Standard Contractual Clauses'); or
3. certain 'derogations' or exemptions apply to allow the processing as of right.  

For many reasons it is best to assume there will not be an EU adequacy decision relating to the UK’s data protection regime by 1 January 2021, as that process is long and complex, and there are some features of the UK regime which do present problems, including: 

• the UK’s use of mass surveillance techniques;
  
• intelligence sharing with other countries such as the US;
  
• the questionable validity of the UK immigration control exemption;
  
• the lack of a ‘fundamental right’ to data protection under UK law; 
• UK adequacy findings for other countries’ personal data regimes that the EU does not deem adequate; and 
• the potential for future divergence from EU data protection standards if the UK GDPR is further modified post Brexit. 

As a result of the decision of the European Court of Justice in a case against Facebook (‘Schrems II’), a data exporter relying on Standard Contractual Clauses (or other contractual 'transfer tools') must first verify that the law of the third country ensures a level of protection for personal data that is equivalent to the EU's General Data Protection Regulation. If that level is considered sub-standard, the data exporter may be able to use certain measures to plug the gaps, but this process would need to be carefully documented and is the subject of the main recommendations from the EDPB. 

The extent to which you can usefully rely on the derogations, either before considering the other appropriate safeguards or 'transfer tools', or if those other options are not available is also somewhat doubtful, as I will explain.

Assessing whether personal data transfers outside the EEA are appropriate

To help data exporters evaluate whether the use of transfer tools will be appropriate, the forum of all the EEA data protection authorities (the European Data Protection Board or EDPB), is now consulting on recommendations for: 

• measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data; and
  
• certain European Essential Guarantees for evaluating surveillance measures. 

The EDPB's first set of recommendations contain steps outlined below. The European Essential Guarantees enable data exporters to determine if the rights for public authorities to access personal data for surveillance purposes can be regarded as a justifiable interference with the rights to privacy and the protection of personal data. Basically:

A. Processing should be based on clear, precise and accessible rules;

B. Necessity and proportionality with regard to the legitimate objectives pursued need to  be demonstrated;

C. An independent oversight mechanism should exist;

D. Effective remedies need to be available to the individual.

The steps involved in assessing the appropriateness of transfer tools must be documented. These involve:

• mapping the proposed transfers;
• choosing the basis for transfer (adequacy decision, 'transfer tool' or derogation);
• unless an adequacy decision has been made by the EU, working with the data importer to assess whether the law or practice of the third country may impinge on the effectiveness of the appropriate safeguards of the transfer tools you are relying on, in the context of your specific transfer (legislation, especially where ambiguous or not publicly available; and/or certain reputable third party findings such as those in Annex 3), and not rely on subjective factors such as the perceived likelihood of public authorities’ access to your data in a manner not in line with EU standards;
• considering whether any supplementary tools might avoid any problems with the third country's laws (various use-cases and suggested tools are explained in the Annex 2 to the recommendations);
• taking any formal steps to implement the relevant tool;
• re-evaluate the assessment periodically or on certain triggers, such as changes in the law (which you should also oblige the data importer to keep you informed about).
  

Data exporters must thoroughly record their assessment process in the context of the transfer, the third country law and the transfer tool on which they propose to rely. But it may not be possible to implement sufficient supplementary measures in every case, meaning the transfer must not proceed. As the Commission points out, there are "no quick fixes, nor a one-size-fits-all solution for all transfers."

The problem with relying on 'derogations'

The EDPB's first set of recommendations state (at para 27) that "If your transfer can neither be legally based on an adequacy decision, nor on an Article 49 derogation, you need to continue with... ” assessing whether the proposed transfer tool is effective. However, that order of approach is not consistent with Article 49, which provides that:

1. In the absence of an adequacy decision pursuant to Article 45(3), or of appropriate safeguards pursuant to Article 46, including binding corporate rules, a transfer or a set of transfers of personal data to a third country or an international organisation shall take place only on one of the following conditions:

(a) the data subject has explicitly consented to the proposed transfer, after having been informed of the possible risks of such transfers for the data subject due to the absence of an adequacy decision and appropriate safeguards;

(b) the transfer is necessary for the performance of a contract between the data subject and the controller or the implementation of pre-contractual measures taken at the data subject's request; 

(c) the transfer is necessary for the conclusion or performance of a contract concluded in the interest of the data subject between the controller and another natural or legal person;

...

Where a transfer could not be based on a provision in Article 45 or 46, including the provisions on binding corporate rules, and none of the derogations for a specific situation referred to in the first subparagraph of this paragraph is applicable, a transfer to a third country or an international organisation may take place only if the transfer is not repetitive, concerns only a limited number of data subjects, is necessary for the purposes of compelling legitimate interests pursued by the controller which are not overridden by the interests or rights and freedoms of the data subject, and the controller has assessed all the circumstances surrounding the data transfer and has on the basis of that assessment provided suitable safeguards with regard to the protection of personal data. The controller shall inform the supervisory authority of the transfer. The controller shall, in addition to providing the information referred to in Articles 13 and 14, inform the data subject of the transfer and on the compelling legitimate interests pursued.

In addition, the EDPB's own guidance on article 49 itself points out (on pages 3-4) that: 

“Article 44 requires all provisions in Chapter V to be applied in such a way as to ensure that the level of protection of natural persons guaranteed by the GDPR is not undermined. This also implies that recourse to the derogations of Article 49 should never lead to a situation where fundamental rights might be breached…Hence, data exporters should first endeavor [explore?] possibilities to frame the transfer with one of the mechanisms included in Articles 45 [adequacy] and 46 [transfer tools] GDPR, and only in their absence use the derogations provided in Article 49 (1)” [but even then the use of the derogations would imply the need for an assessment of the third country’s personal data protection regime by virtue of article 44].

Accordingly, there seems to be no alternative to running through the steps to assess whether the relevant 'transfer tools' will work (with or without supplementary measures) in the context of the transfer and the third country's law. Yet many firms will likely find that process impracticable from a cost and administration standpoint.

Transferring Prepaid Card Programmes Is Non-Trivial

Ominous news that the UK e-money subsidiary of scandal-ridden Wirecard AG is "intending to wind-down its FCA-regulated business" and that "the business will continue to trade while alternative arrangements are being made with its card providers." 

Having advised on the creation and transition of various prepaid card programmes and customers, I'm aware this is highly technical from an e-money and payments regulation standpoint, and will involve intensive 'customer due diligence' under the anti-money laundering regime, as well as a careful approach to the processing of personal data. 

The FCA claims to be "working closely with Wirecard throughout this process to ensure that its customers are treated fairly," so programme managers any e-money issuer(s) taking them and their programmes on will need to tread carefully.

Needless to say, I'm here to help the transferring programme managers or their new e-money service providers either in the UK or in relation to any EEA programmes via Ireland.

 

#PSD2: An Account Information Service Is Not Really A Payment Service

There are good reasons why an "account information service" (AIS) became a regulated "payment service" under the not-so-new Payment Services Directive (PSD2). Chief among them was retail banks' decades-long refusal to allow retailers and other unregulated service providers access to the data in their antiquated systems at all, let alone seamlessly via 21st century "application programming interfaces" (APIs) that are now commonplace. Resolving those concerns sparked formal registration and other complex regulatory and technical requirements on service providers wishing to enable the sharing of payment data (AISPs), including a lot of unfortunately necessary detail in the Directive about customer authentication and information security. Yet years after PSD2 was set in stone confusion still reigns over exactly what an AIS actually is or is not, both as defined in local payments regulation implementing PSD2 and how such services work commercially - especially because an AIS rarely stands alone...

The FCA is doing its best to clarify the regulatory scope of an AIS, including confusion about who might be the AISP, when a firm would require formal registration as an agent and how to benefit from the exclusion for 'technical service providers' (see Q25A of its Perimeter Guidance on payment services). But those issues are merely the tip of the iceberg.

The major problem is that an AIS is primarily a data service (and one which involves personal data at that). This means an AIS attracts the need for several sets of regulatory consents and specific information to be included in customer contracts, as well as the typical series of contractual licences to receive and use the data itself. 

The challenge to getting all this right is that it's rare for payments regulatory specialists to know very much about data licences, or for lawyers who specialise in data licensing to know anything about PSD2. It still feels strange to me to have spent a career on both sides of that divide - veering from financial information service licensing at Reuters, to e-commerce specialist at DLA, to payments specialist at Earthport, to P2P lending at Zopa (which involved licensing of user-generated content and market data) and back to payments at Amazon and WorldPay. And even though I've also continued to advise private clients on all types of services since 2005, there's still very much a sense of 'switching hats' when working through the various issues. 

So what are they?

Regulatory requirements for an AIS

From a regulatory standpoint the multiple sets of rights needed to supply an AIS include:  

• explicit consent from the customer for the supply of the AIS itself (under payments regulation) - note that that 'customer' does not include a third party with whom the customer wants to share the data; and
• under data protection regulation, explicit consent (or some other legitimate basis) for the collection, processing, sharing etc of the data itself, to the extent required to deliver it to a third party - as well as for the processing etc of that data by the third party (which may be tackled via the third party's own privacy policy and data consents).

In addition, payment services regulation specifies certain information that must be included in either an ongoing or single use service contract with the customer.

Meeting these requirements is complicated by the fact that the customer is also likely to be using the AISP's platform to be receiving and sharing data from other types of personal account that are not regulated. So the payment-specific regulatory requirements have to be met within a context where unregulated data services are also being provided.

Commercial requirements

From a commercial standpoint, there are numerous copyright licensing issues to consider regardless of whether the data being shared comes from a payment account or some type of unregulated account. Indeed, the data being contributed and shared could come from the customer herself (user-generated information or 'UGC'). In effect, even the information coming from the user's accounts with third parties is effectively user-generated, particularly in terms of whether the service provider takes responsibility for its accuracy and so on.

These licensing issues must also be considered in terms of what licences are required 'upstream' from the customer, the service provider and any sources of data, as well as downstream licenses - and usage restrictions - from the standpoint of the service provider, the customer and third parties receiving the data. These licences are likely to be reflected in an array of different contracts, including customer terms and commercial agreements. Appropriate disclaimers, exclusions and limits on liability must also be considered.

This is where the sanity of specifically regulating payment account information services becomes questionable, as some of the typical commercial requirements may conflict with the liability and information requirements relating to an AIS, in which case it would need to be 'carved-out'.

Conclusion

These are not the only issues related to the supply of account information services or other data services, but they do illustrate the complex challenges arising from the fact that AISPs had to be subjected to regulation for banks to cooperate with them, and yet an AIS involves the supply of data in a way that other regulated payment activity does not, often in combination with other data services.

Had Enough of GDPR? Then Try The ePrivacy Regulation!

My radio silence of late has been mainly due to reviewing a flurry of privacy policies and data sharing agreements in anticipation of the General Data Protection Regulation taking effect on 25 May 2018 ("GDPR Day"). But the noose is tightening further on the data hungry social network services with additional regulations to cover e-communications and the data on your device, regardless of whether it's personal or non-personal.

As the European Commission has recently explained in a handy "factsheet", the Regulation on Privacy and Electronic Communications ("ePrivacy Regulation") is also wending its way through the EU legislative process (latest text here). 

This will extend current ePrivacy rules to cover not only cover traditional telecoms providers but also internet-based voice and messaging services, such as Skype, WhatsApp, Facebook Messenger, Gmail, iMessage and Viber. 

The new regulation covers electronic communications and the integrity of the information on your device, regardless of whether it's personal data or non-personal data. It creates a right to the privacy and confidentiality of communications, and dictates that mobile apps or internet services through which you communicate cannot intercept, record, listen into, or tap in your communications. 

Meanwhile, the GDPR covers all personal data independently of how it is transmitted and defines rights for personal data protection.  So there is overlap with the ePrivacy Regulation. 

This means when communications include personal data, the general rules of the GDPR apply, unless the ePrivacy Regulation lays down more specific rules.

 

Privacy Not Core To Your Business? Take The ICO's 12-Step Programme

Though years in the making, it's possible that word of the EU's data protection reforms has yet to penetrate some boardrooms, let alone the IT development roadmaps of UK plc, and the UK Information Comissioner is very concerned that Britain will not be ready to comply. So much so that it has created a new website to urge preparation for the new law - even though the draft directive is not due to be passed until after the UK's referendum on EU membership, and will not take effect until mid-2018. 

Brexit fans should still be concerned. The US will tell you that appropriate privacy safeguards are just one cost of doing business with Europe, and the UK will also need to comply in substance if it is to qualify for cosy trade deals as a non-member of the EU. 

The ICO recommends starting with this 12-step programme.