CCBD Sole-Source PWS.pdf

PERFORMANCE WORK STATEMENT

III.1 INTRODUCTION

The Office of the Comptroller of the Currency (“OCC”) charters, regulates, and supervises all national banks and federal thrifts. It also supervises the federal branches and agencies of foreign banks. One of the primary missions of Supervision Research and Analysis (SRA) within the OCC is to deliver economic and quantitative analysis to policymakers and bank examiners. SRA supports on-site and off-site supervision of banks, provides current economic analysis, supports policy development, and conducts original research to support the OCC mission of ensuring a safe and sound national banking system.

III.1.1 Background

The OCC has a requirement to procure Comprehensive Consumer Credit Bureau data and Alternative Credit data to enable the agency to complete a variety of research projects and tasks pertinent to bank supervision and policy. Such research and tasks enable the agency to not only exhibit leadership in the domestic and global financial regulatory environments to promote the global stability of financial services but also to sustain an enterprise pipeline of talented, skilled, experienced, and diverse employees.

III.1.2 Scope of Work

The Contractor must provide Comprehensive Consumer Credit Bureau Data. The data must contain two types of mergeable credit data: traditional credit data from a Nationwide Consumer Reporting Agency1 (e.g., Equifax, Experian, TransUnion) and “alternative” credit data (FCRA2-compliant credit data that is not typically included in traditional credit reports and predominantly covers low-income and/or non-prime consumers3).

III.1.3 Definitions The following definitions will be referenced through the rest of this document:

• (i) Traditional Credit Bureau Database: all records in the Contractor’s nationwide traditional consumer credit database that were included in the month- or quarter-end snapshot of the relevant

1 As defined and listed by Consumer Financial Protection Bureau (CFPB), contemporaneously found at:

https://files.consumerfinance.gov/f/documents/cfpb_consumer-reporting-companies-list.pdf 2 FCRA – Fair Credit Reporting Act, contemporaneously found at: https://www.ftc.gov/enforcement/statutes/fair-credit-reporting-act 3 CFPB defines it as “Low Income and Subprime” consumer market segment, contemporaneously found at:

https://files.consumerfinance.gov/f/documents/cfpb_consumer-reporting-companies-list.pdf.

data period,4 whether or not the records had tradelines and whether or not they were scoreable.5 Buy-now-pay-later (BNPL) tradelines have recently begun systematic collection and the OCC considers BNPL tradelines to be elements of the Traditional Credit Bureau Database. As such, the Contractor must choose a snapshot date prior to July 1, 2022, as of which BNPL tradelines are to be considered a fully-integrated part of the Traditional Credit Bureau Database. After this snapshot date, BNPL tradelines must be included in the data provided by the Contractor in the same manner as other tradelines (e.g., credit card, mortgages, etc.)

• (ii) Traditional Core Data: a longitudinal data sample that is representative of the entire Traditional Credit Bureau Database

• (iii) Base Year Traditional Core Data: initial sample of the Traditional Core Data, obtained by random sampling of consumer-level records from the Traditional Credit Bureau Database;6 includes consumer-level and loan-level (tradeline-level) data for the consumers included in the sample

• (iv) Updates to the Traditional Core Data: consist of (i) updated features of the records (and their associated tradelines) that were included in the Base Year Traditional Core Data or that were added as part of previous Updates (other than those no longer present in the Traditional Credit Bureau Database at the time of the Update), as well as (ii) the features of a random sample of records (and their associated tradelines) that have been newly-added to the Traditional Credit Bureau Database in the update period.7

• (v) Alternative Credit Database: all records in the Contractor’s alternative credit database that were included in the month- or quarter-end snapshot of the relevant data period,8 whether or not the records had tradelines and whether or not they were scoreable. As noted above, the Alternative Credit Database is the universe of credit data not typically included in traditional credit reports. For sampling purposes, consumers who have only non-credit forms of alternative data (e.g., rent payments, payroll information, utility data, or telecommunications data) are not considered part of the Alternative Credit Database.

• (vi) Alternative Core Data: longitudinal sample data representative of the entire Alternative Credit Database

• (vii) Base Year Alternative Core Data: initial sample of the Alternative Core Data, obtained by random sampling of consumer-level records from the Alternative Credit Database includes consumer-level and, ideally, loan-level (tradeline-level) data for the consumers included in the sample9

