This article was published in slightly different format as a two-part article in the July/August and September 2007 issues of the Electronic Banking Law and Commerce Report.

Data privacy law has become a huge compliance issue for multinational businesses operating in Europe and the compliance challenge is perhaps greater for banks and other financial institutions than it is for multinationals in most other sectors. The European Union [EU] data laws regulate personal information on the EU side—all data about “personally identifiable individuals.” To a bank, that broad brush sweeps in virtually the entire business, because in a sense, besides money, a bank’s core business is personal data: information about loans, guarantees, credit card transactions, deposits, debits, estate planning, funds transfers, check clearing, signature verification, securities transactions, electronic banking, employee data—the list goes on.

The compliance challenge here for banks may be even greater than it is for other industries that also traffic in personal data (such as for multinationals involved in insurance, telecommunications, medical services, consulting, journalism and transportation), because two of the primary tools for EU data privacy law compliance for cross-border data transmissions—so called “safe harbor” and “binding/model contractual clauses”—are unavailable to many banks, because of their unique status as financial institutions.

This article is a primer on EU data protection law in the context of US-based multinational banks and financial services businesses that process customer and employee data in Europe. The article begins (1) with a comparative look at data privacy regulation in Europe, as compared to the US. It then (2) summarizes what the EU data protection directive does domestically in Europe as to banking operations there. The article next (3) addresses the unique issue of transferring banking data from Europe to the US in the context of a US-based multinational bank’s European-side customer and employment operations. The article closes (4) with a note on the local adaptation (“transposition”) of data laws in the various EU countries and (5) a strategy summary. In short, this article offers a compliance overview for a multinational bank’s US-side privacy and legal compliance professionals charged with ensuring that European operations respect local data privacy laws.

Data Privacy Regulation in the US vs. Europe: A Clash of Jurisprudential Perspectives

Domestically within the US, our data privacy law is increasingly robust. In recent years, US federal, state and local governments have weaved an intricate web of laws protecting many aspects of Americans’ privacy. As our information-based economy becomes increasingly complex and as personal privacy becomes an increasingly hot social and political topic stateside, American privacy laws and tort concepts have followed along, evolving into important safeguards for Americans in the information age.

Therefore, perhaps it is surprising that many foreign jurisdictions (notably but not exclusively Australia, Argentina, the EU, Canada and Hong Kong) regulate personal data privacy far more comprehensively than America does. By international standards, by comparison, the US takes an almost laissez faire “sectoral” approach to privacy law, concentrating on a handful of specific areas of data management—medical records, credit reports, children online and electronic surveillance, for example. Even with all its privacy laws, the US leaves many, maybe most, areas of personal data processing largely unregulated. This contrast is especially stark as compared with the EU Unlike the US sectoral approach, the EU has an omnibus data protection law that regulates all data about identifiable people. Because EU data law is comprehensive, it reaches even seemingly innocuous databases—for example, telephone books, restaurant reservations systems, employee telephone directories, personal weblogs—and it affects core aspects of business operations law—such as invoicing, personnel records and customer records. In the banking context, EU data reaches virtually all customer, transaction, account and employee records, be they paper or electronic.

The difference between US and EU privacy regulation grows from the jurisprudential gulf separating the American “sectoral” approach to privacy regulation from other countries’ comprehensive sweep. The First Amendment to our Constitution guarantees that “Congress [and the state and local governments, via the Fourteenth Amendment] shall make no law…abridging the freedom of speech, or of the press….” Of course, the most interesting topic of speech and the press is always people, so free speech necessarily implicates privacy.

Because the First Amendment grants Americans an explicit right to discuss, print, or post online most information we have about others—without any express exception for speech that might intrude on someone’s claimed privacy—the text of our First Amendment elevates free speech interests above privacy concerns. As such, our Constitution actually protects would-be privacy violators more explicitly than potential victims of privacy breaches: Our free-speech right is explicit, but our privacy right is merely implicit. Unlike many other countries’ constitutions, the US Constitution nowhere contains the word “privacy”; in fact, the privacy right, according to our Supreme Court, exits only in the Constitutional “penumbra,” or shadows.1

Not so in Europe. Rather than putting privacy interests on a scale counterbalanced by free speech rights, the EU seems to analogize privacy rights with intellectual property rights: If government is going to let corporations keep competitors from exploiting brand-names and trademarks, the law certainly should allow citizens to keep others from trafficking in their credit history and sex lives. Just as intellectual property like a copyright is data belonging to an owner, the EU legal systems protect personal data almost as belonging to the person whom they are about: Why should an individual citizen’s political affiliation, salary and sexual orientation be less worthy of property protection than a for-profit business’s trademark, slogan and jingle?

The difference between the US and EU approaches is even greater in those European nations that suffered under fascist and Communist governments during and after World War II, where secret police exploited personal information in classified files for nefarious government purposes—such as selecting whom to send off to concentration camps. This legacy in these countries instills a healthy skepticism among Europeans of governments (and, for that matter, of faceless financial services corporations) amassing databases with personal information used for who-knows-what purposes.

