The Metro 2 Error Report 2026
The most common Metro 2 validation failures in furnisher data — which fields and segments fail most, and why. Grounded in the real CRRG validation-rule taxonomy and anonymized, aggregate outcomes from BureauRelay’s validation pipeline.
52.1% of files that failed validation had a missing or non-unique account number.
It was the most common failure and the most broadly distributed across furnishers (8 of 12 in the sample). The pattern across the whole dataset is the same: the errors that get furnisher data rejected are almost never about the loan itself — they are missing identifiers, unmapped status codes, and malformed address fields that a pre-submission validation pass catches before anything reaches a consumer’s report.
What to do after this report flags a file
If you are new to Metro 2, start here. Treat the report as a cleanup queue: fix anything that prevents the file from being read, then fix account continuity, then required consumer/address fields, then allowed-value mappings. That order prevents teams from wasting time on low-level data edits while the file still has a structural rejection.
- Run the latest production file through validation and group errors by category, not by raw row count.
- Fix structural file-generation failures first, especially RDW and record-length issues, because they can reject the entire file before account-level data is read.
- Repair stable account identifiers next; account-number continuity is the highest-leverage cleanup because it protects month-to-month tradeline matching.
- Normalize required identity and address fields: first name, surname, city, state, and postal code.
- Replace placeholder or internal codes with reviewed CRRG mappings for ECOA, account status, and portfolio type.
- Purge test values from the live reporting population and block known placeholders from future exports.
- Regenerate the file, rerun validation, and do not submit until critical and error-level findings are cleared.
The target state is concrete: a regenerated file with zero critical or error-level findings, stable account identifiers, no placeholder live data, and a documented mapping table for every CRRG-coded field used by the products being reported.
Methodology
This report combines two sources, one factual-and-fixed and one measured-and-evolving:
- The CRRG validation-rule taxonomy. The structure of Metro 2 errors is defined by the Credit Reporting Resource Guide (CRRG), the Metro 2 specification published by the Consumer Data Industry Association (CDIA). BureauRelay enforces 56 automated checks across 11 categories on top of that rule set. This taxonomy is exact and does not depend on any sample.
- Aggregate validation outcomes. We analyzed 432 production Metro 2 files run through BureauRelay’s validation pipeline between June 12, 2025 and June 19, 2026, representing 25 distinct furnishers. Of those, 71 files (across 12 furnishers) failed validation, containing 8,586 individual CRRG findings.
Each error is ranked by file-level prevalence — the share of failed files in which it appears, counting each error category at most once per file. We rank by prevalence rather than raw error counts on purpose: raw counts are dominated by a handful of high-volume files (the single largest failed file accounts for 14.6% of all error items, and the top three for 43.7%), so a prevalence metric gives a more honest picture of which mistakes are widespread versus simply high-volume. We also report the number of distinct furnishers behind each category so you can see how broad each pattern is.
The most common validation failures
Ranked by the share of failed files in which each error appeared. Every one of these is caught automatically by a pre-submission validation pass.
Account / Identification Number missing
The single most common failure, and the most broadly distributed across furnishers. A blank or non-unique account identifier breaks the tradeline's continuity at the bureau — the account can't be matched to prior months, so history fragments. It usually traces to a column-mapping gap (the source system's loan ID never gets mapped to the Metro 2 account-number field) rather than to anything wrong with the underlying loan.
What to check
- Find the immutable source-system ID used for the account or loan.
- Confirm it is mapped to the Metro 2 Consumer Account Number / Identification Number field.
- Check for blanks, duplicates, and IDs that change between reporting cycles.
How to fix it
- Map the Metro 2 account number from a stable account-level identifier, not from a customer name, row number, or monthly export ID.
- Backfill blanks before the next file is generated.
- Add a uniqueness-and-stability check to the file build so the same account keeps the same ID every month.
Pass condition: Every reported account has a nonblank, unique identifier, and unchanged accounts retain the same identifier across cycles.
State invalid or missing
A two-character USPS/Canada state or province code is required on the base address. Failures are almost always a free-text state ("California" instead of "CA"), a placeholder, or an empty value carried over from incomplete onboarding records.
What to check
- Profile the state field for blanks, full names, lowercase values, and non-US/non-Canadian placeholders.
- Confirm the source value is stored as a two-character state or province code before file generation.
- Review whether missing states are coming from a specific origination channel or import template.
How to fix it
- Normalize full state names to postal abbreviations during import or mapping.
- Block live reporting for records with missing or unsupported state/province values until the address is corrected.
- Add a source-channel report so one bad template cannot keep producing invalid states.
Pass condition: All base-segment address records carry a valid two-character USPS or Canadian province code.
ECOA Code invalid
The ECOA / Association Code must be one of the CRRG-defined values (e.g. 1 = individual, 2 = joint, 3 = authorized user). Furnishers frequently emit a 0, a blank, or a system-internal code, or fail to switch an authorized user to Z when an account closes — all of which the bureau rejects.
What to check
- List every internal borrower-role value in the servicing system.
- Map each role to the CRRG-allowed ECOA / Association Code set.
- Look specifically for blanks, 0 values, authorized users, co-borrowers, and closed accounts.
How to fix it
- Replace hard-coded or placeholder ECOA values with an explicit role-to-ECOA mapping table.
- Require a reviewed mapping for every new product or borrower role before reporting starts.
- Add regression cases for individual, joint, authorized-user, terminated, and closed-account scenarios.
Pass condition: Every reported account emits an allowed ECOA code that matches the consumer's relationship to the account.
ZIP / Postal Code invalid or missing
ZIP must be a valid 5- or 9-digit US code (or a Canadian A1A 1A1 postal code). Common causes are truncated leading zeros (a New England ZIP stored as a number), dashes/spaces left in, or the field missing entirely on thin onboarding records.
What to check
- Confirm ZIP/postal code is stored as text, not a number.
- Search for blanks, four-digit values, values with lost leading zeros, and malformed Canadian postal codes.
- Compare failures by import source to find templates that strip leading zeros or punctuation inconsistently.
How to fix it
- Store ZIP/postal codes as strings at every step of the pipeline.
- Normalize US ZIPs to 5 or 9 digits and Canadian postal codes to the expected alpha-numeric pattern.
- Hold records with incomplete postal codes out of the production file until corrected.
Pass condition: All reported postal codes are present and match the accepted US ZIP or Canadian postal-code format.
Consumer First Name missing
A required identification field. Failures cluster where a furnisher stores the consumer name as a single combined field and never splits it into the discrete first-name / surname fields the Metro 2 base segment requires.
What to check
- Identify whether names are stored as first/last fields or as one combined display name.
- Find records where first name is blank but full name is populated.
- Review business accounts, estates, and edge cases separately before applying a generic name split.
How to fix it
- Capture first name and surname as separate source fields where possible.
- For legacy combined-name data, split conservatively and queue ambiguous records for manual review.
- Add an import validation that prevents live reporting when required consumer-name components are missing.
Pass condition: Every consumer base segment has a populated first-name field, with ambiguous legacy names reviewed before reporting.
Account Status invalid
The Account Status code must be a CRRG-allowed value and must be internally consistent with the balance and past-due fields. The recurring failure here is a literal "00" — a placeholder that is not a valid status — emitted when the source system has no status mapped for the account.
What to check
- Inventory every internal account-status value emitted by the servicing system.
- Find placeholder values such as 00, null, unknown, or unmapped.
- Compare status against current balance, amount past due, close date, charge-off amount, and delinquency fields.
How to fix it
- Create a reviewed source-status-to-Metro-2-status mapping table.
- Forbid defaulting to 00 or blank when a status is unmapped.
- Add cross-field validation so paid, closed, delinquent, charged-off, and current accounts carry consistent supporting fields.
Pass condition: All account statuses are CRRG-allowed values and are consistent with the balance, past-due, close-date, and delinquency fields.
ZIP is a test / placeholder value
Placeholder ZIPs such as 00000 or 12345 survive from test or seed data and slip into a live file. They pass a naive length check but are flagged because they are not real deliverable codes — a classic sign that test records were never purged before go-live.
What to check
- Search the live reporting population for placeholder ZIPs such as 00000, 11111, 12345, 99999, and internal test addresses.
- Confirm test, sandbox, demo, and seed accounts are excluded from production file generation.
- Check whether placeholder values are being inserted by default when address capture is incomplete.
How to fix it
- Purge or exclude test and seed records from live reporting datasets.
- Replace placeholder-default behavior with an explicit incomplete-address status.
- Add a release gate that blocks known test values from production Metro 2 exports.
Pass condition: No known placeholder ZIP/postal values appear in the live reporting population.
Record Descriptor Word / length invalid
Metro 2 records are fixed-length, and the Record Descriptor Word must match the final serialized record length. In the base-record layout this starts at 426 characters, then increases when supplemental segments are appended. A wrong RDW or an off-by-one record length rejects the entire file at the bureau before any single account is even read. Almost always a file-generation bug, not a data problem.
What to check
- Measure byte length for the header, trailer, and every base or supplemental record after final encoding.
- Confirm the base record length and any appended segment lengths before calculating the RDW.
- Check line endings, padding, multibyte characters, and any post-generation transformations.
How to fix it
- Fix the file writer before spending time on account-level data cleanup; structural failures can reject the entire file.
- Generate RDW from the final serialized record length, not from a pre-padding object model.
- Add byte-level tests for representative header, base, supplemental, and trailer records.
Pass condition: Every record has the expected fixed length for the selected format, and every RDW matches the final serialized record.
Consumer Surname missing
The companion to the first-name failure — the surname field is required and is left blank when a combined name field is not split correctly during mapping.
What to check
- Find records with blank surname values, especially where a combined full-name field exists.
- Separate consumer, business, estate, and guarantor naming cases before applying automated parsing.
- Review whether surname loss is happening at origination, import, or Metro 2 mapping time.
How to fix it
- Capture surname as a separate source field for new records.
- Backfill legacy records from reliable source data, with manual review for ambiguous names.
- Block production reporting for consumer records that still lack required name components.
Pass condition: Every consumer base segment has a populated surname field or is removed from the file until corrected.
City missing
A required address component. Missing-city failures track with the same incomplete onboarding records that drive the state and ZIP failures — the address was never fully captured at origination.
What to check
- Find records where city is blank while state or ZIP is present.
- Group missing-city records by origination channel, import file, or partner feed.
- Check whether address parsing is dropping city values from multi-line or international addresses.
How to fix it
- Require city during onboarding or partner import for records intended for credit reporting.
- Backfill city from authoritative address data where available.
- Suppress incomplete addresses from production reporting until the city/state/ZIP set is complete.
Pass condition: Every reported base address includes a nonblank city paired with a valid state and postal code.
Portfolio Type invalid
Portfolio Type (e.g. R = revolving, I = installment, M = mortgage, O = open, C = line of credit) drives which other fields are required. An unmapped or wrong value (a literal "0") both rejects and silently changes which downstream validations apply.
What to check
- List every product type or loan program included in the reporting file.
- Map each product to the CRRG portfolio type: revolving, installment, mortgage, open, or line of credit.
- Look for placeholder portfolio values, especially 0, blank, unknown, or product names copied directly into the field.
How to fix it
- Move portfolio type into reviewed product configuration instead of free-form export logic.
- Block new products from reporting until portfolio type and dependent field rules are configured.
- Run product-specific validation because portfolio type changes which terms, limit, and balance rules apply.
Pass condition: Every account has an allowed portfolio type, and downstream field requirements match that product's portfolio category.
The common thread: address and identity fields on the base segment (account number, name, city, state, ZIP), allowed-value codes (ECOA, account status, portfolio type), and file-structure issues (record length / RDW). Almost none of these reflect a problem with the loan — they are mapping gaps and leftover test data, which is exactly why validating before submission is so effective.
The CRRG validation-rule taxonomy
The frequencies above sit on top of a fixed structure. The CRRG defines the field positions, lengths, allowed values, and cross-field rules for every Metro 2 record. BureauRelay implements 56 automated checks against that specification, split by severity into 6 rejection-causing (“critical”), 32 non-compliant (“error”), and 18 advisory (“warning”) rules. Here is how they break down by category.
| Category | Checks | What it covers |
|---|---|---|
| Format | 14 | Record length / RDW, field lengths, character encoding, ZIP / state / SSN / phone formatting, and payment-history-profile character rules.
|
| Required field | 5 | CRRG-mandatory fields that, when blank, reject the record — postal code, terms duration, payment rating, and a consumer identifier.
|
| Enum (allowed-value) | 4 | Fields whose value must be one of a fixed CRRG-defined set — Consumer Information Indicator, ECOA, account status, payment rating.
|
| Cross-field | 6 | Consistency rules between fields — a paid-in-full account must show zero past due; a closed account must carry a close date; a delinquent account must carry a Date of First Delinquency.
|
| Portfolio | 8 | Rules tied to portfolio type — revolving accounts need a credit limit, installment balances shouldn't exceed the original amount, open accounts use 000 terms.
|
| Date | 4 | Date parseability, FCRA retention window, future-dated values, and date-sequence sanity (e.g. close date before open date).
|
| Supplemental segments | 6 | Structural and value rules for the J1/J2, K1-K4, L1, and N1 supplemental segments, including per-segment count limits.
|
| Amount | 3 | Monetary sanity — no negative amounts, sanity thresholds on unusually high values, and scheduled-vs-actual payment variance.
|
| Business logic | 3 | Bankruptcy-specific reporting expectations (authorized-user ECOA, Payment History Profile position 1, Chapter 12/13 DOFD).
|
| Consumer | 2 | Plausibility of the consumer's date of birth (minor / over-100 typo detection).
|
| Account status | 1 | Reuse of a terminated account status without opening a new account.
|
For the full, field-by-field reference, see the Metro 2 error & rejection code reference, the Metro 2 field reference, and the CRRG overview. The CRRG itself, published by the CDIA, is the authoritative source; this report does not reproduce its proprietary tables.
Why these errors happen — and how to prevent them
Across the sample, the failures fall into three buckets, and all three are preventable upstream:
- Field-mapping gaps. The source system has the data, but it never gets mapped to the right Metro 2 field — a loan ID that doesn’t reach the account-number field, a combined name field that’s never split, an internal status code that isn’t translated to a CRRG value. This is the largest bucket and the one behind the top finding.
- Incomplete onboarding records. Address fields (city, state, ZIP) that were never fully captured at origination surface as missing-field rejections months later.
- Leftover test data. Placeholder ZIPs (00000), test SSNs, and seed records that were never purged before go-live.
The fix for all three is the same: validate every file against the full CRRG rule set before it’s submitted, and fix the mapping once rather than chasing rejections every cycle. Catching a wrong byte before it leaves your system is the cheapest form of compliance a furnisher can buy.
How to reproduce these numbers
The figures in this report are computed, not estimated. They are produced by an aggregate query over BureauRelay’s validation records that emits only category-level counts. In plain terms, the query:
- takes every production file validated in the window (
environment = ‘live’); - keeps the files that failed validation;
- maps each validator finding to a stable CRRG error category and de-duplicates categories within each file;
- counts, per category, the number of failed files and the number of distinct furnishers, then ranks by file-level prevalence;
- reports only those aggregates — never a file name, furnisher, consumer, or account value.
As BureauRelay’s per-rule analytics pipeline (the metro2_dq_monthly rollup) accumulates production volume, the headline source will move to that pre-aggregated, per-rule view grouped across furnishers, widening the sample and adding month-over-month trend lines. The methodology — file-level prevalence, distinct-furnisher breadth, aggregate-only output — stays the same.
Frequently asked questions
What is the most common Metro 2 furnishing error?
In this sample, a missing or non-unique Account / Identification Number was the most common error, appearing in 52% of files that failed validation and across the widest range of furnishers. A blank account identifier breaks the tradeline's month-to-month continuity at the bureau, which is why it matters even though it looks like a small data field.
How were these numbers calculated?
They are computed from aggregate, anonymized outcomes of BureauRelay's own validation pipeline — 432 production files validated between June 2025 and June 2026, of which 71 (across 12 furnishers) failed. Each error is ranked by file-level prevalence: the share of failed files in which it appears. We deliberately rank by prevalence rather than raw error counts so that one high-volume furnisher cannot skew the results. No customer, consumer, or account data is exposed; only category-level aggregates are reported.
Is this a complete picture of Metro 2 errors?
No — and we say so plainly. This is an early read on a deliberately small, recent sample, not a population study. The complementary, fully factual part of this report is the CRRG validation-rule taxonomy: the 56 automated checks (across 11 categories) BureauRelay runs on every file, sitting on top of the broader Credit Reporting Resource Guide (CRRG) rule set published by the CDIA. The taxonomy holds regardless of sample size; the frequencies will be refreshed as the dataset grows.
Do these errors cause credit-report disputes?
Many do, indirectly. A wrong account number, a mis-coded status, or a missing Date of First Delinquency can surface later as an inaccuracy a consumer disputes. The point of this report is prevention: validating the file before it is submitted catches these issues upstream, before they ever reach a consumer's report. BureauRelay is a furnishing and validation tool — it generates, validates, and delivers Metro 2 files. It does not resolve disputes; e-OSCAR is the bureaus' separate dispute-response platform.
Why does a missing account number fail the whole tradeline?
The account / identification number is how a bureau matches this month's record to the same account reported in prior months. If it is blank or changes between cycles, the bureau can't link the history, so the tradeline fragments or a duplicate is created. Keeping a stable, unique identifier is one of the highest-leverage things a furnisher can get right.
How can furnishers prevent these errors?
Validate every file against the full CRRG rule set before submitting it, not after the bureau rejects it. The most common failures here — missing account numbers, unmapped status / ECOA codes, malformed ZIP / state values, leftover test data — are all caught by automated pre-submission validation and a clean field-mapping step. Catching a wrong byte before it leaves your system is the cheapest form of compliance there is.
Validate your file before you submit it
Every error in this report is caught by an automated pre-submission validation pass. Drop a file into the free Metro 2 file viewer and watch it check against the CRRG rule set — no account required.