CFPB Tasked with FCRA Interpretation - FTC Issues Staff Report to Aid Transition

Since the Fair Credit Reporting Act (FCRA) was adopted in 1970, the Federal Trade Commission (FTC) has been the agency primarily responsible for interpreting the Act through formal rules and informal guidance materials. The Dodd-Frank Wall Street Reform and Consumer Financial Protection Act of 2010 shifted the authority to publish FCRA rules and guidelines to the newly created Consumer Financial Protection Bureau (CFPB). On July 21, 2011,to celebrate the 40th anniversary of the FCRA and aid the CFPB as it takes over interpreting the FCRA, the FTC issued a staff report entitled “Forty Years of Experience with the Fair Credit Reporting Act: An FTC Staff Report and Summary of Interpretations.” The staff report provides important insight into how the CFPB will interpret and enforce the FCRA going forward. This post summarizes some of the highlights of the staff report and the implications of the FTC’s newly issued FCRA interpretations.

Changing Opinions

This is not the first time the FTC has issued a comprehensive FCRA report. Given the large volume of guidance materials it has amassed over time, the FTC released “Commentary on the FCRA ” in 1990 – a compilation of statements regarding how the FTC would interpret and enforce the FCRA. Much has changed since the FTC issued the 1990 Commentary: the FCRA has been significantly amended, the FTC has issued numerous new interpretive guidance documents, and developments in technology and industry practices have rendered parts of the Commentary obsolete or outdated. As a result, the FTC withdrew the 1990 Commentary when it issued the new staff report. The new staff report provides an overview of the FTC’s role in enforcing and interpreting the FCRA and includes a section-by-section summary of the FTC’s interpretations of the Act. The interpretations in the staff report differ from the 1990 Commentary in five significant areas, described below.

Commercial Transactions. The FCRA applies to written, oral, or other communications of information by consumer reporting agencies (CRAs) that fit the definition of “consumer reports.” To be considered a consumer report, information communicated by a CRA must bear on a consumer’s credit worthiness, standing, or capacity, character, general reputation, personal characteristics, or mode of living. Additionally, the information must be used or expected to be used to establish the consumer’s eligibility for credit or insurance to be used primarily for personal, family, or household purposes, employment, or other purposes specifically identified in the FCRA. One point of contention has been whether and how the FCRA applies in the context of an application for business credit as opposed to personal credit. Creditors will often obtain a credit report on the sole proprietor or other principal of a business and use the report to determine whether to extend credit to the business. It was the FTC’s position in the 1990 Commentary that “a report on a consumer for credit or insurance in connection with a business operated by the consumer is not a consumer report.” Courts have held that the purpose of the FCRA “is to protect consumers from inaccurate or arbitrary information in a consumer report which is used as a factor in determining an individual's eligibility for credit, insurance or employment” and the FCRA “does not apply to reports used for business, commercial or professional purposes.” For example, in Wrigley v. Dun & Bradstreet, Inc. a commercial reporting service issued credit reports to subscribers who used the information when deciding whether to extend commercial credit to a construction company. The reports contained the personal financial information of the construction company’s president. The court held that the credit reports were for the extension of commercial credit – even though the reports contained personal credit information – therefore the FCRA did not apply.

The staff report details how the FTC currently interprets the FCRA’s application to commercial transactions. To be sure, “a report that concerns the consumer’s business history (as opposed to personal credit or employment history) that is collected and provided by a commercial reporting service solely for use in business transactions is not a ‘consumer report’” and the report provider is not a CRA. However, “a report from a CRA on the personal credit of a consumer to a business credit grantor is a ‘consumer report’ regardless of the purpose for which the information may in fact be used.” This means that reports to business credit grantors by commercial reporting services that compile data and provide reports only for commercial purposes are not “consumer reports” subject to the FCRA. On the other hand, a report on an individual based on information that was collected for the purpose of reporting on that individual is a consumer report and the FCRA applies, even if the report is furnished in connection with a commercial transaction.