The European approach to privacy regulation seems defensible—indeed, preferable—in the eyes of many privacy advocates. But it obviously raises a fundamental conflict with the US: The European approach in effect prioritizes privacy over free speech, while the US in effect does the reverse. This clash, not surprisingly, has significant effects an transatlantic banking operations.

The European Union Data Privacy Directive

In 1995, the EU passed a comprehensive data privacy law called the “European Union Directive on the Protection of Individuals with Regard to the Processing of Personal Data and on the Free Movement of Such Data” (the Directive).2 The legislative tool the EU selected for privacy law—a “directive”—requires each EU member state (of which there are now 27)3 to enact its own local law adopting (or “transposing”) the thrust of the directive. The data Directive mandated that the member states pass their local data laws by October 25, 1998, but in fact, full implementation took several years more.4

Therefore, the text of the EU data Directive offers us a blueprint for data privacy laws across Europe—but in any given situation, the Directive itself is nothing more than a mere framework. As to each specific data privacy issue arising within Europe, the relevant country’s (or countries’) local statute that adopts (“transposes”) the Directive will determine data privacy rights and responsibilities.5 In other words, the Directive itself speaks to only 27 entities—the 27 member state governments. For most purposes, the Directive does not itself dictate rights for European individuals or responsibilities of businesses operating in Europe. But it does serve as a framework for discussing data protection laws across the EU.6

What the EU Data Directive Does: An Overview

The EU data Directive requires each member state to pass a privacy law, called a “data protection” law, that reaches both government and private entities—including businesses like banks that process employee and consumer data. While America’s “sectoral” privacy laws target discrete categories of data (medical and credit records, children online, etc.), the EU Directive mandates omnibus laws that cover all “processing” (defined to include even collection and storage) of data about personally identifiable individuals. The Directive is not anchored to electronic (computerized) data and therefore reaches written, Internet and even oral communications. In the banking context, the Directive regulates all data identifiable to a bank’s customers, employers, guarantors and individual suppliers in the EU, such as data about European bank accounts, credit cards, funds transfers, deposits and debits, securities transactions, signature records, electronic banking, guarantees, loans and bank employees.7

An important aspect of the Directive for banks based in the US is the Directive’s extraterritorial reach. Because it would otherwise be so easy to circumvent the Directive by transmitting regulated data outside of Europe for processing offshore, the Directive specifically prohibits sending personal data to any country without a “level of [data] protection” considered “adequate” by EU standards.8 While there are some tools that allow holders of European personal data to transmit this information outside of Europe to, for example, the US, some of these tools are unfortunately not available to banks.

Social and Legal Context Underlying the EU Data Directive

Nefarious uses of secret files under World War II-era fascists and post-War Communists instilled in many Europeans an acute fear of the unfettered abuse of personal information—a fear that lingers to this day. Many of today’s Europeans remain vividly aware of secret denunciations that sent neighbors and relatives to work camps. This amounts to a cultural issue difficult for frontier-spirited Americans to understand: In many parts of Europe, a culture of secrecy permeates society to an extent almost unimaginable in the free-speech frontier-spirited US. Indeed, this cultural difference—densely populated Europe’s protections of confidentiality versus the wide-open United States ethic of “sharing” feelings and information—may be one of the biggest social divides between the two regions.9

As computers took over the warehousing of personal data, Europeans’ wariness of secret government files morphed into a skepticism of corporate databases and the reams of personal financial data that banks (and others in the industry, such as credit card transaction clearinghouses) process falls squarely within this concern. A feeling arose that only a coordinated legislative response could protect citizens from abuses of their personal information. In the post-war decades, Europeans took a series of steps in this direction, with some countries (Germany, France) passing their own comprehensive data laws.10 By 1980, the Organization for Economic Cooperation and Development was able to issue “Recommendations of the Council Concerning Guidelines Governing the Protection of Privacy and Trans-Border Flows of Personal Data,”11 and in 1981 the European Council (not the EU) issued a “Convention for Protection of Individuals with Regard to Automatic Processing of Personal Data.”12 While the aspiration was for a uniform system of data protection laws across Europe, the OECD and the European Council conventions were not self-executing and data protections across Europe continued to vary widely.

Meanwhile, by the 1980s a reinvigorated EU was charging ahead, proactively “harmonizing” (aligning) laws across a wide range of sectors as part of its “Single Market Program”—the initiative that solidified a collection of European countries into a single economic entity: the EU Simultaneously, new technologies were emerging and threatening personal privacy (in the banking context this would include: computerization of accounts; automated check clearing; credit card processing; automated handling of deposits and debits, loan payments, funds transfers; banks’ computerized human resources information systems and bank security technology, such as closed-circuit video monitoring).13

These factors added up to a consensus that, in Europe, regulation should safeguard citizens’ personal data from prying governments and corporations, including banks. From the European perspective, the solution was obvious: Piggyback on EU integration and align Europe’s then-inconsistent “data protection” (privacy) laws via a single, pan-European data protection law.14 That led to the EU data Directive.

Terminology

The EU data Directive creates its own jargon, which is essential to master before discussing any EU privacy law issue.

Personal data” means information about any “identified or identifiable natural person”—known as the “data subject.”15 “Identified or identifiable natural person” means anyone who “can be identified, directly or indirectly, in particular by reference to an identification number or by one or more factors specific to his physical, physiological, mental, economic, cultural or social identity.”16

