What Is Metro 2? A Plain-English Guide to the Format

Who has to use it

Anyone who reports consumer accounts to a credit bureau. That is a wider group than most people expect, because it is not only lenders. The common categories:

• Banks and credit unions, which have reported for decades and usually have a core banking vendor doing it for them.
• Fintech lenders and buy-now-pay-later providers, the newest cohort and the one most likely to be reading this page.
• Auto lenders and mortgage lenders, where the collateral rules add reporting situations that unsecured lending never hits.
• Property managers reporting rent, and homeowner associations reporting dues.
• Debt buyers and collection agencies, who report accounts they purchased rather than originated.
• Utilities and telecom, usually through a subscription billing relationship, and medical billing operations.
• CDFIs and nonprofit lenders, for whom reporting is often the whole point: an on-time payment history is the product they are trying to build for their borrowers.

One thing worth being precise about, because it is where most newcomers form the wrong mental model. Nothing compels a company to report. There is no statute that says a lender must furnish data, and plenty of lenders never do. Reporting is a choice. What changes the moment you make that choice is that you become a regulated furnisher, and federal law now has opinions about the accuracy of what you send. That is a separate subject from the file format, and it is covered on what Metro 2 compliance means. The industry guides break down what each of these sectors reports and the situations specific to it.

What a Metro 2 file physically looks like

Open one in a text editor and you see a wall of characters. There are no commas, no tags, no column names, no quotes. Every line is the same length, padded out with spaces and zeros, and the meaning of any character depends entirely on where it sits on the line. The file does not describe itself. You need the CRRG, or a tool that has the CRRG built into it, to read one.

Structurally, a file is three kinds of record in a fixed order.

The segment reference covers what each supplemental segment is for and when it is required. If you want to see an actual record broken apart character by character rather than described in prose, the annotated Metro 2 format example walks through one.

Why fixed-width and not CSV or JSON

This is the first question every engineer asks, and the answer is history. The format was designed for mainframe batch processing, in an era when files moved on tape and were read by COBOL programs. Fixed-width records are the natural shape for that world: you can seek to a byte offset without parsing anything before it, every record occupies exactly the same amount of space, and there is no escaping problem because there are no delimiters to escape.

It persists for a much less romantic reason. Changing it would require every bureau and every furnisher on the continent to change at once. The standard has been extended rather than replaced, which is why you still encounter mainframe-era artifacts such as the option to send numeric values in a compact binary encoding instead of readable digits. If you run into that, see character versus packed format and block and record descriptor words, which are the two places the mainframe heritage most often bites a modern team.

What it costs you explains why reporting is harder than it sounds. A fixed-width file has no self-description, so nothing in it tells you when a value is in the wrong place. A JSON parser rejects a malformed document. A Metro 2 reader cannot: a field shifted one character to the left is still a perfectly valid line, it just means something different. There is no type system either, so a date, an amount, and a code are all just digits. Every error is a silent error until something downstream notices.

The five things every record must carry

Strip away the detail and every Base Segment is answering five questions about one account. Almost everything else in the format is elaboration on these.

Several of these accept only values from a published list rather than free text. The codes cheat sheet collects every one of those code sets in one place, and the account status codes get their own page because they are the ones people look up most. The full field reference has a page per field with the definition and the rules that apply to it.

Metro 2 versus Metro 1, and versus the bureaus' own APIs

Against Metro 1. Metro 1 was the earlier standard, and it is obsolete. You will not be asked to produce one, and no bureau will accept one today. It matters only as an explanation for the name and, occasionally, as an explanation for something odd you find in a legacy system that was built before the transition. The practical difference is that Metro 2 carries considerably more per account: a rolling payment history rather than a single status, room for co-borrowers and original creditors and account-number changes through supplemental segments, and the compliance and special comment fields that let a furnisher say something about the circumstances of an account rather than just its numbers.

Against a modern API. People reasonably ask why the bureaus do not just expose a REST endpoint and accept JSON. Some bureau products do have APIs, but they are generally for pulling data rather than furnishing it, and furnishing remains a batch file operation. Two things hold that in place: credit reporting is a monthly-snapshot model by design, which suits a batch file better than a stream of individual events, and inertia at this scale is enormous. Metro 2 is the interface for the foreseeable future, so a modern team's job is to generate it correctly rather than wait for it to be replaced.

How a file gets from your system to the bureaus

Once you are set up, reporting is a monthly loop with six steps.

1. Pick the as-of date. You choose a point in the month and every account in the file describes its state as of that date. Consistency month over month matters more than which date you pick.
2. Extract. Pull the accounts from your servicing or billing system. This is normally where the real work is, because your internal model of an account almost never lines up cleanly with the credit-reporting model of one.
3. Map and generate. Translate your internal states into the format's code values and write the fixed-width records. How to create a Metro 2 file covers this step in detail.
4. Validate. Check the file before it leaves. Record lengths and structure, valid code values, codes that have to agree with each other, dates that have to be consistent, trailer counts that have to balance against the records present.
5. Transmit. Send to each bureau by whatever secure channel that bureau specified when you were onboarded. Each has its own submission window, and missing yours costs you a cycle.
6. Reconcile. Read what comes back. Bureaus return acknowledgements and defect reports, and reading them is the step teams most often skip. A file that was accepted with warnings is not the same thing as a file that was right.

Everything before that loop, the applications, the agreements, the identifiers, and the test submission each bureau requires before turning you on, is a one-time project measured in months. How to become a data furnisher is the end-to-end version of that.

What happens when it goes wrong

Two failure modes, and they are nothing alike. Understanding the difference is most of what separates a furnisher who is on top of this from one who is not.

A reject is the bureau refusing a record or a whole file because it is malformed. A line is the wrong length, a code is not in the allowed set, the trailer counts do not match. You find out within days, you fix it, and the cost is usually a missed cycle for the affected accounts. Rejects are loud, annoying, and cheap. The error and reject code library documents the specific defects and how to fix each one, and common validation edits covers the checks the bureaus run on their side when your file arrives.

A dispute is different. It happens after a record has been accepted, when a consumer looks at their credit report and says the tradeline is wrong. Nothing about the file was malformed. The record was well-formed and inaccurate, and it sat on someone's report describing an account that does not exist the way the record says it does. When a dispute reaches a furnisher, whether directly or routed through a bureau, federal law obliges the furnisher to investigate it, respond within a statutory window, and correct anything the investigation shows to be wrong. That is a legal duty that attaches to the furnisher, and it is the reason field-level accuracy is worth more attention than format conformance. Fewer disputes start when the data is right.

The asymmetry is the thing to take away. Format errors announce themselves and cost you a cycle. Accuracy errors are silent and cost you a dispute, a correction, and a consumer whose report was wrong the whole time. What Metro 2 compliance means goes through both obligations in full.

Frequently asked questions