Joint Users. Does an entity become a CRA by virtue of sharing a consumer report with another party? According to the FTC’s prior interpretation, a user could share a consumer report with another user without becoming a CRA under certain circumstances. An agent could share with its principal, an employee with employer, and two users could share a consumer report for the same permissible purpose with the consumer’s consent. In these scenarios, the entity sharing the report and the recipient were deemed “joint users” and the sharing entity escaped CRA status. The FTC has now abandoned the “joint user” terminology, focusing instead on whether an entity meets the statutory definition of a CRA. If a user shares a consumer report “for the purpose of providing consumer reports to third parties,” the user may be deemed a CRA. However, a user who obtains a consumer report and shares it with another simply to effectuate a particular transaction initiated by the consumer "is not providing consumer reports to third parties” and, therefore, is not a CRA.

Departments of Motor Vehicles. The FTC no longer takes the position a DMV is a CRA when it provides motor vehicle reports for insurance underwriting purposes – even if it does so for a fee. Although a DMV or other government agency that supplies public records to third parties might be considered a CRA based on a literal reading of the FCRA, the staff report notes that such an interpretation would “lead to absurd results.” If government sources of public record information were CRAs, “government agencies would be required to suppress accurate public record information more than seven years old” and “those who provide information for use in public records – such as police officers – would be deemed furnishers, subject to a host of responsibilities under the FCRA.”

Identified Information. The FTC generally considers “credit guides” – listings that rate how well consumers pay their bills – to be consumer reports subject to the FCRA. However, the FTC previously did not consider credit guides to be consumer reports if they were coded to prevent the disclosure of a consumer’s identity. The FTC now takes the position that that credit guides (as well as other information) that do not identify consumers by name may constitute consumer reports if such guides can “otherwise reasonably be linked to the consumer.” The FTC voiced its concern that coding (particularly by Social Security number or other sensitive data) could readily lead to the disclosure of a consumer’s identity due to advancements in technology and the increasing availability of consumer data.

New Interpretations

The staff report addresses several issues not covered by the 1990 Commentary in an attempt to provide clarity regarding FCRA provisions that have generated a significant number of questions from the public. Importantly, the staff report delves into detail regarding when it is permissible for CRAs to issue (and users to obtain) consumer reports under the FCRA. One permissible purpose to obtain a consumer report is “in connection with a credit transaction involving the consumer on whom the information is to be furnished and involving the … review or collection of an account of the consumer.” The staff report states that the “review” permissible purpose applies only when a creditor has an existing account relationship with a consumer and uses a consumer report solely to decide whether to modify the terms of the account. This means that even if a creditor has a permissible “review” purpose to obtain a consumer report, it may not exploit the report to market other products or services to the consumer. CRAs are also permitted to furnish a consumer report according to the written instructions of the consumer to whom the report relates. The staff report states that written consent only qualifies as an “instruction” if it clearly authorizes the issuance of a consumer report on that consumer. For example, “I authorize you to procure a consumer report on me” is sufficient if it is in writing, but the consumer’s signature on a form stating “I understand that where appropriate, credit bureau reports may be obtained” is not. The FTC highlights a consumer’s electronic signature may be an acceptable method of providing written instructions under FCRA. To be valid under the ESIGN Act, electronic authorization must be in a form that can be retained and retrieved in a perceivable form. The FTC notes “whether an e-mail, a mouse click ‘yes,’ or other electronic means clearly conveys the consumer’s instructions depends on the specific facts.”

The staff report also reflects the statutory modifications made to the FCRA over the years. Recently, the Dodd-Frank Act amended the FCRA to impose new requirements on users of consumer reports. The FCRA requires a person taking adverse action based in whole or in part on a consumer report to provide adverse-action notice to the affected consumer. Under new rules that took effect July 21, 2011, users of credit scores must include those scores (and related information) in adverse-action notices. This requirement also applies to adverse-action decisions not related to credit. Consequently, when a user takes an adverse action based on consumer report information, regardless of the weight the credit score plays in the decision, the user must provide the consumer with a host of new information. Additionally, the FCRA requires creditors to provide risk-based pricing notice to consumers when, based on the report, the creditors grant credit or amend existing credit on terms that are “materially less favorable” than the most favorable terms obtained by a substantial portion of consumers. The Federal Reserve Board and the FTC recently amended their respective adverse action and risk-based pricing rules to reflect the recent FCRA amendments. The new rules raise a host of questions, many of which are addressed in the staff report. As the new rules apply when a credit score is used in the evaluation of a consumer, the staff report squarely addresses what constitutes a credit score and when a credit score is considered “used” under the rules. The staff report clarifies that a score that is not used to predict creditworthiness, such as an insurance score, is not a credit score and need not be disclosed. The staff report also makes clear that “use” occurs at a very low threshold - if a credit score plays any role in a user’s decision regarding a consumer then it must be disclosed.