In the bank context, this includes all customers, guarantors, individual suppliers and employees, including, for example, data such as a signature card, electronic funds transfer memo, photo of a bank employee on an identification badge or on a video monitor, or a listing of account balances designated either by customer name or by some identification number (company ID number, social security system/tax ID number). However, a truly “anonymized” list of data—such as, for example, a list of loan amounts not designated by name or number—would not be “personal data.”17 As such, genuinely “anonymizing” personal data is always a way to sidestep the application of the Directive.

Processing of personal data” means “any operation or set of operations…performed upon personal data,” automatically or otherwise.18 This definition is wide open, because it includes “collection, recording, organization, storage…retrieval…use, disclosure by transmission,” and “dissemination.” By expressly including “storage” in the definition of “processing,” the mere act of holding personal data is, under EU law, a regulated activity. In the bank context, any records, be they paper or electronic, on customers or employees or personal merchants that are identifiable by name or by identification number are processed personal data, even when they are merely stored.

Other essential EU Directive jargon:

  • A data “controller” is anyone who determines the “purposes and means of processing of the personal data,”19 and would include any bank.
  • A data “processor” is anyone who processes personal data for a controller, such as a provider of credit card transaction services.20
  • A “third party” is anyone who processes data under “the direct authority” of a controller or processor.21

Data Processing Rules Domestically Within Europe

With these broad definitions as a springboard, the Directive extensively regulates the processing of personal data. The Directive’s main objectives are:

  • To “protect the fundamental rights and freedoms of natural persons and, in particular, their right to privacy with respect to the processing of data.”22
  • To protect EU citizens from—according to one commentator—the “aggressive wave of data collection and distribution similar to that in the United States.”23
  • To harmonize privacy laws across member state borders, ensuring the free flow of personal data among the EU member states.24

The rules the Directive imposes domestically within Europe to achieve these broad objectives break down into three categories:

  • Complying with data quality principles and rules.
  • Disclosing to data subjects and addressing their concerns.
  • Reporting to state agencies.

In vivid contrast to the US “marketplace of ideas” where citizens are free to research and discuss whatever they want, the EU data Directive, as worded, actually prohibits all personal data “processing”—except for processing that is “fai[r], “lawful[l],” and “legitimate.”25 Specifically, the Directive imposes a presumption against “collect[ing]” and “process[ing]” personal data unless for “fai[r] and lawful[l],” “specified, explicit and legitimate reasons.”26

In practice, this means data controllers must process personal data consistent with a number of “data quality principles”:

1. Fairness: Process data “fairly and lawfully.”

2. Specific Purpose: Process and store data “for specified, explicit and legitimate purposes and not further processed in a way incompatible with those purposes.”

3. Restricted: Ensure data are “adequate and relevant and not excessive in relation to” the purposes they are for which they are collected.

4. Accurate: Ensure data are “accurate and, where necessary, kept up-to-date,” so that “every reasonable step [is] taken to ensure” errors are “erased or rectified.”

5. Destroyed when obsolete: Maintain personal data “no longer than necessary” for the purposes for which the data were collected and processed.27

In addition to these five listed principles, the Directive elsewhere adds two more:

6. Security: Data must be processed with adequate “security” (a “controller must implement appropriate technical and organizational measures to protect personal data against…destruction or…loss, alteration, unauthorized disclosure or access, in particular, where the processing involves the transmission of data over a network.…”)

7. Automated processing: “Decision[s]” from data processing cannot be “based solely on automated processing of data” that “evaluate[s] personal aspects.”29

Here are some banking-context examples of data processing that likely could violate these seven data quality principles and therefore be illegal under the European laws that implement the directive:

1. A bank sells its customer list to an insurance company (violates “fairness” principle).

2. A bank combs its own depositor files for leads in marketing estate-planning or securities-brokering services (violates “specific purpose” principle).

3. A job application for a high-level banking position asks applicants for information about their primary education and military experience (violates “restricted” principle).

4. A credit bureau customer complains about a claimed error in her account, but no one at the credit bureau does anything about it (violates “accurate” principle).

5. A bank retains computer backup files, attendance records and other business information going back many years (violates “destroyed when obsolete” principle).

6. A financial services firm’s night janitors straighten up piles of bank files (violates “security” principle).

7. A bank’s website allows applicants to apply for a job, or depositors to apply for a loan; resumes, or loan applications, get screened with a special program that searches for key words (violates “automated processing” principle).

But even complying with these data quality principles is not enough. The Directive goes on to impose a separate hurdle prohibiting some data processing even consistent with these principles. Indeed, under the Directive, all processing of data—even consistent with the principles—is actively illegal, unless:

  • The data subject consents or
  • The processing is “necessary” (not merely convenient) to accomplish one of five objectives:
    • to “perfor[m] a contract to which the data subject is a party”
    • to “compl[y]” with a law
    • to “protect” the data subject’s “vital interests”
    • to advance the “public interest” or facilitate “the exercise of official authority”
    • to further the controller’s (or some other “disclosed” party’s) “legitimate interests” without infringing the data subject’s “fundamental rights and freedoms.”30

