DEV Community

Keith Ransom
Keith Ransom

Posted on

What I Learned About the Credit System by Building a Dispute Automation Tool

#programming #webdev #career #fintech

Building a tool to automate credit bureau disputes taught me that the credit reporting system has a completely different data model than anything I'd worked with before.

Metro 2 Format: The Hidden Protocol

The credit bureaus (Equifax, Experian, TransUnion) don't use a modern API. They use Metro 2 — a fixed-width flat file format from the early 1990s. Furnishers (banks, lenders) submit monthly batches of Metro 2 files, and everything you see on your credit report is derived from those files.

The key fields that determine your credit score:

Position  Field Name          Type    Length  Description
001-002   Record Descriptor   N       2       Segment identifier
003-007   Account Number      AN      5       Truncated for privacy
008-011   Portfolio Type      AN      4       I=Individual, J=Joint
012-013   Account Type        AN      2       01=Mortgage, 07=Installment
...
Enter fullscreen mode Exit fullscreen mode

When a dispute goes wrong, it's almost always because someone doesn't understand that the bureau's "investigation" is just re-fetching the same Metro 2 record from the same furnisher who reported the error in the first place.

The Dispute Letter Is Not the Product

Most people focus on writing the perfect dispute letter. That's the wrong mental model.

The dispute letter is a trigger that initiates a data pipeline:

  1. Bureau receives letter → assigns investigation code
  2. Bureau sends ACDV (Automated Consumer Dispute Verification) to furnisher
  3. Furnisher has 30 days to verify, modify, or delete the tradeline
  4. Bureau updates Metro 2 record based on furnisher response
  5. Bureau sends result to consumer

If the furnisher responds "verified" without actually verifying, you have 15 USC 1681e(b) grounds. The investigation was not "reasonable."

What Actually Gets Items Removed

After building the automation:

  1. Procedural violations > factual disputes. "Verify" doesn't mean anything if the furnisher can't produce the original signed agreement. Debt sold 3+ times? The current holder may not have the original documents.

  2. Statute of limitations is a defense, not a delete trigger. The FCRA 7-year rule is a reporting limit, not a legal limit on the debt. Knowing the distinction matters.

  3. Method of verification letters are underused. After a "verified" result, you have the right to ask the bureau HOW they verified it. If they can't say, that's your next move.

  4. Separate bureau strategy matters. All three bureaus have different Metro 2 data from different furnishers at different update cycles. Dispute one at a time, see what comes back, adjust.

The Automation Layer

The tool I built handled:

  • FCRA deadline tracking (30/45/60 day windows)
  • Template generation with the exact statutory language
  • Response classification (verify/modify/delete/transfer)
  • Next-action recommendation based on response type

The hardest part wasn't the letter generation — it was the state machine for tracking multi-round disputes across multiple tradelines across three bureaus.

The Guide

I wrote up the full methodology — Metro 2 format explained, the 12 most common bureau error patterns, the exact dispute language that works for each type, and the escalation sequence.

Credit Bureau Mastery Guide — $29 →

Has anyone else built tooling in this space? The Metro 2 documentation is a nightmare to find.

Top comments (0)