First-Time Metro 2 Furnisher Launch Checklist

Reporting to the credit bureaus for the first time is less like flipping a switch and more like getting a small airplane certified to fly. The Metro 2 format itself is the easy part once you understand it. The hard part is everything around it: the legal duties you take on the moment you become a furnisher, the separate onboarding process at each bureau, and the discipline of producing a clean, internally consistent file every single month. Skip a step and you do not get a friendly error message. You get a rejected file, a silently dropped record, or worse, an inaccurate tradeline sitting on a real person's credit report.

This checklist is written for the team standing at the start of that runway: a lender, a property manager, a debt buyer, a fintech, a nonprofit, or any organization that has decided it needs to report. It assumes you have never furnished before and walks the sequence in the order the work actually has to happen. Compliance prerequisites come first because they shape your data. Subscriber codes come next because nothing reaches a bureau without them. Then data readiness, field mapping, validation, a test submission, go-live, and the monthly cadence that keeps you in good standing.

Wherever a step maps to something concrete in Metro 2 the article names the field, the segment, or the status code involved, and points to the reference pages on this site so you can look up the exact specification while you work. The goal is not to make you a CRRG expert overnight. It is to keep you from making the handful of mistakes that derail almost every first launch.

Step 1: Understand the duties you are taking on

Becoming a furnisher is a legal status, not a technical one. Under the Fair Credit Reporting Act, the entity whose name sits in the file is responsible for the accuracy of every record it sends and for investigating disputes about that data. You should resolve this before you write a single line of a file, because the answers change how you store data, who can touch it, and what your monthly process has to include.

The two FCRA obligations that bite first-time furnishers hardest are accuracy and dispute handling. Accuracy means you may not report information you know, or have reasonable cause to believe, is incorrect, and you have to keep it current as balances and statuses change. Dispute handling means that when a consumer disputes a tradeline, you must conduct a reasonable investigation and either confirm, correct, or delete the item within the statutory window. That investigation reaches you as an ACDV from the bureau, so your launch plan needs an owner for those before you ever go live.

Practically, that means naming a responsible person, writing down how a consumer reaches you to dispute, and deciding how you will correct or delete data once it is out in the world. A correction is not just re-sending the right value; certain fixes require specific mechanics in the format, such as setting the Compliance Condition Code to XB to indicate an account is under dispute, or using a Special Comment to flag a settled or transferred account.

Confirm the legal entity that will be named as the furnisher and that its information is consistent across every bureau application.
Name an accountable owner for data accuracy and for dispute (ACDV) responses, with a backup.
Document a consumer-facing dispute path (address, email, or portal) and your internal SLA for investigating, well inside the FCRA window.
Decide your policy for corrections and deletions, including how you will represent disputed accounts (Compliance Condition Code XB) and settled or closed ones.
Confirm you have a permissible purpose and the consumer relationship that justifies reporting the account in the first place.

Step 2: Apply for a subscriber code at each bureau

There is no single front door to the credit reporting system. Equifax, Experian, TransUnion, and Innovis are separate companies, and you have to be approved as a data furnisher with each one individually. Each issues you a subscriber code (sometimes called a subscriber number or member code) that identifies you in the file and in their systems. Until you have that code, nothing you generate can be delivered, so start these applications early; approval and the site inspection that often accompanies it can take weeks.

Expect each bureau to vet you. They commonly ask for business registration documents, proof of a permissible purpose, a description of the accounts you intend to report, expected monthly volume, and sometimes a physical site inspection to confirm you can secure consumer data. Apply to all four in parallel rather than serially. Many first-time furnishers begin live reporting with the bureaus that approve first and add the others as their codes come through, which is fine as long as your file generation can be scoped per bureau.

Your subscriber codes are not just paperwork; they become data. They drive the Identification Number in the file and have to match what each bureau expects, byte for byte. A transposed digit or a code used for the wrong bureau is one of the most common reasons a first file is rejected. Our bureau subscriber code prep guide covers the application logistics in depth and is worth reading alongside this step.

Apply separately to Equifax, Experian, TransUnion, and Innovis; treat them as four independent onboarding tracks.
Gather the common evidence package up front: entity docs, permissible purpose, account-type description, and projected monthly volume.
Prepare for a possible site inspection or security questionnaire before approval.
Record each subscriber code and the exact identifier format each bureau expects; these populate the file's identification fields.
Decide which bureaus you will launch with first if codes arrive at different times.

Step 3: Get your source data clean and complete