• (viii) Updates to the Alternative Core Data: consist of (i) updated features of records (and

4 For quarterly frequency options, each data year contains four snapshot dates: September 30th, December 31st, and March 31st and June 30th. For monthly frequency options, the snapshot dates are the final day of each month with the final snapshot date of the data year being June 30th. Specific snapshot dates for periodic updates are negotiable if Sample Design B is chosen (see Section III.2.4.2), as long as the relevant dates are at a monthly or quarterly pace, as required.

5 A “record” is considered the same as a “case” or “file.” The terms refer to data at the level of the “consumer” or “individual.” The precise definition of the data universe, here, can change slightly if Sample Design B is chosen (see Section III.2.4).

6 Or as defined in Section III.2.4 and its subsections if Sample Design B is chosen by the Contractor.

7 We call these records “newly-opened” Traditional Credit Bureau Database files. Specifically, a consumer’s file is considered “newly-opened” for this purpose when they have a Traditional Credit Bureau Database file for a given year but have not had a Traditional Credit Bureau Database file in any prior data year covered by this contract.

8 For quarterly frequency options, each data year contains four snapshot dates: September 30th, December 31st, and March 31st and June 30th. For monthly frequency options, the snapshot dates are the final day of each month with the final snapshot date of the data year being June 30th. Specific snapshot dates for periodic updates are negotiable if Sample Design B is chosen (see Section III.2.4.2), as long as the relevant dates are at a monthly or quarterly pace, as required.

9 See section III.4 and its subsections for additional information about our alternative data requirements.

associated tradelines) included in the Base Year Alternative Core Data or added as part of previous Updates (other than those no longer present in the Alternative Credit Database at the time of the Update), as well as (ii) the features of a random sample of records (and their associated tradelines) that have been newly-added to the Alternative Credit Bureau Database in the update year.10

• (ix) Alternative Core Data Complement (to the Traditional Core Data): For a given data period,11 these data shall contain, for all consumers present in the Traditional Core Data in that data period, a collection of the consumer-level records (and associated tradelines) retrieved from the Alternative Credit Database for each of those consumers in that same data period (if such records exist).12

• (x) Traditional Core Data Complement (to the Alternative Core Data): For a given data period,13 this data shall contain, for all consumers present in the Alternative Core Data in that data period, a collection of the consumer-level records (and associated tradelines) retrieved from the Traditional Credit Bureau Database for each of those consumers in that same data period (if such records exist).14

• (xi) Complementary Core Data: the aforementioned complementary datasets, as defined by (ix) and (x)

• (xii) Core Data: all aforementioned Core Data, as defined by (ii), (vi), (ix) and (x)

• (xiii) Optional Data: any other Data acquired as part of this procurement that fall outside of the

Core Data

• (xiv) Acquired Data: The entirety of the data acquired as part of this procurement.

• (xv) Buy-Now-Pay-Later (BNPL) Data: BNPL data is a subset of the Traditional Credit Bureau

Database, as noted in (i) Though there is no all-encompassing definition of BNPL products, BNPL products are distinct from both traditional small installment loans and credit card loans, and they generally share the following characteristics: BNPL products are structured as installment loans with a down payment due at sale and a fixed repayment schedule (e.g., “Pay-In-Four” with weekly/bi-weekly payments for short 0% interest loans; monthly payments for low interest longer-term loans); BNPL loans are offered through retailers, at the point-of-sale, and are tied to the purchase of a particular product; and, BNPL companies often offer easier lending terms, with no or limited credit checks. Most Buy Now, Pay Later loans range from $50 to $1,000, but may be larger. Any considerable difference between the aforementioned characteristics of BNPL products and those provided to OCC by the Contractor must be approved by OCC on a case-by-case basis.

OCC’s contracting officer (with advisement from his/her COR) shall be the sole arbiter of what constitutes a considerable difference.

III.2 OVERARCHING COMPREHENSIVE REQUIREMENTS

This section provides an overview of data, documentation, updates, and sampling design requirements for both traditional and alternative credit data.

10 We call these records “newly-opened” Alternative Credit Database files. Specifically, a consumer’s file is considered “newly-opened” for this purpose when they have an Alternative Credit Database file in a given year but have not had an Alternative Credit Database file in any prior data year covered by this contract.

11 “Data period” for this purpose means either quarterly or monthly periods, whichever matches the selected update frequency of the Traditional Core Data.

12 The intent, here, is to require the Contractor to check the Alternative Credit Database for any data on the consumers who appear in the Traditional Core Data and to provide that data if they find any there. This data should be provided at the same update frequency as the Traditional Core Data.

13 “Data period” for this purpose means either quarterly or monthly periods, whichever matches the selected update frequency for the Alternative Core Data.

14 Again, the intent here is to require the Contractor to check the Traditional Credit Bureau Database for any data on the consumers who appear in the Alternative Core Data and to provide that data if they find any there. This data must be provided at the same update frequency as the Alternative Core Data.

III.2.1 Overarching Comprehensive Credit Data Requirements

1. The OCC requires data with limited rights in perpetuity with limits as described in this section (III.2.1). The OCC shall be licensed to use data internally and publish or share aggregate results externally.

2. The Contractor must provide the OCC the following data usage rights:

a. The right to merge the Acquired Data with data and information from other sources and create derivative products;15

b. The right to retain the data for use in research and analysis;

c. The right to publish/present the Acquired Data; and

d. The right to post research papers with aggregated Acquired Data.

3. The Contractor must deliver contract base year traditional and contract base year alternative Core Data.

4. The Contractor must deliver regular updates to the traditional and alternative core data at the specified frequency for the life of the contract. Updates must be mergeable to the base-year core data and updates previously provided by the Contractor under this contract (e.g., consumer identifiers and tradeline identifiers should be consistent across time).

