Nonprofit Lender's First 300 Metro 2 Records

Picture a small nonprofit lender — a CDFI that originates credit-builder loans for people with thin or no credit files. The whole point of the product is that on-time payments should show up on a borrower's credit report. For two years they had been making the loans but not reporting them, because "furnishing data to the bureaus" sounded like a compliance project they did not have the staff for. Their entire portfolio lived in a loan-servicing spreadsheet and a payment ledger.

This playbook follows that lender from zero to their first accepted Metro 2 file: roughly 300 active credit-builder tradelines, reported to all four consumer bureaus. It is an illustrative scenario, not a named customer — but every step, field name, and error described here is real, and is exactly what a first-time furnisher works through.

If you run a nonprofit, a CDFI, a community lender, or any small portfolio that has never furnished before, this is the shape of the work. None of it is hard once it is broken into steps. The two things that trip up almost every first-timer are the same two things this lender hit: getting subscriber codes from the bureaus, and getting the dates right — specifically Date of First Delinquency (DOFD), Date Opened, and the ECOA association code. The validator catches the date problems before the bureaus ever see them, which is the whole reason a clean first file is achievable.

Step 1 — Get subscriber codes before anything else

Nothing can be furnished until each bureau issues the lender a subscriber code (Experian and TransUnion call it a subscriber code; Equifax calls it a member number; Innovis issues one too). The code identifies who is reporting and is stamped into the header of every file. There is no way to shortcut this — a beautifully formatted file with no valid subscriber code is simply rejected at intake.

The lender applied to each bureau's data-furnisher program. The bureaus want to know what you are: a regulated lender, the loan types you report, expected monthly volume, and that you have a permissible purpose and a dispute-handling process under the FCRA. For a CDFI furnishing credit-builder installment loans, this is a clean story to tell, but it still takes a few weeks per bureau and they do not all move at the same pace.

A practical reality worth planning around: you will almost never have all four codes on the same day. The lender got TransUnion and Experian first, started reporting to those two, and added Equifax and Innovis to the same monthly file as each code arrived. In Metro2 each bureau destination is its own SFTP delivery, so you can switch a bureau on the moment its code lands without touching the rest of your setup.

Apply to all four bureaus in parallel on day one — the codes are the long pole, not the file.
Have your loan types, monthly volume estimate, and FCRA dispute process written down before you apply.
Store each code carefully; it goes in the file header and a wrong digit fails the whole file.
Expect staggered approvals — design your process to add bureaus one at a time.

Step 2 — Export the servicing spreadsheet as-is

The instinct of most first-timers is to hand-build a Metro 2 file, or to reshape their spreadsheet into some imagined "bureau format" before importing. Do not. Metro2 imports the CSV or Excel you already have and auto-detects the field mapping, so the cleanest path is to export the servicing data exactly as it lives in your system.

For this lender that meant one row per loan with the columns a servicing spreadsheet naturally has: borrower name, SSN, date of birth, current address, the loan's open date, original loan amount, current balance, scheduled monthly payment, the account number, and the payment status. Their credit-builder loans are installment loans, so each is a single tradeline with a term and a balance that pays down over time.

One column that does not exist in most servicing spreadsheets but matters enormously is the Date of First Delinquency. More on that below — for the first export the lender simply left it blank for current accounts and flagged the handful of loans that had ever gone late, which is exactly the right move.

Export the raw servicing data — do not pre-format it into fixed-width or invent a layout.
Include identifiers (name, SSN, DOB, address) and the account fields (open date, amount, balance, monthly payment, account number, status).
Mark which loans have ever been late; leave DOFD blank on accounts that have always been current.
CSV or Excel both import; keep one row per loan.

Step 3 — Import and let the field mapping auto-detect

On import, Metro2 reads the column headers and maps them to Metro 2 fields automatically: "Original Amount" to the Original Loan Amount field, "Balance" to Current Balance, "Open Date" to Date Opened, and so on. Where a header is ambiguous it asks you to confirm rather than guessing silently. The lender's spreadsheet mapped almost entirely on the first pass; the only columns needing a human decision were the status column and the joint/individual indicator.

