How Accurate is Your Metro 2® Furnishing? (Do you even know?)

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.

[article_ad]

Three Things You Should Be Doing for Accuracy and Control

1. Conduct a deep review of the Metro 2® furnishing file that is submitted to the Nationwide Credit Reporting Agencies (NCRAs)

2. Develop a detailed Metro 2® data mapping and conversion document to examine system of record code that produces the Metro 2® file

3. 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