5. The Contractor must deliver the following data in a format ensuring filenames and included indicators clearly establish which of these components the Contractor aims to satisfy with the data delivery:16

a. Traditional Core Data (and its Updates),

b. Alternative Core Data (and its Updates),

c. Alternative Core Data Complement (to the Traditional Core Data) (and its

Updates),

d. Traditional Core Data Complement (to the Alternative Core Data) (and its

Updates)

6. Provide anonymized identifiers that universally and uniquely identify consumers across all Core and Optional (if applicable) data (making it possible for the OCC to, for example, merge the Complimentary Core Data to their corresponding Core Data); this consumer identifier should be consistent for each consumer, across time. Alternatively, the Contractor will provide a crosswalk that matches each consumer’s anonymized identifier found in Core Data to his/her corresponding anonymized identifier in the Complimentary Core Data; in this case the identifiers would be consistent across time and unique within each data type (i.e., unique within the Traditional Core and Complement (to Alternative) Data and unique within the Alternative Core and Complement (to Traditional) Data).

7. Provide, similarly to consumer identifiers, a unique identifier for each tradeline that is consistent across time and unique at least within each data type.

8. As an optional task related to Paragraph 7 of Section III.2.1. (the immediately preceding paragraph), if a single tradeline is reported in both the traditional data and the alternative data, and if the tradeline identifier is not the same for that tradeline in the traditional and

15 The OCC will not attempt to merge the data in a way that risks de-anonymization of consumers, lenders, servicers, or other anonymized data.

16 The OCC is flexible in exactly how the data is formatted and delivered; however, the OCC reserves the right to require the format to be changed by the contractor if it cannot identify which subsets of the data provided satisfy each of the required samples/updates. For example, Updates to the Traditional Core Data and Updates to the Traditional Core Data Complement to the Alternative Core Data may be combined if there is an indicator flag noting which consumers/records belong to which sample.

the alternative data, the Contractor must identify tradelines the bureau considers likely to be duplicates across the traditional and alternative data and provide a unique identifier for every such pair of duplicates. This task must only be performed if the associated optional contract line item is awarded and exercised at the time of contract award or by modification to the contract.

9. The data delivered to the OCC must not contain name, street address, and/or social security number. The OCC reserves the right to have the Contractor resubmit work that contains this information as determined by the COR/CO; therefore, the Contractor is encouraged to work with the COR to ensure the data to be delivered will not contain name, street address, and/or social security number prior to compilation.

III.2.2 Comprehensive Credit Data Required Documentation

The contractor must provide:

1. Data dictionaries, updated whenever a provided variable changes definition.

2. Methodology for computed/derived statistics (OCC is willing to sign a non-disclosure agreement regarding this information if necessary).

3. Release notes and/or documentation of any changes to the information gathered or to the data structure.

4. A document that explicitly identifies any third-party data subject to additional license and/or usage constraints.

III.2.3 Comprehensive Credit Data Updates

Annual Updates to Ensure National Representativeness. In each data-year, in order to maintain the representativeness of the OCC data relative to the cross-section of consumers in credit databases, the Contractor must add a sample of new entrants to the (non- Complementary) Core Data consistent with their definitions in Section III.1.2.17 The rate at which the newly-opened consumer-level records must be sampled by the Contractor from the traditional credit bureau database to produce an update to the traditional core data is the same sampling rate used to draw the base-year traditional core data from the traditional credit bureau database.18 Similarly, the rate at which the newly-opened consumer-level records should be sampled from the Alternative Credit Database to produce an Update to the Alternative Core Data is the same sampling rate used to draw the Base Year Alternative Core Data from the Alternative Credit Database. After newly-opened consumer-level records are added to the (non-Complementary) Core Data (both Traditional and Alternative separately), the corresponding records from the Complementary Credit Databases must also be added to the Complementary Core Data as part of the Update for the relevant data year.

17 Note that sampling newly-opened accounts and incorporating them into the Updates may occur on an annual basis, while each intermediate (quarterly or monthly) update is only required to provide the latest data for individuals already in the data panel. The Contractor may choose to sample and incorporate newly-opened accounts on a quarterly or monthly basis if the Contractor prefers to do so.

18 If Sample Design B is chosen, the Contractor may utilize a different method to ensure representativeness.

III.2.4 Comprehensive Credit Data Sampling Plan

To the maximum extent practicable, the comprehensive credit data panel must be nationally representative of American consumers with traditional and/or alternative credit database information.

To this end, the Contractor must meet the following requirements:

1. The Contractor must use a simple random sampling (SRS) scheme to build the Base-Year Core Data sets.19 Specifically, if Sample Design A is chosen the Contractor must employ a method involving random numbers, not systematic sampling.20 The Contractor must randomly sample credit records (consumers), not proxies for those records.