Most failed launches are not format failures; they are data failures wearing a format costume. The Metro 2 layout is unforgiving about a handful of fields that have to be present and correct on every account, and the most expensive of these is the Date of First Delinquency. DOFD anchors the seven-year FCRA obsolescence clock. If it is wrong, an account can legally drop off too early or, worse, linger past the point where it should have aged off. Before you map anything, confirm you can source an accurate DOFD for any account that has ever been delinquent.

Alongside DOFD, audit the other dates and identifiers that the format treats as load-bearing: Date Opened, Date of Account Information (the as-of date for the reporting period), and the Date of Last Payment. Each has to be a real date in the account's history, not a placeholder. On the consumer side, you need a name, a current address, and ideally an SSN and date of birth so the bureaus can match the record to the right file; thin identification is a leading cause of unmatched records that simply never post.

Decide your account scope now too. Metro 2 supports both consumer and commercial tradelines, and a commercial account is reported differently, using ECOA code W and the appropriate account-type and portfolio designations. If you are reporting business accounts, flag them in your source data before mapping so they route to the right treatment rather than being silently coerced into a consumer shape.

Confirm an accurate Date of First Delinquency for every account that has been delinquent; this drives the seven-year obsolescence clock.
Validate Date Opened, Date of Account Information, and Date of Last Payment as real historical dates, not defaults.
Ensure each consumer record carries enough identification (name, address, ideally SSN and DOB) to match at the bureau.
Tag commercial accounts explicitly (ECOA W) so they are reported as business tradelines rather than consumer ones.
Resolve duplicate accounts and stale balances at the source before they reach the file.

Step 4: Map your fields and pick your status codes

With clean data in hand, the next job is translation: turning your spreadsheet or export into the fixed-width Metro 2 structure. You do not have to do this by hand. Importing a CSV or Excel file auto-detects the field mapping, matching your columns to the format's fields so you confirm rather than construct the mapping. Spend your attention on the fields that carry the most meaning rather than re-deriving the entire layout.

The single most consequential field is the Account Status. It tells the bureau the current state of the account each period: status 11 for current, 71 through 84 for the progressive stages of delinquency, 93 for collection, 97 for charge-off, and so on. Getting the status wrong is not cosmetic; status 11 on an account that is actually 90 days past due reports false good news, and the reverse damages a consumer who is current. Our status code reference lists every value and what it means, and the field reference does the same for every position in the layout. Keep both open while you map.

Mapping is also where the file's structure takes shape. Each account is a base segment, and additional information attaches as segments: a J1 or J2 for associated consumers such as a co-borrower or authorized user, a K segment for the original creditor on a purchased or collection account, an L segment when an account number or identifier changes. Map the relationships you actually have rather than emitting empty segments, and let the importer flag anything it could not place rather than guessing.

Let the importer auto-detect the mapping from your CSV or Excel, then verify the high-stakes fields by hand.
Choose the correct Account Status per account (11 current, 71-84 delinquency stages, 93 collection, 97 charge-off) using the status code reference.
Map associated consumers to J1 or J2 segments for co-borrowers and authorized users.
Add K segments for the original creditor on purchased or collection accounts and L segments where identifiers change.
Cross-check every position against the field reference; confirm the mapping rather than assuming it.

Step 5: Validate against the rule engine before anyone else sees it

A Metro 2 file can be perfectly formatted and still be wrong. Field lengths can be right while the values inside them contradict each other: a charge-off status with no charge-off amount, a closed date earlier than the date opened, a balance that disagrees with the high credit, a DOFD that would have aged the account off years ago. The bureaus run their own validation on intake, and a file that trips those checks gets rejected or partially dropped. The point of validating first is to catch all of that on your side, where fixing it is cheap.

The platform runs every file through a rule engine covering 240-plus CDIA CRRG rules. It checks structure, cross-field consistency, date logic, and the conditional rules that say if this field has that value, this other field is required. Each finding lands in a result you can read line by line, and the error reference explains what each rule means and how to satisfy it. Treat a clean validation as the gate for the next step: do not submit a file that still has unresolved errors.

You do not even need to import to start sanity-checking. The free in-browser file viewer at the file viewer page parses a Metro 2 file and shows you the decoded segments and fields, which is a fast way to confirm a sample looks right before you commit to a full run. Use it early, then rely on the full rule engine once your real file is assembled.