Therefore, in Europe, processing ordinary personal data is presumed illegal unless the processing both complies with all seven data quality principles and is either consented to or “necessary.”

These are the rules that cover ordinary personal data. On top of them, the EU data Directive adds a layer of extra rules for a few classes of information now known as “sensitive” data: personal data that discloses “racial or ethnic origin, political opinions, religious and philosophical beliefs, trade-union membership, [or]…health or sex life.”31 The Directive flatly prohibits processing all sensitive data32 unless an express exception applies—including, notably, an “explicit consent,” “freely given.”33 The definition of sensitive data conspicuously omits reference to financial data, but some EU member states may treat financial data as sensitive.

As extensive as the sweep of the Directive is, however, member states have some leeway in carving out certain exceptions, such as for national security, defense, criminal investigations and the like.34 The Directive also has member states grant limited exceptions for “journalistic” and “artistic or literary expression”35—but only to the extent “necessary” to balance data privacy rights with “the rules governing freedom of expression.”36 And the Directive allows an exception for processing certain “historical, statistical or scientific” data.37 Further, some authorities claim that European controllers can freely process data for personal or household use and that non-profit organizations may process “sensitive” data about their members.38

Disclosing to Data Subjects

Once someone in Europe processes personal data consistent with all these principles and rules, the analysis turns to disclosures to data subjects.

The EU data Directive prohibits processing personal data in secret: European data subjects, including bank customers and employees, enjoy a legal right to see what information others have on file about them and to learn what is being done with it.39 This right can seem revolutionary in the eyes of US businesses, which are used to processing personal information without ever mentioning anything to individuals affected. For example: US banks may share customer lists between departments for marketing purposes and US credit card companies may track customers’ spending patterns for internal marketing or security purposes. US banks may restrict employees’ access to their own personnel files.

In Europe, on the other hand, the Directive requires telling individuals what data are on file about them and how those data are “processed.” The notice must say why the information was collected, who collected it and who can access it.40 Additionally, the European data subject (such as a bank’s customer, loan applicant, guarantor or employee) must have access to the information itself, “without constraint at reasonable intervals and without excessive delay or expense.”41 A data subject who claims some error in his data can offer corrections or ask the controller to purge the incorrect information42: A data subject may object “on request and free of charge, to the processing of personal data relating to him which the controller anticipates being processed for the purposes of direct marketing, or to be informed before personal data are disclosed for the first time to third parties…and to be expressly offered the right to object free of charge to such disclosures or uses.”43 If a dispute about the data arises, the Directive sets out complex dispute resolution mechanisms that kick in.44

Reporting to State Agencies

The Directive requires each member state to set up its own “Supervisory Authority” or “Data Protection Authority” (DPA)—a bureaucracy or government agency dedicated to privacy—to administer its data protection law.45 Member states can and some do, require controllers to file one-time or annual summaries of all personal data processing they are doing.46 The summary usually needs to include: controller’s name, purpose and description of the processing, recipients and any proposed transfers of data to third countries.47

In practice, however, different member states handle the disclosure requirement in very different ways. France and the UK are two member states with proactive DPAs that require controllers to file fairly comprehensive annual disclosures. In fact, France’s DPA even retains a right affirmatively to approve certain proposed data processing operations, which in France are illegal until the French Supervisory Authority (known by the French acronym CNIL) issues a specific approval. This French CNIL procedure was widely publicized in the summer and fall of 2005, when France denied McDonald’s and a unit of CEAC Technologies permission to operate Sarbanes-Oxley whistleblower hotlines and then issued regulations on this topic.48 At issue was the data privacy rights of the accused wrongdoer subject to a whistleblower’s complaint.

Once a DPA receives required disclosures, it assesses how controllers’ processing procedures present specific “risks to the rights and freedoms of the data subjects.”49 The DPA then “publicize[s]” the data processing “operations” it learns about.50 DPAs also have enforcement powers and in addition to data subjects have private rights of action.51

Transfers of Data to Countries Outside Europe

All the aspects of the EU data Directive we have discussed to this point apply internally within Europe.

However, we have not yet even raised what tends to be the primary EU privacy law compliance challenge confronting US-based banks’ headquarters: The Directive’s provisions on transmitting personal data, such as virtually all bank customer, transaction, loan applicant and employee data, outside Europe, such as to US bank headquarters, or to an offshore processing center in, say, India.

As soon as the EU decided to regulate personal data, as a practical matter, it had to impose tight limits on transmitting personal information abroad. By imposing the tight data restrictions we have discussed on European data controllers—data quality principles, disclosures to data subjects, reports to state agencies—the EU faced a huge risk that, rather than comply, certain data controllers in Europe might simply transmit and process European data subjects’ personal data somewhere offshore, be it in Nigeria, Haiti, Mexico, Japan, the United States or any other country without domestic data protection laws like Europe’s. As such, European data controllers could easily do an end-run around the EU data privacy superstructure, eluding the Directive entirely, simply by processing European data offshore.

To plug what otherwise would be a gaping hole here, the Directive imposes tight limits on transmitting personal data outside of Europe. These limits have profound effects on US-based multinational banks’ worldwide operations.52 And accordingly, these are the EU data protection rules that attract the most attention from bank headquarters outside Europe.

