How a small furnisher fixed its Equifax and Experian rejects
The first production submission is where most furnishers learn that "the file imported fine" and "the bureaus accepted it" are two completely different things. A small lender sends a tidy fixed-width Metro 2 file to Equifax and Experian, the SFTP handshake succeeds, and a week later a response file lands in the outbound folder with a column of reject and error codes next to account numbers the team thought were perfect. Nothing posted. The phone starts ringing.
This playbook follows that exact scenario in general terms — a furnisher with a few hundred consumer tradelines, no prior reporting history, working through its first round of bureau rejects. It is written to be instructive, not attributed to any named organization. The codes, fields, and fixes are real and accurate to the CDIA Credit Reporting Resource Guide (CRRG) and the Metro 2 format; the company is illustrative.
If you are about to submit for the first time, or you just got a response file back and the rejects make no sense, this is for you. We will read the response file line by line, decode the most common reject reasons, correct the underlying records, and resubmit clean — then lock in pre-validation so the next cycle never produces the same surprises.
What a bureau reject actually is (and what it is not)
A reject is not a complaint about your business or your borrowers. It is the bureau's automated quality gate telling you a specific record did not meet a structural or logical rule, so it was set aside instead of posted. Rejects come in two broad flavors: hard rejects, where the record is dropped entirely and nothing about that consumer updates this cycle, and warnings or soft errors, where the record posts but a field looked suspicious enough to flag.
The critical mental shift is that a successful transmission tells you nothing about acceptance. Your SFTP job can report a clean upload to Equifax, Experian, TransUnion, and Innovis while every record inside the file gets bounced for the same field-level defect. Acceptance lives in the response file, not the transfer log.
Each bureau returns its own response artifact on its own cadence — Experian and Equifax both publish structured error output that pairs an account or consumer identifier with one or more reason codes. The reason codes map back to specific Metro 2 field positions and the rules that govern them. Your job is to translate that mapping into edits on the source records.
- Hard reject = record dropped, nothing posts for that consumer this cycle.
- Warning/soft error = record posts, but a field was flagged for review.
- A clean SFTP transfer is not acceptance — read the response file.
- Every reason code points back to a Metro 2 field position and a CRRG rule.
Reading the response file without guessing
Open the response file the same way you would inspect any Metro 2 artifact: structurally, not by eyeballing raw text. The free in-browser file viewer at /metro2/file-viewer parses fixed-width segments and lines up each field with its position, which is the fastest way to see why a record tripped a rule. For a response file, you are looking for the pairing of your record's key fields — account number, consumer name, SSN — against the bureau's returned reason code.
Work the file as a triage list. Group rejects by reason code first, because a first submission almost always fails in clusters: one wrong default or one bad template assumption produces the identical error across dozens or hundreds of records. Fixing the pattern once fixes the cluster. Chasing rejects one account at a time is how a two-hour cleanup becomes a two-day one.
When you hit a code you do not recognize, look it up rather than guessing. The error-code reference at /metro2/error and the field reference at /metro2/field translate bureau and Metro 2 codes into plain-language causes and the exact segment they live in. Keep both open while you triage — most first-round rejects resolve to three or four distinct root causes once you decode them.
- Parse the response in the file viewer (/metro2/file-viewer) instead of reading raw text.
- Group rejects by reason code — first submissions fail in clusters, not one-offs.
- Decode unfamiliar codes against /metro2/error and /metro2/field before editing.
- Match each returned identifier (account, SSN, name) back to the source record.
Invalid status code combinations
The single most common first-submission reject is an Account Status that contradicts the rest of the record. Account Status (Base Segment, the two-digit code such as 11 for current, 71 through 84 for the delinquency ladder, 64 for repossession, 97 for charge-off) has to agree with Payment Rating, Current Balance, Amount Past Due, and the Payment History Profile. Report status 11 (current) while also reporting an Amount Past Due, and the record is internally inconsistent — the bureau rejects it.
Two recurring traps: reporting a delinquency status (71+) without a corresponding Date of First Delinquency, and reporting status 13 (paid/closed, zero balance) while a non-zero Current Balance is still present. Both are logical contradictions the validator catches before the bureau ever sees them. The status-code reference at /metro2/status-code lists each code with the balance, past-due, and rating combinations it is allowed to coexist with.
The fix is to make the status the source of truth and reconcile every dependent field to it. If the account is genuinely current, clear Amount Past Due and confirm the Payment History Profile shows no recent delinquency markers. If it is delinquent, the Date of First Delinquency must be populated and the Payment Rating must align with the status.
- Status 11 (current) cannot carry an Amount Past Due — reconcile or change the status.
- Any delinquency status (71-84) requires a populated Date of First Delinquency.
- Status 13 (paid/closed) must report a zero Current Balance.
- Payment Rating and Payment History Profile must agree with Account Status.
Date of First Delinquency (DOFD) errors
DOFD is the field that decides when a negative item ages off, so the bureaus guard it hard. The classic first-round mistakes are leaving it blank on a delinquent account, setting it after the Date Opened, setting it in the future, or moving it forward on resubmission — which illegally re-ages the account and is exactly the behavior FCRA obsolescence rules exist to prevent.
DOFD must be the date the account first went delinquent and never recovered. It does not reset when a later payment is missed, and it must be on or before every later date in the record. A frequent template bug is copying Date Opened or the reporting Date into DOFD for every row; that passes a naive null check but produces dates that fail the bureau's logic and re-age accounts on every cycle.
When you correct DOFD, lock it. Once a value is established for an account it should carry forward unchanged until the account either pays current or ages off. The date-field cross-checks (DOFD on or before Date Closed, on or before the reporting period, after Date Opened) are exactly the kind of rule the validator runs before generation so the contradiction never reaches the bureau.
- DOFD is required on every delinquent account — blank is a hard reject.
- DOFD must fall after Date Opened and on or before all later dates.
- Never advance DOFD on resubmission — that re-ages the account (FCRA violation).
- Establish DOFD once, then carry it forward unchanged across cycles.
Length, RDW, and structural file errors
If an entire file or a whole block of records bounces, suspect structure before content. Metro 2 records are fixed-width, and the Record Descriptor Word (RDW) — the first four characters of each segment — declares the exact byte length the bureau expects. A Base Segment that should be 426 characters but arrives at 420 because a trailing field was truncated will reject every record that inherits the same template flaw.
The other structural offenders are line-ending and encoding mismatches (CR/LF where the spec wants a specific terminator, or UTF-8 artifacts in what must be plain ASCII), a Header or Trailer record whose counts do not match the actual number of records in the file, and packed/zero-padded numeric fields that were left blank-padded instead. These are not data errors — they are format errors, and they tend to be all-or-nothing.
This is why generating the file through the production pipeline matters rather than hand-assembling fixed-width strings. The generator computes RDW from the actual segment content, pads numeric and alphanumeric fields per the spec, and reconciles Header and Trailer counts automatically. Loading a suspect file into /metro2/file-viewer immediately shows whether the declared RDW matches the real segment length.
- RDW (first four chars of a segment) must equal the segment's true byte length.
- Truncated or mis-padded fields shift every field after them — a cascade of rejects.
- Header/Trailer record counts must match the actual record count in the file.
- Confirm plain ASCII and the spec terminator — stray encoding bytes break parsing.
Missing required fields and ECOA mismatches
Some fields are non-negotiable: Consumer Account Number, Surname and First Name, Date of Birth or SSN (one identifier minimum, both preferred), Date Opened, Account Type, Portfolio Type, and the ECOA/Association Code that describes the consumer's relationship to the account. Leave any of these blank and the record cannot be matched to a consumer file, so it rejects. A short SSN, an obviously invalid DOB, or a name that is all spaces fails the same way.
ECOA is the field that quietly produces the most resubmissions. The ECOA Code (Account Holder/Association Code in the J1/J2 segments) declares whether the consumer is the individual borrower (1), a joint/contractual holder (2), an authorized user (3), a co-signer (4), and so on. The mismatch pattern is reporting one borrower on the Base Segment but attaching a J2 associated-consumer segment with an ECOA that contradicts it, or marking a sole borrower as joint. For commercial tradelines the relevant ECOA values shift (W and the 6A/6B/7A account-type family), and applying consumer ECOA logic to a business account is its own reject.
Fix these by treating the Base Segment plus its J1/J2 segments as one coherent statement about who owes the debt. Every associated consumer needs a matching J-segment, every J-segment needs a valid ECOA, and the relationship has to be consistent end to end. The field reference at /metro2/field lists each required field and its valid ECOA values, including the commercial set.
- At minimum: account number, name, one identifier (SSN/DOB), Date Opened, Account/Portfolio Type, ECOA.
- Every associated consumer needs a J1/J2 segment with a valid, consistent ECOA.
- Do not mix consumer ECOA logic into commercial tradelines (W, 6A/6B/7A family).
- A sole borrower marked joint — or a joint account missing its J2 — both reject.
Correcting and resubmitting
Once the rejects are grouped and decoded, fix at the source — the import or the underlying records — not by patching the output file. Editing a generated fixed-width file by hand reintroduces exactly the RDW and padding errors you are trying to eliminate. Correct the data, then regenerate so RDW, Header/Trailer counts, and field padding are computed fresh.
Resubmit only what changed. The bureaus expect each cycle to carry forward established history, so a correction run should update the affected accounts with their corrected status, dates, and ECOA while leaving DOFD and Date Opened anchored to their original, correct values. Genuine error corrections may warrant a Compliance Condition Code (the CCC / "XB" family) so the bureau knows the change is a correction, not new derogatory activity — but routine field cleanup on records that never posted does not need one; you are simply resubmitting them clean.
Before the corrected file leaves the building, run it through validation again and confirm zero blocking errors, then regenerate through the production endpoint so the file carries the right storage path, audit trail, and SFTP routing. Watch the next response file to confirm the previously rejected accounts now post. One full clean cycle is the milestone — not one clean upload.
- Fix the source data and regenerate; never hand-edit the fixed-width output.
- Keep DOFD and Date Opened anchored — only the changed fields move.
- Use a Compliance Condition Code only for genuine corrections to posted data.
- Re-validate to zero blocking errors, resubmit, then verify the next response file.
Preventing the next round of rejects
The whole point of a first painful cycle is that you never repeat it. Pre-validation is the lever: the same 240+ rule engine the bureaus effectively run can run against your file before it ever reaches an SFTP folder, so status/balance contradictions, blank DOFDs, RDW mismatches, and ECOA conflicts surface as blocking errors at your desk instead of as rejects a week later.
Build the habit of validating every file in sandbox/test mode before a live run. Sandbox produces the same validation output and the same generated structure without transmitting anything, which turns the response-file feedback loop from days into seconds. Pair it with the free readiness assessment before your first live submission so the structural and field-level issues are caught up front.
Finally, treat the reference pages as part of the workflow, not a last resort. Bookmark /metro2/status-code, /metro2/field, and /metro2/error, and load any unfamiliar file into /metro2/file-viewer the moment something looks off. Furnishers who pre-validate and decode early stop seeing reject files at all — the SFTP transfer and the bureau acceptance finally mean the same thing.
- Run the 240+ rule pre-validation on every file before it reaches the bureaus.
- Use sandbox/test mode to get response-file feedback in seconds, not days.
- Take the free readiness assessment before the first live submission.
- Keep /metro2/status-code, /metro2/field, /metro2/error, and the file viewer in the loop.
Key takeaways
- A clean SFTP upload is not acceptance — rejects and errors only show up in the bureau response file.
- First-submission rejects come in clusters; group by reason code and fix the pattern once.
- The big four root causes: invalid status/balance combinations, bad or re-aged DOFD, RDW/length errors, and missing fields or ECOA mismatches.
- Never advance DOFD on resubmission and never hand-edit the fixed-width output — fix the source and regenerate.
- Pre-validation in sandbox/test mode turns a days-long reject loop into seconds and eventually eliminates rejects entirely.
- Use the reference pages — /metro2/status-code, /metro2/field, /metro2/error, and the file viewer — as part of the workflow, not a last resort.
FAQ
My file uploaded successfully but nothing posted. What happened?
A successful SFTP transfer only confirms the bytes arrived. Acceptance is reported separately in the bureau's response file, which pairs each record with reject or error reason codes. Parse that response file in the viewer at /metro2/file-viewer and group the codes to find the root cause — first submissions usually fail in a few large clusters.
What is a DOFD error and why does it re-age accounts?
Date of First Delinquency is the anchor for when a negative item ages off. It must fall after Date Opened, on or before every later date, and stay fixed once established. If a template copies the reporting date into DOFD each cycle, the date moves forward and illegally re-ages the account — a defect the validator catches before generation. Establish DOFD once and carry it forward unchanged.
Why would an entire file reject when the data looks correct?
That is almost always a structural problem, not a data one. Check the Record Descriptor Word (RDW) — the first four characters of each segment must equal its true byte length — and confirm Header and Trailer record counts match the actual count. Truncated fields, wrong encoding, or bad padding shift every following field and reject the whole block. Generating through the production pipeline computes RDW and counts automatically.
How do I fix an ECOA mismatch?
Treat the Base Segment and its J1/J2 segments as one statement about who owes the debt. Every associated consumer needs a J-segment with a valid ECOA code that is consistent with the Base Segment — individual (1), joint (2), authorized user (3), co-signer (4), and so on. Commercial tradelines use a different ECOA set (W and the 6A/6B/7A family). The field reference at /metro2/field lists the valid values.
Do I need a Compliance Condition Code when I resubmit corrections?
Only for genuine corrections to data that already posted. If records were rejected and never posted, you are simply resubmitting them clean and no Compliance Condition Code is needed. Reserve the CCC family for cases where you are correcting information the bureau already has on file.
How do I stop getting reject files entirely?
Pre-validate every file against the 240+ rule engine and run it in sandbox/test mode before any live submission. That surfaces status contradictions, blank DOFDs, RDW errors, and ECOA conflicts at your desk in seconds instead of as bureau rejects a week later. Combined with the free readiness assessment before your first live run, most furnishers reach the point where every transfer posts cleanly.
Catch the rejects before the bureaus do
Run your Metro 2 file through 240+ validation rules and sandbox test mode before it ever ships. Decode any error against the field, status-code, and error references, then generate a bureau-ready file and deliver it over automated SFTP.