Future of FCRA Interpretation and Enforcement

The newly created CFPB is now the primary agency responsible for interpreting the FCRA. The CFPB is vested with exclusive rulemaking authority over all federal consumer financial law – this includes the authority to issue rules under existing consumer protection statutes such as the FCRA (with limited exceptions) as well as new rules to prohibit unfair, deceptive or abusive acts or practices. The primary role of the CFPB will be supervision in order to “prevent harm to consumers from unlawful financial practices and ensure that markets for consumer financial products and services are fair, transparent, and competitive.” To accomplish this, CFPB is assembling a team of examiners that will directly observe the business practices of entities subject to CFPB jurisdiction. Examiners will assess institutions’ compliance with the FCRA and other federal consumer protection laws. According to the CFPB website, the agency will require businesses to change their practices to comply with the law and may also “require improved employee training, implementation of better policies and procedures or quality controls, and in more serious cases, monetary compensation to consumers.”

Since the adoption of the FCRA, the FTC has enforced the Act at the federal level by bringing enforcement actions against CRAs, entities that furnish information to CRAs, and users of consumer reports such as creditors and employers. The CFPB and FTC now have joint FCRA enforcement authority over a host of industries. As we noted in a previous post, the FTC is actively addressing FCRA compliance and we expect its efforts to extend beyond traditional CRAs. Earlier this year the FTC found that Social Intelligence Corporation - an Internet and social media background screening service - is a CRA subject to the FCRA. Like the FTC, we expect the CFPB will broadly interpret and actively enforce the FCRA. In so doing, the CFPB may give heavy weight to the FTC’s interpretations of the FCRA, making the staff report invaluable to businesses handling consumer report information. With new FCRA rules in place and an additional agency tasked with FCRA enforcement, businesses are wise to determine whether they are subject to the FCRA and to consider FCRA compliance.

 

 

 

Is Your Organization's Red Flags Rule Identity Theft Prevention Program Ready for Primetime?

As our readers know, the FTC, after four extensions of the deadline, currently intends to begin enforcing the Red Flags Rule with respect to organizations subject to its jurisdiction on June 1, 2010. In the meantime, the Red Flags Rule remains in effect as to all financial institutions and creditors (and has been subject to enforcement by the banking regulators since November 1, 2008).  Although a recent decision of the United States District Court for the District of Columbia, ABA v. FTC, brought lawyers outside the scope of the Rule, the Rule remains broad and covers a wide range of entities as "creditors."  Creditors subject to the FTC's jurisdiction need to have their written Red Flags Rule Identity Theft Prevention Programs prepared, approved by the Board, and implemented by June 1.  For more on the history and the requirements of the Rule, see my recent article, "The FACTA Red Flags Rule: A Primer," published in Bloomberg Law Reports – Risk & Compliance, reproduced here with the permission of Bloomberg.  Read on . . .

Reminder: FTC Will Enforce Red Flags Rule Beginning November 1 (but Federal Judge Rules Lawyers Not Subject To Rule)

The Federal Trade Commission will begin enforcing its Red Flags Rule this Sunday, November 1.  Financial institutions and creditors that hold covered accounts, as defined under the Rule, must have written Red Flags identity theft prevention programs in place by November 1.   Earlier today the American Bar Association reported that a federal judge in Washington, D.C., ruled that the FTC exceeded its authority by applying the Red Flags Rule to practicing lawyers.  The FTC is expected to appeal today's ruling.

