The DS code implementation checklist

Everything a furnisher needs in place before the first DS code goes on a file — and what keeps it defensible in the cycles after. Work it in order: each phase assumes the one before it.

Phase 1 — Decide

Reporting is voluntary. The decision to report, and its scope, should be a documented policy decision — not a default that happens to a reporting team.

  • Make the reporting decision explicitly — report DS, or not, institution by institution and portfolio by portfolio. An undecided portfolio is a risk position either way; write down which one you are taking and why.
  • Scope it institution-wide — CDIA directs the code onto all applicable accounts at the same financial institution. The decision has to cover the whole book, not the one portfolio that asked first.
  • Assign an owner — one team accountable for DS reporting end to end, with compliance holding the evidence standard (Phase 2) and the dispute team holding the evidence file (Phase 5).

Phase 2 — Set the evidence standard

The gating question is what your institution accepts as verification. Settle it before the first cycle, and put it in writing.

  • Adopt CDIA’s two conditions as the test — verified active participation in a for-profit debt settlement program, and participation expected to materially alter repayment terms, including before any settlement completes.
  • Write the exclusions into the standard — debt management plans, credit counseling arrangements, and preliminary inquiries, informal discussions, or speculative negotiations never verify. Neither does a consumer negotiating alone.
  • Define the grades your team works to — what meets the standard (Verified: report) and what does not (Indicated: inquire only). If a result cannot show its company, status, and as-of date, it is not verification.
  • Fold the standard into your Regulation V procedures — §1022.42 expects reasonable written accuracy and integrity procedures. The DS evidence standard belongs in that document, named and dated.

Phase 3 — Wire verification into the file cycle

Timing is the operational heart of it: verification has to happen before the file is generated, so the code on the file and the evidence behind it sit in the same cycle.

  • Run the check pre-transmission — match the file you are about to send against current enrollment records (file review), or keep the book under continuous watch so decisions pre-date the file (monitoring). Retrofitting verification after transmission is how unsupported codes happen.
  • Fix turnaround inside the cycle — the corrections have to return with time to apply them before the transmission deadline. Put the turnaround in the agreement, not in an email thread.
  • Review both directions — accounts missing DS that verification supports, and accounts carrying DS that current verification no longer supports. Drop-outs and completions are corrections too.
  • Keep the pen — corrections are applied by your team to your file. You remain the furnisher of record, and the verification record lands in your records — where Regulation V §1022.41(d) expects the substantiation to be.

Phase 4 — Handle the out-of-cycle edges

Not everything waits for the monthly file. Two channels cover what happens between cycles.

  • Corrections: use the AUD (Automated Universal Dataform) in e-OSCAR to fix a tradeline out of cycle when an error cannot wait — a DS code that should not be there, or one a dispute has already surfaced. AUD is the exception path; the routine path is Phase 3.
  • Disputes: a consumer dispute about a DS code arrives through e-OSCAR as an ACDV and starts the FCRA §623(b) clock. The investigation runs from the verification record: status, company, grade, as-of date. If that record cannot be produced, the investigation starts from zero, on a deadline. See the disputes guide.
  • Lifecycle events: drop-outs, settlements reached, and completions between cycles change what the next file should say. They should reach the reporting team as events, not as surprises in the next corrections package.

Phase 5 — Retain, assign, repeat

A DS report can be questioned long after the cycle closes. What you keep, and who owns it, decides how that conversation goes.

  • Retain the evidence record per account — enrollment status, settlement company named, evidence grade and basis, effective and as-of dates, and the corrections package the result arrived in.
  • Retain the decisions — the policy decision (Phase 1), the written evidence standard (Phase 2), and each cycle’s accept/reject record on corrections. FCRA limitations can reach back years — the retention tail should match, up to five years from a violation.
  • Name the roles — reporting operations runs the cycle; compliance owns the standard and the written procedures; the dispute team holds the evidence file and the §623(b) playbook. DS fails in the handoffs, not in the definition.
  • Re-run the standard against new guidance — CDIA will publish implementation detail in the Credit Reporting Resource Guide. When it lands, the checklist gets a fresh pass — see the timeline for what is known and what is still to come.

Checklist questions

When exactly should verification happen?

Before the file is generated and transmitted — inside the same cycle the code will report in. Regulation V measures integrity by substantiation in the furnisher’s records at the time the information is furnished, so the verification record has to predate the transmission it supports.

What documentation should we keep?

The verification record behind every reported DS code (status, company, grade, as-of date), the corrections packages, the policy decision and written evidence standard, and the audit trail of each check — retained on a tail matched to FCRA’s limitations reach, up to five years.

Who should own DS reporting internally?

Three roles, explicitly: reporting operations runs the file cycle and applies corrections; compliance owns the evidence standard and the Regulation V written procedures; the dispute team holds the evidence file for §623(b) investigations. One named owner accountable across all three.

Can ScrubHits run the verification step for us?

Yes — that is the service. Verification runs through file review against the file you are about to transmit, monitoring against your whole book between cycles, or both — with the evidence record returned into your files for every line.

Verify before you report

Start with a mutual NDA and one file. We review the file you are about to transmit, hand back the corrections with the evidence behind each one, and you decide what reports.

Get Started
Prefer to look first? See how file review works
💬