Many a US-based bank has been surprised to learn that EU data law reaches information about the bank’s own customers and employees in Europe transmitted back to US headquarters. A typical US response is that the Europeans are overreaching when they impose their data protection rules onto intra-company data housed at US headquarters or on a US-based server. But from a European standpoint, these data transfers, even though intra-company, nevertheless transmit personal data about European data subjects outside Europe’s jurisdictional reach. To a European bank customer or employee who takes comfort in the EU’s tough data protections, transfers of personal data outside Europe—even intra-company transfers—raise a real risk that personal data offshore becomes susceptible to abuse.53

Data Transfers Allowed to “Third Countries” Abroad

The data Directive dedicates its Chapter IV to requirements for sending personal data outside Europe. The core provision here seems sweeping: No data can leave Europe unless the transmission goes to some “third country” that “ensures an adequate level of protection”54—in other words, data about European individuals can only go into “countr[ies]” with data protection laws that the European Commission considers “adequat[ely]” safeguard Europeans’ personal data. This includes, for example, even intra-bank transfers about customer, card holder, or employee data and for these purposes a “transfer” would include putting data onto a US server-hosted computer system.

That sets the bar amazingly high: To date, the EU Commission has formally designated only Argentina, Canada, Guernsey, the Isle of Man and Switzerland as “third countries” offering this “adequate level of protection.”55 This formal Commission designation means that now, transmitting personal information from, say, Latvia to Argentina is legally no different from sending data from Austria to Germany. For most legal purposes, this club of countries, together with the European Economic Area (Iceland, Norway and Liechtenstein), forms a sort of “EU data zone.”56

The problem, of course, is the rest of the world—sending personal data out of Europe to the US or India or to any other non-EU jurisdiction on Earth other than Argentina, Canada, Guernsey, the Isle of Man and Switzerland.57 Under a strict reading of the Directive’s Article 25(1), personal data transmissions to any other country would appear flatly illegal, because the text of the Directive’s Article 25 consistently talks in terms of whether a “third country” offers an “adequate level of protection.”58 This would seem an all-or-nothing proposition of comparative law: Either a “third country” has enacted a generally applicable privacy law that the EU Commission deems “adequate” (therefore making the county eligible to receive personal data from Europe), or it has not (therefore keeping it ineligible).

But in practice, this all-or-nothing analysis quickly devolved to mean something very different from what Article 25’s many references to “third countr[ies]”59 would seem to imply. After a couple of years of futilely trying, in diplomatic discussions, to convince the US and other “third countries” to pass omnibus, European-style data laws offering “adequate…protections,”60 the EU Commission loosened up and began promulgating ways for individual overseas data processors to bind their institutions “adequate[ly]” to EU-style data “protections”—empowering them to receive data from Europe, not country by country, but company by company.

There are now three such methods, or tools, for a non-European entity to become unto itself its own island nation (“third country”) of Article 25 “adequate…protection”:

  • Safe harbor
  • Binding/model contractual clauses
  • Binding corporate rules61

Further, the data Directive’s Article 26(1) authorizes a number of other exceptions, or yet other ways legally to transmit personal data outside of Europe even to a “third country” that fails to offer an “adequate level of protection.” A data controller or processor can legally send personal data outside of Europe to the US, or any other country, if:

  • The data subject has [freely] given his consent unambiguously to the proposed transfer [to be enforceable, a consent must indeed be unambiguous and freely given—EU data authorities take the position that a consent must specifically list the categories of data and the purposes for the processing outside the EU; in the employment context, consents may be deemed presumptively not freely given, merely because of the imbalance in bargaining power between employer or job applicant and employee] or
  • The transfer is necessary [not merely convenient] for the performance of a contract between the data subject and the controller or [for] the implementation of precontractual measures taken in response to the data subject’s request or
  • The transfer is necessary [not merely convenient] for the conclusion or performance of a contract concluded in the interest of the data subject between the controller and a third party or 
  • The transfer is necessary [not merely convenient] or legally required on important public interest grounds, or for the establishment, exercise or defense of legal claims or 
  • The transfer is necessary [not merely convenient] in order to protect the vital interests of the data subject or 
  • The transfer is made from a register which, according to laws or regulations, is intended to provide information to the public and which is open to consultation either by the public in general or by any person who can demonstrate legitimate interest, to the extent that the conditions laid down in law for consultation are fulfilled in the particular case.62

Also, of course, there is no prohibition against transmitting genuinely anonymized data out of the EU—where the identity of the data subject is impossible to determine, the data transmission falls outside the scope of the directive. This would include, for example, intra-bank transfers of deposit or loan figures for accounting purposes, when stripped of identifying information.

Therefore, even a bank (or other data processor) based in a country like the US that is not a member of Europe’s club of data-law countries, can legally receive information about identifiable individual Europeans (including the bank’s own customers and employees), but only if the transmission meets one of these narrow Article 26(1) exceptions—or else only if the transmission is sheltered under one of the three individualized methods, or tools, for transferring data: safe harbor, binding/model contractual clauses or binding corporate rules. Each tool is complex and all three tools are not available to banks.