In 2007, the FTC, the federal bank regulatory agencies, and the National Credit Union Administration issued final rules requiring financial institutions and creditors to develop and implement written identity theft prevention programs, as part of the Fair and Accurate Credit Transactions Act of 2003. The FTC (but not the federal bank regulatory agencies) extended the deadline for enforcement three times:  from November 1, 2008, to May 1, 2009, to August 1, 2009, and finally to November 1, 2009.

Code or Clear? Encryption Requirements (Part 2)

In the last post, I talked about the role of encryption in fashioning a “reasonable” security plan for sensitive personal information and other protected data routinely collected, stored, and used by an enterprise. But lawmakers and regulators are getting more specific about using encryption and managing data that is risky from an ID-theft perspective. Here are some leading examples of this trend.

State Security and Breach Notification Laws

Since California adopted SB 1386, which went into effect in 2003, nearly all US states have enacted security breach notice laws that require notice to affected individuals, and in some cases to public authorities, when a party has reason to believe that the security of protected categories of personal data has been compromised. The protected categories are typically SSN (Social Security Number), driver’s license, financial account or payment card details (usually only if the password or access code is also compromised), and, increasingly, medical data not covered by federal HIPAA privacy protections.

All of these laws make an exemption from the notice obligation if the data were encrypted (some add that this is true only if there is no reason to believe that the decryption key was also compromised). The laws, and regulations adopted under the laws, typically do not specify the level or kind of encryption. For example, California’s Office of Privacy Protection published guidance specifically on the subject of “Recommended Practices on Protecting the Confidentiality of Social Security Numbers” in April 2007, which has only this to say about encryption, on page 11:
“Protect records containing SSNs, including back-ups, during storage by encrypting the numbers in electronic records or storing records in other media in locked cabinets.”

Partly as a consequence of these security and breach notice laws, organizations should limit their use and storage of these categories of personal data to the extent they are really necessary for business operations. Storage on servers or on archived media, and transmission over internal networks and VPN connections, may or may not be sufficiently secure without encryption, depending on the company’s risk assessment and IT security practices. Organizations should encrypt such data when it is resident on laptops or other portable devices and when it is in transit over the public Internet.

Massachusetts and Nevada have recently adopted stricter and more specific rules, however, that may become a model for other states. These increase the regulatory pressure for encrypting protected categories of personal data.

Massachusetts

The Massachusetts Personal Information Security Regulation (201 CMR 17.00) is now scheduled to take effect on March 1, 2010. The Regulation was promulgated by the Office of Consumer Affairs and Business Regulation (OCABR) under the authority of the Massachusetts personal information security law.

The Regulation will require all parties that “own or license” any of the protected categories of personal data concerning Massachusetts residents to encrypt the data in laptops or other portable devices, as well as in wireless transmissions and in transmission over public networks.

Note that the Regulation does not limit its coverage of financial account data to cases where the access code or PIN is compromised, as do most security and breach notice laws. The Regulation extends to any nonpublic financial account or payment card data, as well as to SSNs and driver’s license numbers. The Regulation does not cover medical information, however.

The Regulation mandates a number of “Computer System Security Requirements” (201 CMR sec. 17.04) for businesses that handle the protected categories of personal data. These expressly include the following:

“(3) Encryption of all transmitted records and files containing personal information that will travel across public networks, and encryption of all data containing personal information to be transmitted wirelessly . . .

(5) Encryption of all personal information stored on laptops or other portable devices . . .”

The level and type of encryption are not specified.

Nevada

Nevada recently amended its personal information security law, which already required “reasonable” security measures as well as breach notice (Nevada Rev. Stats. secs. 603A.010 et seq.). The amendments take effect on January 1, 2010.

The law covers SSNs, driver’s license numbers, and payment card or financial account data in combination with an access code or PIN. Medical information is not covered.

Under the amended law, businesses that accept payment cards (credit cards and debit cards) must comply with the Payment Card Industry Digital Security Standard (PCI DSS). In addition, a party handling any of the protected categories of information must encrypt the data if it transfers the data electronically “outside of the secure system of the data collector” or if the data is stored on a device (laptop, USB drive, etc.) that is moved “beyond the logical or physical controls of the data collector or its data storage contractor.”