a. The Contractor must apply this scheme to the Traditional Credit Bureau Database to build the Base Year Traditional Core Data sample.21 The Contractor must also independently apply it to the Alternative Credit Database to build the Base Year Alternative Data sample; the intent is not to construct a single sample from the universe of consumers who appear in the Traditional Credit Bureau Database or the Alternative Credit Database, but instead to construct one random sample from consumers in the Traditional Credit Bureau Database and another independently drawn random sample from consumers in the Alternative Credit Database. Note that this sampling methodology allows for some consumers to be randomly selected for inclusion in both the Base Year Alternative Core Data and in the contemporaneous Traditional Core Data. The Contractor must provide an indicator variable that flags consumers for whom this is the case.

2. If Sample Design B is selected (Section III.2.4 and its subsections), in lieu of the SRS sampling method, the sampling methodology must be approved in advance by the COR. The Contractor must meet the sample size requirements for the Core Data in Sections III.3.3 and III.4.3 (as applicable).

3. The Contractor must use one of the Sample Designs described in Section III.2.4 and its subsections to build the Core Data.

4. All Updates to the Core Data must build upon and extend the panel started in the Base Year Core Data. Specifically, all Updates shall contain detailed credit bureau data, identifiers, and other features (as described in Sections III.2.1, III.3.5, and III.4.5, as applicable), as of each periodic snapshot date.22

a. At least once each year, a proportion of newly-opened Traditional Credit Bureau Database consumer files must be randomly selected for inclusion in the Update to the Traditional Core Data by the Contractor. Similarly, a proportion of newly-

19 This does not apply for the Base Year Traditional Core Data set if Sample Design B is chosen; see Section III.2.4 and its subsections for the details of the applicable sampling method. Note that the Complementary Data sets are not formed using random sampling. They are generated by assembling the information that is contemporaneously available in the Traditional or Alternative Database for the consumers selected for inclusion in the (non- Complementary) Core Data sets.

20 See Section III.2.4.2 for additional information.

21 Except if Sample Design B is chosen, see Section III.2.4 and its subsections for details.

22 Monthly or quarterly, depending on update frequency selected. Note that newly-opened consumer records may be added to the panel on an annual basis, rather than at each monthly/quarterly update (as described immediately below).

opened Alternative Credit Database consumer files must be randomly selected for inclusion in the Update to the Alternative Core Data set by the Contractor. Adding these consumers with newly-opened accounts to each panel ensures that they stay nationally-representative over time. Note that this sampling methodology allows the same consumer to be randomly selected for inclusion in the Update to the Alternative Core Data and be selected/present in the contemporaneous Traditional Core Data. The Contractor must provide an indicator variable that flags consumers for whom this is the case.

b. OCC staff will compare summary statistics of the proposed sample of newly-opened consumer files to be delivered with each Update against summary statistics on newly-opened consumer files in the Contractor’s Traditional or Alternative Credit Database and determine whether the sample is sufficiently representative of the population in the Databases.23 If the sample is not representative, the Contractor must randomly draw the sample of newly-opened consumer files again and provide the corresponding statistics described in Section III.2.4.4. This process will continue iteratively until the COR notifies the Contractor the OCC is satisfied that the sample of newly-opened consumer files is representative.24

5. The Contractor must use one of the two sample designs below (Sample Design A or Sample Design B). Once a sample design is selected, it cannot be changed without the consent of the OCC.

III.2.4.1 Sample Design A

Sample Design A, the Contractor shall use 2019 as the Base Year for constructing the Base Year Core Data samples, unless the Traditional or Alternative Data Historical Records options are chosen.25 Sample construction shall be as described in Section III.2.4.

III.2.4.2 Sample Design B

Sample Design B, if the Contractor chooses to offer an off-the-shelf data product (e.g., Analytical Dataset, Analytical Sandbox, Prama, etc.) to satisfy some or all of the requirements in this PWS, the specific sampling methodology for the Base Year Traditional Core Data and/or Base Year Alternative Core Data is determined by the Contractor, but the sample selection and updating methodologies must be approved in advance by the COR.

III.2.4.4 Core Data Set Development

The Contractor must provide the following as a part of developing the Core Data:

23 The OCC will primarily use the information provided under Section III.2.4.4 to make this determination. The Contractor can (optionally) also provide quality control documentation that illustrates the representativeness of the update samples.

24 Note that the intent of this process is simply to ensure that the new entrants are appropriately drawn and to check data-integrity.

25 If any of the historical records options are chosen, the base year must be set earlier than 2019 as described in Sections III.3.4 and III.4.4

1. Credit Database Features: Before the Contractor delivers the Core Data, it must provide the OCC with the following data (separately for the Traditional and Alternative Credit Databases) describing each database as of June 30, 2019:

a. The name, snapshot dates, and description of the Credit Database;

b. The total number of records and the total number of scoreable records in the Credit

Database; and

c. The total number of records in the Credit Database by credit score value, date of birth

(month and year), and state of residency;26 For each Update to the Core Data Sets, the Contractor shall provide the above information for the Traditional and Alternative Credit Databases as well the same statistics for the portion of each of those databases that consists of newly-opened records as of the snapshot date for each Update.27 For each Update, the Contractor shall also provide the number of attrition records (i.e., those records that are not present in a database for this Update’s data period but which were present in the same database for the previous Update’s data period).