Because Europe sees the US as a “third country” that fails to offer an “adequate level of [data] protection,”63 the EU data Directive looms as a huge barrier for US-based multinational banks’ headquarters that need data on their own European customers, guarantors, suppliers and employees. Indeed, as soon as the Directive became effective in 1998, it became clear that it actively threatened data flows between the two largest trading partners on Earth. Financial services sector examples of Europe-to-US data flows put at risk include:

  • Routine financial transactions including ATM and credit card transactions, check-clearing, signature verification, funds transfers and securities transactions. 
  • US-server-hosted databases containing deposit, loan, customer, check clearance and other financial data. 
  • Interactive bank websites and bank intranets. 
  • Transatlantic customer service operations.
  • Customer and employee directories. 
  • Administration of equity plans, expatriate programs, succession management and other transatlantic human resources functions.
  • Credit card transaction processing. 
  • Human resources information systems (PeopleSoft, SAP, Ceridian, Oracle and the like). 
  • Routine intra-bank mail, express delivery documents, e-mails, employee directories, intranets and telephone calls.

Not surprisingly, how to maintain EU-to-US data flows under the Directive materialized as a key business issue on even the diplomatic radar screen. In the late 1990s, the EU Commission and the US government, led by the US Department of Commence, launched formal discussions to come up with a solution tailored for US businesses.64 Initially the EU Commission—perhaps naively—actually hoped to convert the Americans: Brussels diplomats spent almost a year trying to convince US officials that a comprehensive data law modeled on the Directive would protect Americans and strengthen US interests.65 Of course, however, the immense cultural and free speech divide66 kept the US from seriously entertaining membership in Europe’s club of “third countries” offering “adequate level[s] of protection.”67

Safe Harbor

So the European Commission and the US Department of Commerce turned to tailoring a bespoke US solution that became “safe harbor.”68 As soon as the Europeans and Americans hammered out this safe harbor compromise, the EU Commission ratified it via a special “decision.”69 (A decision is a form of EU legislation that, unlike a directive, applies directly across Europe without member state ratification.)

Safe harbor, which is unique to the US and completely unavailable elsewhere, is a voluntary self-certification system for transmitting data from the EU to the US—but not beyond. Under it, US data processors can receive personal data from Europe if they agree to accept restrictions requiring them to treat the data as if still physically in Europe—and subject to the Directive. In Directive Article 26 terms, a safe harbor entity essentially becomes an autonomous “third country” free to receive personal data from Europe as a full-fledged member of the club of “countr[ies]” offering “an adequate level of protection.”70 Contrary to a widespread misconception, safe harbor restrictions need apply only to personal data about European data subjects: A safe harbor company remains free to deny EU-style data protections to, say, American data subjects.

Because the safe harbor structure wraps personal data from Europe in a blanket of EU data Directive compliance, the substantive safe harbor requirements essentially track the Directive’s data quality principles and rules.71 Self-certifying under safe harbor requires publicly committing, on the US side, to comply with seven safe harbor principles that mostly track the Directive’s seven data quality principles and rules.72 In addition, self-certifiers have to:

  • Disclose their privacy policies publicly. 
  • Accept jurisdiction of the US Federal Trade Commission (FTC) under Section 5 of the Federal Trade Commission Act (which prohibits unfair or deceptive practices affecting commerce), or of the US Department of Transportation under 49 USC. § 41712.73 
  • Notify the US Department of Commerce of the self-certification: Procedurally, self-certifying merely entails filling out a short form on the Department of Commerce’s website—but that form certifies the entity already has in place fully compliant data processing systems and protections.74

Organizations qualify for the safe harbor in three ways. The standard route is to develop an in-house privacy policy (covering at least personal data received from Europe) that complies with the safe harbor principles.75 A less-traveled route is to join a self-regulatory privacy program that complies.76 In addition, an organization subject to a statutory, regulatory, administrative or other body of law (or rules) that effectively protects personal privacy might also, in theory, qualify.77

However, safe harbor is not available to banks, because of Gramm-Leach-Bliley and an exception to Federal Trade Commission jurisdiction.78 Banks and other US financial institutions not regulated by the FTC, therefore, must strike safe harbor from their list of compliance tools and move on to the others: Binding/standard contractual clause and binding corporate rules.

Binding/Model Contractual Clauses

Safe harbor aside, a completely separate way legally to transmit personal data outside of Europe and a method that is, in theory, available to financial institutions (at least those with discrete legal entities operating in the EU), is so-called “binding” or “model contractual clauses.” The text of the Directive itself lets the Commission approve transfers of personal data even to third countries that fail to ensure an “adequate level of protection”79 if the controller erects “sufficient safeguards” via “certain standard contractual clauses” consistent with the “Commission’s decision.”80

In 2001, 2002 and 2004, the Commission issued three separate decisions81 anointing three different boilerplate contracts as appropriate cover for an EU data controller (“data exporter”) to send personal data to controllers and processors abroad (“data importers”).82 The Commission’s three decisions amount to pre-approved adhesion contracts which data importers and exporters can either agree to accept in whole—or not. To negotiate terms within the forms would kill the Commission’s protection, so after a data exporter and importer decide to use a model contract, all there is to negotiate is which of the three forms to use.83