“Encryption” is defined in the amendments with reference to “established standards,” specifically including FIPS and mentioning the need for standards-based key management as well as encryption protocols:

‘Encryption’ means the protection of data in electronic or optical form, in storage or in transit, using:

(1) An encryption technology that has been adopted by an established standards setting body, including, but not limited to, the Federal Information Processing Standards issued by the National Institute of Standards and Technology, which renders such data indecipherable in the absence of associated cryptographic keys necessary to enable decryption of such data; and

(2) Appropriate management and safeguards of cryptographic keys to protect the integrity of the encryption using guidelines promulgated by an established standards setting body, including, but not limited to, the National Institute of Standards and Technology.”

Thus, while the law itself does not specify the form of encryption, it puts the burden on the user to choose an appropriate and standards-based method.

HITECH

Title XIII of ARRA, the federal economic recovery legislation adopted early in 2009, is labeled the Health Information Technology for Economic and Clinical Health Act (HITECH). It amends the HIPAA medical privacy provisions by adding a federal security breach notice requirement for nonpublic, personally identifiable health information. While HIPAA applies only to certain covered entities (healthcare providers and insurance companies and clearinghouses), HITECH also applies to “business associates” that provide services to those entities. HITECH reaches as well any employers that are covered by HIPAA because, for example, they operate company clinics or manage their own health plans.

HITECH requires notice to affected individuals when there has been a security breach exposing personally identifiable health data. HIPAA already lists 18 identifiers (names, addresses, SSNs, health plan ID numbers, etc.) that must be removed to establish that health records have been “de-identified.” Where compromised records have not been fully de-identified by removing these data fields, HITECH sec. 132400 also recognizes that the information may not be personally identifiable if it is effectively encrypted:

“(b) Implementation specifications: Requirements for de-identification of protected health information. A covered entity may determine that health information is not individually identifiable health information only if:

(1) A person with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods for rendering information not individually identifiable:

(i) Applying such principles and methods, determines that the risk is very small that the information could be used, alone or in combination with other reasonably available information, by an anticipated recipient to identify an individual who is a subject of the information; and (ii) Documents the methods and results of the analysis that justify such determination; . . . .”

Thus, HITECH does not specify a particular form of encryption but leaves it to IT security experts to decide whether the data are effectively unidentifiable in the hands of an unauthorized user. Note that the statute requires covered entities to maintain documentation of this professional analysis, and that the analysis must be based on “generally accepted” principles and methods – which means that professional opinions are likely to refer to published specifications and industry standards.

Red Flags

The 2007 Identity Theft Red Flags Rule (promulgated under the 2003 FACTA amendments to the federal Fair Credit Reporting Act) went into effect in November 2008, although the FTC suspended enforcement until November 1, 2009. (Similar rules were issued by the federal financial regulatory agencies, for the institutions they supervise.) The Rule requires covered entities to develop and implement written policies to prevent identity theft, including recognition of warning signs or “red flags” of suspected ID theft.

The Rule applies not only to traditional financial institutions but to “creditors,” defined as companies that “regularly defer payment for goods or services,” whether or not charging interest or finance charges, and therefore store personal information about individual debtors. Some employers, for example, sell goods or services to employees on deferred payment terms and may be treated as covered entities for that reason. (However, the Red Flag FAQs written by FTC staff take the view that an employer is not a covered entity simply because it sponsors a 401k or other qualified retirement plan that allows participants to borrow from their retirement funds.)
For covered entities, the mandatory policy to prevent ID theft must identify signs of possible security breaches involving certain data, as well as appropriate responses to those alerts. The covered data are SSNs and tax identification numbers, healthcare IDs, financial account and credit/debit card details, personally identifiable medical information, and identifying data from consumer reports (which are often used for employee background checks as well as for credit applications).
The Rule itself does not mandate encryption measures. However, most covered entities will necessarily address encryption in their written anti-ID theft policies. Their “red flags” should also include an alert if there is evidence that encryption keys have been misused, stolen, or hacked.