2. Credit Balance Statistics: After calculating the sum of all tradeline credit balances associated with each credit record in the Contractor’s Credit Bureau Databases (again, separately for traditional and alternative databases), the Contractor must provide the OCC with the mean and standard deviation of these sums for:

a. All credit tradelines; and

b. Each major category of credit (e.g., mortgage, installment, revolving, and unsecured personal loans for traditional bureau data; likewise, for any relevant categories for the alternative credit data).28

c. (Optional task) The above summary statistics must be reported separately for banks and non-banks (for Traditional data only).

d. (Optional task) If the FICO score option described in Section III.3.5.3 is exercised, the Contractor must additionally provide the total number of records by FICO score value (or within narrow score bands, up to 5 points wide) as well as the mean and standard deviation of FICO scores.

e. (Optional task) If the lender type variable option described in Section III.3.5.3 is exercised, the above summary statistics must also be reported for each lender category (for Traditional data only).

3. The Core Data: The Contractor must use the SRS sampling method to produce Traditional and

Alternative Core Data that adhere to the requirements described in Sections III.2.1, III.2.4, III.3.3, III.3.5, III.4.3, and III.4.5 (as applicable). If Sample Design B is selected, in lieu of the SRS sampling method, the sampling methodology must be approved in advance by the COR.

The result is the Core Data.

III.3 Traditional Credit Data

This section discusses the type of data to be included in the traditional core data, the update frequency, the required sample size, historical records, and features.

III.3.1 Traditional Credit Data Scope/Definition

26 In this document, the term “state of residency” refers to the 50 U.S. states; Washington, D.C.; U.S. territories;

overseas military areas; etc.

27 Or of the snapshot date for each Update if the Contractor chooses to add newly-opened accounts more frequently.

28 The exact categories reported must be approved by the OCC.

The traditional credit data shall be sourced from data that widely represents American individuals who either (i) borrow or have borrowed via a bank-offered product, such as credit cards, auto loans, mortgages, etc. (irrespective of whether it was supplied by a bank or a non-bank financial institution), and/or (ii) have inquired about such credit products, and/or (iii) have a public debt record (e.g., collection or bankruptcy).

For the individuals covered by the traditional credit data, the data shall contain (i) information on the characteristics of the aforementioned credit products and their performance, (ii) information on the credit inquiries for such products, and (iii) public debt record information. Pre-aggregated data (e.g., the number of loans of a given type for a given consumer), sometimes called “attribute” data, is insufficient; the Contractor must provide characteristics for each tradeline, inquiry, and/or debt record for each consumer.

Additionally, loan performance information must be provided for each tradeline. The universe of traditional credit data must include buy-now-pay-later transactions for snapshot dates after this data began being systematically collected by the Contractor (or a bureau associated with the Contractor).29

III.3.2 Traditional Data Updates

• The Contractor must provide Updates to the Traditional Core Data and Updates to the Traditional

Core Data Complement to the Alternative Core Data on a quarterly basis. These updates must be based on snapshot dates at the end of each quarter and be provided to the OCC in a timely manner.

Note that the sample of newly-opened accounts need only be drawn and added once per year.

o (Optional task to be performed only if exercised by OCC) The Contractor must provide monthly updates in the same manner as described for quarterly updates, but with a snapshot date at the end of each month. Note that the sample of newly-opened accounts need only be drawn and added once per year.

III.3.3 Sample Size of the (Traditional) Core Data

• The Contractor must provide a sample of at least 7.89 million customers (or 2.5% of the Traditional

Credit Bureau Database, whichever is greater) from the Traditional Credit Database for the Base Year drawn using the relevant Sample Design A or B, described above.

III.3.4 Traditional Data Historical Records

• (Optional Task) The Contractor must provide Traditional Core Data going back at least two additional years.30 These data should be updated at the same frequency (quarterly or monthly) as future Updates.31

• (Optional Task) The Contractor must provide Traditional Core Data going back at least four

29 No later than snapshot date June 30, 2022. If buy-now-pay-later tradelines are not included in the Base Year Traditional Credit Bureau Database, these tradelines will begin to appear in the Updates to the Traditional Core Data and in the Traditional Core Data Complement (to the Alternative Core Data) via two means. Once the buy-now-pay-later tradelines are incorporated into the Traditional Credit Bureau Database, those tradelines will appear alongside the other tradelines for consumers who are already in the sample and consumers who only have buy-now-pay-later tradelines will begin to enter the sample through the (at least) annual process of sampling newly-opened accounts.

30 This option pushes the Base Year back two years, to 2017 rather than 2019. The Base Year Traditional Core Data would be drawn from 2017, and each year of data thereafter would receive Updates to the Traditional Core Data to maintain the national-representativeness of the sample.

31 See Section III.3.2.

additional years.32 These data should be updated at the same frequency (quarterly or monthly) as future Updates.33