One challenge in the bank context to binding contractual clauses is that, like any contracts, these binding/model contracts need to be entered into between separate parties. Multinationals in most industries operate via locally incorporated subsidiaries in each country where they do business, so this does not pose any problem for them; the European affiliate subsidiaries of, say, a manufacturing company can enter a binding/model contract with the US parent entity. But for regulatory reasons, multinational banks often do business worldwide via unincorporated branches. This structure poses an obvious practical problem for binding/model contractual clauses, in that a bank cannot enter into a contract with itself. Of course, however, a US bank can enter a binding/model contract with any distinct legal entity in Europe, such as any separately incorporated affiliate or an unaffiliated services provider.

Obligations of the Data Exporter and Data Importer

Speaking very broadly, the Commission’s model contracts act like private safe harbor arrangements, where a US data importer contractually pledges to follow a package of rules that fairly closely track the obligations of safe harbor, (and thus the obligations of the Directive).84 While details differ a bit among the three model contract forms, in essence a model contract “data importer” picks up the burden to process data European-style, with: purpose limitation; data quality and proportionality; “transparency”; security/confidentiality; data subject right of access/rectification/dispute resolution; restriction against onward transfers; special rules for sensitive data; restrictions regarding direct marketing and automated decision making.85

Although the model contractual clauses themselves are pure boilerplate and are not susceptible to rewording, parties must specify in an appendix the precise categories of data and types of processing they will conduct. Parties must also say whether they will transmit any sensitive data.86 And parties to model contracts have to promise to respond to reasonable inquiries from data subjects and supervisory authorities87—as well as commit to accepting data audits by data exporters or independent inspection bodies.88

Liability

If a party breaches a model contract, data subjects (such as a bank’s customers, employees and guarantors)—third-party beneficiaries—who suffer injury can win compensation from the data exporter or importer, as could a member state data protection authority.89 Under one of the three model contracts, the data exporter and data importer are jointly and severally liable, unless they agreed to indemnify one other.90 However, one of the other sets of model clauses91 lays out an alternate liability regime based on due-diligence obligations. This model exposes the data exporter and data importer to liability in proportion to their respective breaches of the contract.92 Obviously this alternate is especially attractive to parties at arm’s length (as opposed to parties within a corporate family),93 such as, for example, a bank and a credit card transaction clearing house. To prevent abuses, under this regime, member state data protection authorities get beefed-up powers to cut off data transfers.94

European data agencies and courts take data privacy violations seriously in the out-of-EU context. A number of Spanish judgments have reached the Spanish limit of €300,056 (US$420,000). The Spanish data agency is said to be self-funded from fines. France, too, can impose €300,000 fines, as well as criminal penalties for illegal out-of-EU transmissions and while for years there were few examples of large data awards in Europe outside of Spain, in 2007 big-money data judgments were starting to issue out-of-member states including France, Greece and the United Kingdom.

Binding Corporate Rules

Safe harbor and model contractual clauses each have serious shortcomings in the banking context: Safe harbor is not available to financial institutions and model contracts are not available within entities that operate abroad via unincorporated branches. Also, both these regimes envision simple Party-A-to-Party-B data transfers from Europe to a single offshore country. In the real world, though, data transfers get a lot more complex. For example, these days, there are multinational banks that are (for example) daily:

  • E-mailing personal data to recipients in several countries simultaneously. 
  • Inputting personal data onto globally accessible intranets and human resources information systems.95 
  • Zapping customer information back and forth among outsource partners. 
  • Using complex chains of onward data transfers such as from Europe to US headquarters and then over to back-office operations in, say, India and ultimately back to Europe.

Neither safe harbor nor model contracts were engineered to accommodate these multi-faceted international data transfers. To customize a more effective tool, in June 2003, the “Article 29 Data Protection Working Party”—an EU data protection advisory body established under the Directive itself96—published a Working Paper outlining a third way to send data to third countries whose laws fail to offer “adequate protections”:97 So-called “Binding Corporate Rules” (BCRs) are corporate codes of conduct that legally bind each branch or entity of a conglomerate to company-specific, EU-compliant data handling systems. That is, under BCRs, a multinational builds its own in-house structure sheltering the data processing of its branches and partners worldwide. Once approved, BCRs empower the multinational freely to transfer personal data on EU data subjects in-house worldwide.

BCRs are an intriguing, but (as of 2007) still largely untested, tool. What is certain is that BCRs have been seen as neither for the fainthearted nor the tight-budgeted. BCRs are seen as demanding far more thorough global data protection systems and attracting far more intrusive data protection authority (DPA) bureaucratic approvals, than safe harbor or model contractual clauses.98 BCRs will appeal most to well-capitalized multinationals that genuinely respect privacy rights and commit to top-down EU data law compliance and they are especially interesting to banks and financial institutions because of the lack of viable alternatives in this sector. A conglomerate opting for BCRs is likely to be in the data-processing business (in one way or another); it will have a robust business case justifying this all-bells-and-whistles approach. This said, however, by early 2007, the BCR early adopters were getting their BCRs approved and BCRs were starting to become a viable, even exciting, option, especially for the financial services sector.