Run the full file through the rule engine and resolve every error before moving on; do not submit with open findings.
Pay special attention to cross-field rules: status versus amounts, date ordering, and balance versus high credit.
Use the error reference to understand each finding rather than guessing at a fix.
Spot-check decoded segments in the free in-browser file viewer before a full run.
Re-validate after every correction; fixing one field can surface a dependent rule you had not hit yet.

Step 6: Submit a test file in sandbox first

Once your file validates cleanly on your side, the next step is to prove it works end to end without touching a real consumer's report. Use sandbox or test mode to do a dry run of generation and delivery. This confirms that the file your pipeline produces is the file you think it is, that your subscriber identifiers are placed correctly, and that the delivery mechanism is wired up, all before a single byte reaches a production bureau system.

Many bureaus also support or require a test submission of their own as part of onboarding. They will take a sample file, run it against their intake, and tell you whether it would post. This is the moment to surface mismatches that only the bureau can see: an identifier that does not match their records, a header detail they expect formatted differently, an account type they do not accept under your code. Plan for at least one round of corrections here; a first test file passing untouched is the exception, not the rule.

Delivery itself is automated. The platform delivers files to Equifax, Experian, TransUnion, and Innovis over automated SFTP, so once your codes and routing are configured you are not hand-uploading anything. Validate that routing in the test phase: confirm each bureau's file goes to the right destination with the right credentials, and that you can see the result, before you flip to live.

Do a full generation-and-delivery dry run in sandbox or test mode before any live submission.
Use each bureau's own test intake where offered; expect at least one correction cycle.
Confirm subscriber identifiers and file headers match exactly what each bureau expects.
Verify automated SFTP routing per bureau, with the right destination and credentials, during the test phase.
Treat a passing test as the gate to go-live, not as the finish line.

Step 7: Go live, then read the response file

Go-live is the smallest step on this list because the work that makes it safe already happened. With approved subscriber codes, clean validated data, and a passing test behind you, the live submission is a controlled repeat of the test with production routing. Start narrow if you can: a first production file with your full record set is fine once validation is clean, but plan to watch the response closely rather than firing and forgetting.

Submitting is not the end of the loop, because the bureaus talk back. After a file posts, you get a response file that tells you which records were accepted and which were not, and why. Parsing that response is how you find the records that silently failed to post: an unmatched consumer, a rejected account type, a duplicate. The platform parses CRA response files so those outcomes land in front of you instead of disappearing. A record you submitted is not a record that posted until the response confirms it.

Build the response review into your launch, not your eventual steady state. The first one or two cycles after go-live are where the bureau-side issues you could not see in testing finally surface, and the furnishers who handle launch well are the ones who treat the first response file as a required step rather than an optional report.

Repeat the validated, tested pipeline with production routing for the live submission.
Parse the CRA response file every cycle and reconcile accepted versus rejected records.
Investigate every non-acceptance: unmatched identity, rejected account type, or duplicate are the common causes.
Treat the first one or two post-launch response files as a required review, not a formality.
Confirm a record posted before you consider it reported.

Step 8: Lock in the monthly cadence

Furnishing is a subscription to a process, not a one-time project. The bureaus expect data on a regular cadence, typically monthly, and gaps or erratic reporting hurt both your standing and the consumers whose accounts go stale. The discipline that gets you through launch is the same discipline that keeps you compliant: pull current data, set the Date of Account Information to this period, update every Account Status to reflect the account's real state, validate, deliver, and reconcile the response.

The status field is where ongoing accuracy lives or dies. An account that was current last month may be 30 days late this month, paid off, or in collection. Each cycle you are restating the truth, so the status, the balance, and the dates have to move with reality. This is also where dispute handling intersects your cadence: if an ACDV came in, the correction or the dispute flag (Compliance Condition Code XB while it is contested) has to be reflected in the next file, not deferred.

Set up the operational scaffolding so the cadence does not depend on one person remembering. Use webhooks to get notified when files generate or validation completes, lean on the audit trail so every submission has a record of who sent what and when, and keep the dispute owner from Step 1 in the loop each cycle. The first month is the hardest; by the third, a well-built process runs itself.

Commit to a fixed monthly cadence and update the Date of Account Information each cycle.
Restate Account Status, balance, and dates every period to match the account's real state.
Fold dispute outcomes into the next file: corrections applied, and disputed items flagged with Compliance Condition Code XB.
Use webhooks and the audit trail so the cadence is operational, not dependent on memory.
Reconcile each cycle's response file as part of the routine, not as an afterthought.

The Metro 2 launch checklist for first-time furnishers