The CFPB expects that you, as furnishers, have written documentation to explain how you’ve populated various Metro 2® fields from your systems of record. Here are a few areas to tackle as part of your journey to data furnishing accuracy and control.
Three Things You Should Be Doing for Accuracy and Control
- Conduct a deep review of the Metro 2® furnishing file that is submitted to the Nationwide Credit Reporting Agencies (NCRAs)
-
Develop a detailed Metro 2® data mapping and conversion document to examine system of record code that produces the Metro 2® file
-
Review upstream operational processes to identify trigger events and data that impact contents of the Metro 2® file
As part of #1 and #2 above, we have uncovered four important areas that would likely be flagged by regulators. While these steps can be time-consuming and highly detailed, what they reveal can help you ensure data accuracy prior to submission to NCRAs.
Do You Understand How Your Metro 2® File Is Created?
Do you have clear knowledge—or documentation—of how your systems of record map to your Metro 2® files prior to sending them to NCRAs, including those generated by your third-party processors? If you don’t, you can wind up with inaccurate furnishing, an increase in complaints and disputes, and ultimately regulators knocking on your door.
Recording how your Metro 2® file is created with a detailed, audit-ready data mapping and conversion document is a key component to meeting the evolving regulatory expectations for consumer reporting accuracy.
Top 4 Areas You Can Fix to Improve Accuracy
The following examples are typical opportunities for system and/or operational enhancements that you can make to ensure the data going to the CRAs is accurate.
1. System Limitations for Compliant Reporting
- Inability to generate certain Metro 2® file segments
- Limited capture / storage of information (6 months vs. 7 years)
- Reporting of delinquent accounts for greater than 7 years
- Consolidation of data elements into one field requiring manual parsing (Surname, First Name, Middle Name)
- Missing logic required to report Metro 2® fields (e.g., reporting spaces instead of the Generation Code)
- Not flagging required Metro 2® fields as mandatory (e.g., Social Security Number)
2. Logic Potentially Results in Inaccurate Reporting
- Inaccurately counting days past due for account status assignment
- Lacking logic to report “Last Good Payment” date after a payment reversal due to NSF
- Mass overwriting of dates (e.g., Date of Account Information)
- Missing best practice controls (e.g., if account is current and in bankruptcy, Date of First Delinquency should not be blank)
- Reporting the most recent Actual Payment Amount value rather than totaling all payments receiving during the reporting period
3. Inconsistency Among Correlated Fields
- Failure to update all relevant downstream data elements when manually overriding Metro 2® fields (e.g., Account Status)
- Inaccurate or incomplete reporting when an account is closed (e.g., Date Closed is not populated, Current Balance is greater than $0)
- Inconsistent date progression (e.g., Date of Account Information is a date later than the timestamp of the file)
- Inappropriate representation of Metro 2® fields related to Account Status (e.g., Payment Rating is not populated when required, Payment History profile does not reflect the prior month’s Account Status)
4. Missing and Inaccurate Field Values
- Invalid assignment of Portfolio Type and/or Account Type values
- Inaccurate values furnished for Special Comment Code, ECOA, Consumer Information Indicator, and Compliance Condition Code fields