Two fields always need a deliberate choice because no spreadsheet has them in Metro 2 form. The first is the Account Status / payment-status code — the lender's plain-English "Current" had to become the correct Metro 2 status code (status 11 for an account paying as agreed). The free reference at /metro2/status-code lays out every code, from current through the various 30/60/90-day buckets up to charge-off and collection, and the field-level reference at /metro2/field explains each segment field individually.

The second is the ECOA association code, which describes the borrower's relationship to the debt. Almost every credit-builder loan here was a single borrower, so the right value was ECOA code 1 (individual). Co-signed or joint loans use other codes (2 for joint contractual liability, for example). Getting this wrong is one of the most common first-file defects, which is why the importer surfaces it for confirmation instead of defaulting it.

Auto-mapping handles the obvious columns; you confirm the ambiguous ones.
Translate plain-English status into a Metro 2 status code (current = 11) — see /metro2/status-code.
Set the ECOA code per loan: 1 for individual, 2 for joint contractual liability.
Use /metro2/field to understand any segment field the mapping asks about.

Step 4 — Run validation and read what it flags

Before generating anything, the lender ran the records through the validator — a 240+ rule engine that checks each tradeline against CDIA CRRG requirements. This is the step that makes a clean first file realistic: the bureaus will reject or silently drop bad records, but the validator tells you what is wrong while you can still fix it, in plain language, with the offending field named. The error catalog at /metro2/error documents what each validation message means.

The lender's first run came back with three clusters of issues, all of them classic first-file mistakes and all of them about dates and codes rather than the data being "bad":

These were not surprises once explained — they were the difference between a spreadsheet's worldview and the bureau's. The validator turned a vague fear ("what if our file is wrong?") into a finite, named checklist.

A batch of accounts had Date Opened after the reporting date — a data-entry artifact where a few loans had a placeholder future open date. Invalid; fixed at the source.
Several loans marked late were missing a Date of First Delinquency, which is mandatory once an account is delinquent or charged off.
A handful of joint loans still carried ECOA code 1 (individual) instead of the joint code — caught because the borrower-count and ECOA value disagreed.
Monetary fields needed to be whole, properly-scaled amounts — the platform normalizes money internally so balances report correctly rather than off by a factor.

Step 5 — Fix the dates: DOFD, Date Opened, and why they matter

The single most important field a first-time furnisher learns is the Date of First Delinquency. DOFD is the date an account first became late and then never caught back up to current. It is the field that drives the FCRA seven-year obsolescence clock — a derogatory item ages off a credit report seven years from the DOFD, not from when you reported it. Reporting the wrong DOFD, or moving it forward when an account re-ages, is one of the most serious furnisher errors there is, so the validator is strict about it.

For this lender the rule played out simply. The roughly 290 always-current loans correctly had no DOFD — you do not have a first delinquency if you have never been delinquent. The ten or so loans that had gone 30+ days late needed the actual calendar date of that first missed-and-never-recovered payment, pulled from the payment ledger. Once an account is reported with a delinquent status, DOFD becomes required; the validator's job is to make sure you never report a late account without it.

Date Opened was the easier fix: the placeholder future dates were corrected to the true origination dates from the loan docs. With Date Opened, DOFD, and the account status now internally consistent, the records passed. It is worth loading the corrected file into the free in-browser viewer at /metro2/file-viewer at this point — it renders the fixed-width segments field by field so you can eyeball that the dates landed in the right positions before you ship.

DOFD = the date the account first went late and stayed late; it never moves forward on a static delinquency.
DOFD drives the 7-year FCRA obsolescence clock — accuracy here is a compliance issue, not a formatting one.
Current accounts have no DOFD; delinquent/charged-off accounts must have one.
Confirm Date Opened reflects true origination, not a servicing placeholder.