III.3.5 Traditional Data Record Required Features

The data provided by the Contractor for the Base Year Traditional Core Data, the Updates to the Traditional Core Data, and Traditional Core Data Complements (to the Alternative Core Data) must contain the information contained in Section III.3.5 and its subsections.

III.3.5.1 Records

• Consumer record identifier: The Contractor must assign a unique, time-invariant, anonymized identifier to each record (consumer), to enable OCC staff to track individual records over time. All data files must include this anonymized consumer record identifier; this will allow the OCC to link the information from the traditional and alternative credit files (as well as inquiry, bankruptcy, and other files) back to the relevant consumer.

• Updates: For every update frequency (quarter or month), the Contractor must provide then-current information for each record of the data and any record that has been added to it.

• Minimum required record features: The Contractor must minimally provide a record identifier (unique ID), database snapshot date (the date as of which the data for that record was recorded), credit score information (as of the snapshot date),34 and basic demographic information (including geographic information about the consumer’s residence and information related to the consumer’s date of birth). The precise configuration of this information must be approved by the OCC.

III.3.5.2 Record Features In each case, the Contractor must provide data on the fundamental features of every tradeline, as well as information on inquiries and debt/collections associated with each consumer credit record in the sample.

Fundamental features are those features that are irreducible and cannot be computed from the data on other features that the Contractor provides. Examples include account status, account type, ECOA code, highest credit amount, term at origination, and various tradeline dates. We do not require, and fundamental features do not include, the number of tradelines per record, the number of tradelines 90 days past due over the past 12 months, or similar measures that are computed or aggregated from the fundamental features (these statistics are sometimes referred to as “attributes”).

• Tradeline-level data o The Contractor must provide an anonymized unique identifier for each tradeline that will allow OCC staff to track individual credit tradelines over time. The Contractor must make

32 This option pushes the Base Year back four years, to 2015 rather than 2019. The Base Year Traditional Core Data would be drawn from 2015, and each year of data thereafter would receive Updates to the Traditional Core Data to maintain the national-representativeness of the sample.

33 See Section III.3.2.

34 Credit score information here refers to scores that the traditional bureau can provide, such as a bureau-specific risk score and/or Vantage score. FICO score is a separate, optional task requirement.

a reasonable effort to provide an identifier that will link tradelines across any change in account number (e.g., for lost or stolen credit cards) or across any change in the reporting institution.

o The Contractor must provide data on the fundamental features of every tradeline associated with every (consumer-level) record delivered to the OCC. Fundamental features are tradeline features that are irreducible and cannot be computed from the data on other tradeline features the Contractor provides.

o Reporting date on the tradeline is a required feature. While most variables are expected to be point-in-time observations (as of the reporting date that precedes and is closest in time to the database snapshot date), the Contractor must also provide a string of data recording the monthly loan statuses (i.e., current, 30–59 days past due, …, 120+ days past due, collection account, repossession, included in bankruptcy, charge-off) of the trade over (at least) the preceding 24 months.35 The 24 month duration for the trailing period is a minimum and the Contractor may offer to provide a longer duration.

o Similar to the requirement for anonymized consumer identifiers, the institution reporting on the tradeline to the bureau (e.g., loan servicer) must be conveyed using an identifier.

This identifier must be unique and time-invariant. It may be anonymized but must be provided along with an industry code. The contents of this code must be consistent with industry practice.36

III.3.5.3 Record Options

a. (Optional task to be performed only if exercised by OCC) The Contractor must provide trended data that is derived from multiple point-in-time observations.

b. (Optional task to be performed only if exercised by OCC) The Contractor must provide FICO credit score for each consumer.

c. (Optional task to be performed only if exercised by OCC) The Contractor must provide FICO Resilience Index Data. For each consumer in the Core Data Set, the OCC shall receive FICO Resilience Index (“FRI”) data consisting of:

a. (a) for every FRI-scoreable record, an FRI Score and up to five FRI Reason Indicators, or

b. (b) for records that are not FRI-scoreable, an Exclusion code explaining why the record was not FRI-scoreable.

d. (Optional task to be performed only if exercised by OCC) The Contractor must provide an MPL/fintech flag. This will indicate that the reporting institution can be tied to originations by a

35 Assuming 24-month coverage, this variable must be a string variable consisting of 24 characters. Each alphanumeric character shall indicate the status of the tradeline in each of the 24 months preceding the reporting date (current, 30- 59 days past due, …, 120+ days past due, collection account, repossession, included in bankruptcy, charge-off, etc., and these codes must be approved by the OCC). The first character in the string must represent the most-recent month’s status (closest to the snapshot date) and the last character must represent the least-recent month’s status. If the loan is less than 24 months old, the last few characters in this string may be blank (because the loan did not yet exist, so it has no status associated with its performance).

36 It is the OCC’s observation that there are standard industry codes (e.g., bank, credit union, lumber yards, farm implements dealers, etc.) contemporaneously used by the major credit bureaus. OCC will provide a list of these codes to the Contractor, upon request.