How do BCRs work? Our blueprint is yet another Article 29 Working Party Working Paper, issued almost two years after the first one, in April 2005.99 That Working Paper requires a BCR applicant to apply to its most “appropriate” DPA.100 To get its BCRs approved, the applicant asks the lead DPA to authorize its draft BCR package, which spells out exactly how the applicant company processes and protects EU personal data worldwide. If, after the inevitable back-and-forth, the lead DPA provisionally approves the BCR package, it then sends the package on to every other affected member-state DPA. Then the other DPAs can object. Final approval comes when all sign on.

Of course, the BCR application package includes the conglomerate’s documents that compose its BCRs?all relevant policies, codes, procedures, notices, contracts and dispute resolution and other systems.101 The application has to prove a BCR program actually is up and running, with an auditing feature in place. As with safe harbor and model contractual clauses, BCRs have to specify: the types of personal data being transmitted; the methods of (and purposes for) the data processing;102 data security measures; and a system for how the BCR applicant company can amend and report on, its BCR system.103

A BCR application must also prove the applicant’s data protection systems really are binding both “internally” and “externally”:104

  • Showing “internal” BCR compliance requires evidence that the BCRs would bind all the applicant’s branches, subsidiaries and affiliates, even its partners and subcontractors. A BCR applicant could establish internal compliance, for example, by offering:
    • a headquarters mandate that all branches and affiliates must comply with the BCRs (assuming the corporate by-laws and applicable member states’ laws recognize such a declaration).105
    • an example of the multinational’s contractual clauses with subcontractors requiring BCR compliance and imposing tough penalties for violations.106
    • proof that employees will follow the BCRs;107 for example, the BCR application could evidence: data protection training and compliance programs, references to BCRs in form employment contracts and disciplinary rules for employees who violate the BCRs.108
  • Showing “external” BCR compliance requires evidence that “individuals covered by the scope of the binding corporate rules [i.e., EU data subjects] must be able to enforce compliance with the rules both via the data protection authorities and the courts.”109 A BCR applicant has to show it has made its internal dispute resolution procedures, remedies and compliance mechanisms available to aggrieved data subjects.110 Every BCR application must guarantee that EU data subjects will enjoy all their rights under the data Directive.111

The BCR application process has been streamlined a bit by the EU Article 29 Working Party’s January 10, 2007 adoption of an EU “recommendation” on Standard Application for Approval of Binding Corporate Rules, spearheaded by the International Chamber of Commerce (the same organization that helped draft the most recent, “business-friendly” model contract).112 The Standard Application contains nine sections and is designed to include all information that a DPA would require to make an approval decision on the company’s BCRs. The Standard Application is based on the BCR Article 29 Working Party documents.

In December 2005, General Electric stepped up as the first multinational to get BCRs provisionally approved by its lead DPA,113 the UK Information Commissioner’s Office, which issued that provisional approval pending the other DPAs’ positions. As of 2006, Daimler Chrysler, Philips Electronics and Accenture also were publicly discussing BCRs, as were some New York banks and US credit card companies and by 2007, the first BCR approvals were coming in, opening up this newly viable procedure that has special appeal for multinational banks.114

“Transposition” (Adoption) of the Data Directive in European States

This article has focused on the EU data Directive as a single integrated law, applicable across Europe. Indeed, here in the US, we can get too easily lured into thinking of European data law as a federalized structure emanating from Brussels. In fact, of course, the EU is not a federal system. While each member state’s data law incorporates (that is, adopts or “transposes”) the Directive, each local country’s law is unique. Consistent with the advisory nature of an EU directive (and with the EU principle of “subsidiarity”—home state rule), the member state data laws vary widely.115 While the member states’ local data laws offer data subjects at least the Directive’s core protections, some member states add extra rights. And all member states have created their own unique DPAs, compliance structures, notification processes and other bureaucratic procedures. Indeed, one member state, the UK, even created its own additional tool for transferring personal data outside the EU116

By having focused our discussion in this article on the EU data Directive as the framework for the local EU member state data laws, perhaps unfortunately, our discussion here is just a beginning for any bank that needs to ensure data law compliance across the EU Any US-based bank with branches or operations in the EU that must comply with European data protection laws will need to monitor compliance at the local level in each member state where it operates. The member states all impose their own quirky local twists on the doctrines we have discussed here. And they all have their own local data agencies with their own local enforcement practices and filing/notification requirements.117

Strategy

European union data protection law is complex and it poses special problems for any US-based multinational bank’s EU operations. A philosophical and jurisprudential gulf separates the data privacy regime of the US (which limits privacy laws that infringe on free speech) from the system in Europe (which sees personal data as equally worthy of protection as intellectual property).

Unfortunately, US-based banks and other US financial institutions operating in Europe bear a unique burden in the data law compliance scramble: Banks’ very business models more intricately involve regulated personal data than do many other businesses—deposits; withdrawals; check, credit card and ATM transactions; guarantees; securities brokerages; electronic banking and human resources operations all intimately implicate regulated personal data in the EU In addition, banks face special hurdles in transmitting personal data from Europe to the US because they are not eligible for safe harbor and (if they operate abroad via unincorporated branches) they may be foreclosed from using binding/model contractual clauses.118 As such, aggressive and creative data law compliance strategies are vital for US-based multinational financial institutions.