Step 6 — Generate the bureau-ready file

With validation green, the lender generated the Metro 2 file. Metro2 produces the bureau-ready fixed-width output: a Header Record identifying the furnisher and the reporting cycle, one Base Segment per tradeline carrying the account-level fields, the relevant appended segments (the J1/J2 segments for any additional associated consumers on joint loans, for example), and a Trailer Record with the control totals the bureaus reconcile against.

Because this is a regulated, audited workflow, file generation runs through the production pipeline rather than a one-off export: monetary values are normalized to the correct scale, dates are computed in UTC so the FCRA boundaries are consistent, the validation result is recorded for the audit trail, and the file is stored with proper metadata. The lender did not have to think about any of that — they clicked generate — but it is the reason the file that comes out is the file the bureau accepts.

The output for this cycle was a single file containing the ~300 tradelines, formatted identically for each bureau destination (the subscriber code in the header is what differs per bureau). The lender opened it one last time in /metro2/file-viewer to confirm the record count and trailer totals matched their 300, then moved to delivery.

The generated file = Header + one Base Segment per account + appended segments (J1/J2 for joint) + Trailer.
Generation runs the full production pipeline: money normalization, UTC dates, audit record, stored output.
Trailer control totals must match your record count — verify before sending.

Step 7 — First SFTP submission

Each bureau receives furnisher files over SFTP into a mailbox tied to your subscriber code. Metro2 delivers the file automatically to Equifax, Experian, TransUnion, and Innovis, so the lender did not stand up its own SFTP client or manage keys by hand — they configured the destination once per bureau and the platform pushed the file.

For a genuine first submission, the safe move is to use sandbox / test mode first. The lender sent a test cycle, confirmed the transport and the file structure were accepted end to end, and only then promoted to a live submission. Reporting is a monthly cadence: furnishers send a full file each cycle reflecting the current state of every account, so the lender set the expectation internally that this is now a recurring monthly run, not a one-time event.

Because the codes had arrived staggered (Step 1), this first live cycle went to the two bureaus already approved, with the other two added to the next cycle as their codes cleared. That is completely normal and the bureaus do not penalize you for onboarding incrementally.

Delivery is automated SFTP to all four consumer bureaus — no manual SFTP client to maintain.
Send a test/sandbox cycle first to validate transport before going live.
Furnishing is monthly: each cycle is a full snapshot of every account, not just changes.
It is fine to go live on the bureaus you have codes for and add the rest next cycle.

Step 8 — Read the bureau acknowledgement

Submitting is not the finish line — the acknowledgement is. After a cycle, each bureau returns a response (an acknowledgement and, where applicable, exception detail) telling you what it accepted and what it kicked back. Metro2 parses these CRA response files so you are reading record-level outcomes instead of decoding raw return data by hand.

The lender's first acknowledgement was the moment of truth. The header and trailer reconciled, the overwhelming majority of the ~300 records were accepted, and a small number came back as exceptions — typically an identifier mismatch (an SSN/name/DOB combination the bureau could not confidently attach to a consumer) rather than a format defect. Those are normal on a first file: the bureau is matching your borrowers to existing consumer records and occasionally needs a cleaner identifier. The lender corrected the flagged identifiers and they cleared on the following cycle.

From there the workflow becomes routine and quiet: each month, export, import, validate, generate, deliver, read the acknowledgement, fix the handful of exceptions. The hard part — codes, mapping, and the date discipline around DOFD and Date Opened — was all in the first file. By the second cycle, this lender's borrowers were seeing their on-time credit-builder payments show up on their reports, which was the entire reason the organization makes the loans.

The acknowledgement, not the upload, confirms success — read it every cycle.
Metro2 parses CRA response files into record-level accepted/exception outcomes.
First-file exceptions are usually identifier matching, not format errors — fix and resubmit next cycle.
After the first clean file, the monthly loop is fast and low-effort.

How a nonprofit lender submitted its first 300 records to the bureaus