marketplace lender and/or a fintech firm; the Contractor must provide a description of what types of lenders qualify for inclusion in this flag or provide a complete list of included lenders.37

e. (Optional task to be performed only if exercised by OCC) The Contractor must provide a variable that notes the type of lender for each tradeline that includes institutional designations (e.g., bank, non-bank financial institution, fintech firm, GSE). The list of institutions included in each category or the criteria for assigning lenders to each category must be approved by the OCC. The Contractor must provide a list of the lenders that are categorized as each type. The number of firms in each lender type category must be large enough to ensure that individual firms remain anonymous;

omitting or combining lender types for this purpose is permissible.

f. (Optional task to be performed only if exercised by OCC) The Contractor must provide “attribute” data containing information aggregated at the consumer level (e.g., number of satisfactory trades within 3 months). If this optional task is exercised, the Contractor must provide the method by which each provided attribute is calculated.

g. (Optional task to be performed only if exercised by OCC) The Contractor must provide detailed data on Inquiry, Bankruptcy and Collections as described below:

a. Inquiry data. Each inquiry entry must include:

1. a unique anonymized identifier for the inquiry, the aforementioned unique and time-invariant anonymized identifier of the consumer

2. a unique identifier for the reporting institution; the OCC prefers this to be non-anonymized, but is willing to accept an anonymized identifier for reporting institution

3. the fundamental features of the inquiry (including inquiry date)

b. Collection data. Each collection entry must include:

1. a unique anonymized identifier for the collection, the aforementioned unique and time-invariant anonymized identifier of the consumer, along with a unique and time-invariant identifier of the reporting institution (e.g., collection agency); the OCC prefers this to be non-anonymized, but is willing to accept an anonymized identifier for reporting institution

2. the fundamental features of the collection (including reporting date and date of assignment)

c. Bankruptcy data. Each bankruptcy entry must include:

1. A unique anonymized identifier for the bankruptcy, the aforementioned unique and time-invariant anonymized identifier of the consumer, along with a unique and time-invariant identifier of the reporting institution (e.g., court); the OCC prefers this to be non-anonymized, but is willing to accept an anonymized identifier for reporting institution

37 OCC acknowledges that the fintech landscape is rapidly evolving. The definition of MPL/fintech must be approved by the OCC prior to use, but should generally include non-depository institutions for which the primary customer interaction mechanism is online or via a mobile app.

2. The fundamental features of the bankruptcy (including reporting date, date of filing, and date of verification).

III.4 ALTERNATIVE CREDIT DATA

This section discusses the type of data the Contractor must include in the alternative credit data and the required sample size of the core data, historical records, and features.

III.4.1 Alternative Credit Data Scope/Definition The Contractor must provide credit data that is not typically included in traditional credit reports, primarily including data provided by and to suppliers of alternative credit product/services, which are predominantly demanded by low-income and/or non-prime consumers. These may include, but are not limited to alternative financial service data that are collected and provided to short-term (payday) lenders, nonprime installment lenders, and other credit providers.38 The Contractor may also provide non-credit data from other sources, such as rental payments, asset ownership, phone and/or utility payments, and consumer-permissioned data—these data may be provided in addition to the credit data described above, but are not required and are not to be considered part of the Alternative Credit Database.

III.4.2 Alternative Data Updates o The Contractor must provide quarterly updates in which data must be refreshed at the end of each quarter and provided to the OCC in a timely manner. Note that the sampling and permanent inclusion of newly-opened accounts that keeps the sample nationally-representative over time must occur at least annually.

o (Optional task to be performed only if exercised by OCC) The Contractor must provide monthly updates in the same manner as described for quarterly updates, but monthly. Note that the sampling and permanent inclusion of newly-opened accounts that keeps the sample nationally-representative over time must occur at least annually.

III.4.3 Sample Size of the (Alternative) Core Data The sample size for the base-year alternative core data must be a random sample of at least 500,000 American consumers who appear in the Alternative Credit Database in 2019.39

• (Optional task to be performed only if exercised by OCC) The sample size for the base-year alternative core data must be at least 1 million American consumers who appear in the Alternative Credit Database in 2019.

III.4.4 Alternative data historical records

38 As defined and listed by the CFPB in “Low Income and Subprime” consumer market segment in:

https://files.consumerfinance.gov/f/documents/cfpb_consumer-reporting-companies-list.pdf.

39 Consistent with Section III.4.1, a consumer is not considered to appear in the Alternative Credit Database unless he/she appears in a dataset that contains alternative financial service data—that is, datasets broadly consistent with what was provided to the OCC during market research for the DataX Credit Report Data Dictionary, the Clarity Distributable Data Dictionary, or the FactorTrust Alternative Credit Attributes Data Dictionary. Appearance in other alternative data sets, such as those containing only telecommunications, rent, income, or utility information do not qualify a consumer as appearing in the Alternative Credit Database for the purposes of consumer sampling. Note that if Sample Design B (see Section III.2.4) is chosen, the sampling method for Alternative Core Data must be approved by the COR. Sampling from the Alternative Credit Database using a percentage of the universe rather than a fixed sample size is acceptable if approved by the COR and if the number of consumers is approximately consistent with the sample sizes specified in Section III.4.3 or larger.

