What Is Metro 2 Compliance? The Data Furnisher's Guide

Two obligations, two failure modes

People use "Metro 2 compliance" to mean two genuinely different things, and conflating them is why the phrase is so slippery. One is a technical standard published by a trade association. The other is a legal duty imposed by federal statute. You can satisfy either one while failing the other, and the failures look nothing alike.

The asymmetry matters. Format failures announce themselves. Accuracy failures do not. A furnisher who measures compliance by reject rate is measuring the cheaper half of the problem and calling it the whole thing.

What Metro 2 compliance is not

A meaningful share of the search traffic for "Metro 2 compliance" is looking for something else entirely: the so-called Metro 2 compliance method, a dispute technique that circulates in credit repair communities. The idea is that a consumer challenges a tradeline not by arguing the underlying facts but by pointing at internal inconsistencies in its Metro 2 fields, on the theory that a record which contradicts itself cannot be accurate.

It is worth being plain about this, because the two meanings point in opposite directions. The compliance method is a tactic aimed at furnishers. Metro 2 compliance, in the sense a furnisher means it, is the furnisher's own obligation. If you are here because someone told you your company needs to be "Metro 2 compliant," the rest of this page is for you. If you are here looking for a dispute strategy, this is not that page, and the dispute process is described elsewhere on this site in neutral terms.

The tactic's existence is nonetheless a reason for furnishers to care about field-level consistency. A tradeline whose account status disagrees with its payment rating, or whose payment history contradicts its balance, is an easy target regardless of whether the underlying account facts are right. Fewer disputes start when the data is right.

The format layer: what conformance actually requires

Metro 2 is a fixed-width format. Every field occupies a defined byte range in a defined record, and the value in it must come from a defined set. There is no schema negotiation and no optional extension. Conformance has three parts.

Record layout. A file is a Header record, a series of Base Segments each optionally followed by supplemental segments, and a Trailer. Each record carries a descriptor word stating its length, and the lengths have to be right. The segment reference covers what each record is for and when it is required. Supplemental segments have ordering rules: a J2 without a J1 is invalid, and a J1 without a Base Segment is meaningless.

Field positions and types. Every one of the fields in the field reference has a start position, a length, a type, and a required flag. Dates are dates in a specific layout, amounts are zero-padded numerics, and text fields are left-justified and space-filled. A value that is right-justified where the format expects left-justified is a defect even though the characters are correct.

Code-set validity. Roughly a dozen fields accept only codes from a published set. The Metro 2 codes cheat sheet lists all of them: Portfolio Type, Account Type, Terms Frequency, Account Status, Payment Rating, Payment History Profile, Special Comment, Compliance Condition, ECOA, Consumer Information Indicator, and Creditor Classification.

Here is the part that catches people. Code-set validity is per field, but code-set correctness is not. Every individual code in a record can be a legal value for its field while the combination describes an account that cannot exist. A mortgage account type under a revolving portfolio type is two valid codes and one impossible loan. Those cross-field rules are collected on the cheat sheet under codes that must agree with each other, and they sit exactly on the boundary between the format layer and the legal layer.

The legal layer: FCRA section 623 in furnisher terms

The Fair Credit Reporting Act does not require anyone to furnish data. It regulates you once you choose to. Section 623 sets out the duties of furnishers of information, and the accuracy and integrity standards are implemented at 12 CFR Part 1022 Subpart E, part of Regulation V. Three duties matter operationally.

Accuracy and integrity. You may not furnish information you know, or have reasonable cause to believe, is inaccurate. Subpart E goes further than a bare accuracy rule: it asks you to establish and follow reasonable written policies and procedures for the accuracy and integrity of what you furnish, appropriate to the nature, size, complexity, and scope of your activities. "Integrity" is doing real work in that phrase. It covers furnishing information in a form the bureaus can use correctly, with the identifiers needed to match it to the right consumer, and with enough context that it does not create a materially misleading impression. See accuracy, integrity, and consistency for how that maps onto specific fields.

Correct and update. When you determine that information you furnished is incomplete or inaccurate, you must promptly correct it and notify the bureaus, and you must stop furnishing the incorrect version. This is a duty that runs continuously, not one that activates only when someone complains.

Investigate on receipt of a dispute. When a dispute reaches you, whether directly from the consumer or through a bureau, you owe a reasonable investigation, a response within the statutory window, and correction of anything the investigation shows to be wrong. The reporting mechanics of that are handled through the Compliance Condition Code field, which is how you tell the bureaus that a dispute is open and, crucially, how you tell them it has closed. A blank value in that field does not clear a prior dispute flag, which is why stale dispute conditions are one of the most common accuracy defects in live portfolios.

The nine ways furnishers fail compliance

These are the recurring defects. Note how few of them are format errors. Most are records that a bureau will accept without comment and that misdescribe an account.

The full error and reject code library documents each of these as a specific check with the fix, and common validation edits covers the ones the bureaus apply on their side.

How to verify compliance before you submit

Checking a file before it goes out is worth more than fixing it afterward, for a reason that is easy to miss: a rejected file costs you a cycle, but an accepted file that is wrong costs you the cycle plus everything downstream of it. Corrections have to be furnished, disputes have to be investigated, and the consumer's report was wrong the whole time.

A serious pre-submission check runs at four levels. Structural: record lengths, encoding, descriptor words, header and trailer presence. Field-level: format, allowed values, and required-when conditions. Cross-field: the pairings collected on the codes that must agree table. And cross-cycle: month-over-month impossibilities, such as a balance that rises on a closed account or a date of first delinquency that moves.

The first two are mechanical and a careful analyst can do them on a small file. The last two are not realistically checkable by hand at portfolio scale, which is the honest case for automating the check. Bridgeforce's analysis of furnisher data quality has found that a substantial share of tradelines submitted without automated controls contain errors. See data quality monitoring and audit and the implementation checklist for the operational shape of that.

One caveat on what any validator can do. Automated checking can tell you a record is non-conformant or internally inconsistent. It cannot tell you a record is factually untrue. If your servicing system believes an account is current and it is not, a validator will confirm the record is well-formed and pass it. Compliance still depends on the data being right at the source.

Frequently asked questions