• (Optional task to be performed only if exercised by OCC) The Contractor must provide data with the base year set to 2017 instead of 2019; the subsequent updates will use 2017 as the base year, but the minimum sample size requirement is still 500,000 consumers in 2019 as described above (except this methodology does not employ simple random sampling to select the 2019 consumers;

instead simple random sampling is used to select records for the Base Year and to add newly-opened records for the relevant Updates). The consumers who remain in the panel from the base year through 2019 plus the consumers added during Updates who remain in the panel through 2019 must total at least 500,000 consumers as of the June 30, 2019 snapshot date.40

• (Optional task to be performed only if exercised by OCC) The Contractor must provide data with the base year set to 2015 instead of 2019; the subsequent updates will use 2015 as the base year, but the minimum sample size requirement is still 500,000 consumers in 2019 as described above (except that this methodology does not employ simple random sampling to select the 2019 consumers; instead simple random sampling is used to select records for the 2015 base year and to add newly-opened records during the subsequent update years). The number of consumers from the base year who remain in the panel through 2019 plus the consumers added during the Updates who remain in the panel as of 2019 must total at least 500,000 consumers as of the June 30, 2019 snapshot date.41

III.4.5 Alternative Data Record Required Features The data provided by the Contractor for the Base Year Alternative Core Data, the Updates to the Alternative Core Data, and Alternative Core Data Complements (to the Traditional Core Data) must contain the information contained in Section III.4.5 and its subsections.

III.4.5.1 Records The alternative data provided by the Contractor must include similar or analogous consumer-level data to what is in the Traditional Core Data (see Section III.3.5.1).

• Consumer record identifier: The Contractor must assign a unique, time-invariant, anonymized identifier to each record (consumer) to enable OCC staff to track individual records over time. All data files must include this anonymized consumer record identifier; this will allow the OCC to link the information from the traditional and alternative credit files (as well as inquiry, bankruptcy, and other files) back to the relevant consumer.

• Updates: For every periodic Update (quarterly or monthly), the Contractor must provide then-current information for each record of the data set and any record that has been added to it.

• Minimum required record features: The Contractor must minimally provide the following record features: Record identifier (unique ID); database snapshot date; credit score(s) (as available);42 and basic demographic information as available (including geographic information about the consumer’s residence and information related to the consumer’s date of birth). The precise configuration of this information must be approved by the OCC.

• Traditional/Alternative Record Flag: The Contractor must include a flag variable indicating whether each consumer present in the Base Year Alternative Core Data, the Updates to the

40 Or 1,000,000 consumers if the larger sample size option is chosen.

41 Or 1,000,000 consumers if the larger sample size option is chosen.

42 Credit scores provided must be commercially-marketed alternative credit scores, not the scores provided as part of the Traditional Core Data set.

Alternative Core Data, and Alternative Core Data Complements (to the Traditional Core Data) has an Alternative Bureau Database record only or both a Traditional Credit Bureau Database record and an Alternative Bureau Database record.

• Traditional/Alternative Sample Flag: The Contractor must deliver a flag variable indicating whether the alternative credit record was included because it corresponds to a consumer selected as a part of the alternative core data sample or whether the alternative credit record was included as part of the alternative core data complement (to the traditional core data).

III.4.5.2 Record Features The OCC desires Alternative Credit Data that is similar in nature to the data in III.3.5.2, that is, data on the fundamental features of every tradeline (and every inquiry, collection, and other record types) associated with each consumer credit record in the data sample. Fundamental features are irreducible and cannot be computed from the data on other features the Contractor provides. Examples include account status, account type, highest credit amount, and various tradeline dates. The OCC recognizes that some Alterative Credit Databases can only provide this information at the consumer level rather than at the tradeline level. Such consumer-level summary statistics are often called “attributes.” The OCC will consider consumer-level/attribute data as acceptable to fulfill the Alternative Data requirements under this contract.

• Consumer level data:

o The Contractor must provide a unique identifier allowing OCC staff to track individual consumers over time.

o For each consumer in the alternative data set, the Contractor must provide data on the features associated with the record; these features must be broadly consistent with the “DataX Credit Report Data Dictionary” provided to the OCC during market research and/or the “DataX Attributes File Layout and Metadata” provided to the OCC as part of Equifax’s response to the OCC’s previous credit bureau data solicitation.43 Note that, as with the Traditional Credit Bureau data, the Alternative Credit Data provided to the OCC must not contain certain highly-sensitive personally identifiable information.44

III.4.5.3 Alternative Record Information for Consumers Selected in the Traditional Sample and Traditional Record Information for Consumers Selected in the Alternative Sample

For any consumers selected for inclusion in the alternative core data (or updates to those data) who also have records in the traditional credit bureau database that would have been provided if that consumer was selected as part of a traditional core data sample, the Contractor must provide that…