R1 / R2 traceability model

Pragmatic field set to answer audit questions on placement, recall, and strategy moves

Purpose. Answer six questions without archaeology: refer date and amount, recall date and balance, reasons, DCA-reported snapshot, and what was proposed versus what CP actually did next. Implement as columns in the CP recoveries book or equivalent, fed by placement, recall, and DCA state files.

Audit questions this must answer

When was this account referred to DCA1, and at what refer amount?
When was it recalled from DCA1, at what balance, and why?
What did the DCA believe the balance and arrangement status were at recall?
Why did CP move it to DCA2 (strategy), as distinct from “DCA asked”?
Same four questions for R2 if used.

R1 field set (illustrative names)

Field	Description
R1_DCA	Identifier of first DCA vendor
R1_Refer_Date	CP-recognised placement date
R1_Refer_Amount	Authoritative refer balance at placement
R1_Current_Balance	CP authoritative balance while at R1 (rolling)
R1_Status	OPEN / RECALL_PENDING / CLOSED
R1_Recall_Request_Date	When DCA sent RQT if applicable
R1_DCA_Reported_Recall_RQT_Date	As reported by DCA (should match R1_Recall_Request_Date when aligned)
R1_DCA_Reported_Recall_RQT_Reason	Vendor reason text or code for the request
R1_Recall_Date	When CP executed stop work (actual recall)
R1_Recall_Reason	CP-coded reason (compliance, strategy, customer paid, and so on)
R1_Recall_Category	COMPLIANCE \| STRATEGIC \| DATA_CONTROL (taxonomy yours)
R1_Recall_Balance	CP balance at recall event
R1_DCA_Reported_Balance	Snapshot from DCA state file near recall
R1_DCA_Reported_Status	DCA workflow status
R1_DCA_Reported_Arrangement_Status	Active, broken, none, and so on
R1_Next_Strategy_Proposed	What DCA or ops proposed (R2, internal, sale)
R1_Next_Strategy_Actual	What CP approved (must be populated before R2 refer if applicable)

These fields exist because recall request and actual recall are different moments; category explains regulator and audit questions; balance at recall anchors cohort and fee arguments; proposed versus actual next strategy explains DCA1 to DCA2 moves without relying on oral history.

R2 field set

Mirror the same pattern with R2_ prefixes. R2 must never be “empty history.” If R2 exists, R1 must be closed with recall timestamps and balances.

Recall request versus actual recall

RQT is not permission by itself. Store both the request timestamp and the CP decision (approve or reject) and the actual recall execution time. SLAs often require stop work within hours for conduct cases; strategy recalls may batch daily. Reporting should not confuse “asked” with “stopped.”

Proposed versus actual next strategy

DCA may propose R2 with commercial motivation. CP may choose internal work instead. If you only log “recalled,” you lose the decision quality story for NPV feedback and vendor scorecards.

Why this supports reporting

Vintage and spin-down reports need clean cohort boundaries. If R1 and R2 placements overlap in reporting because recall was late, recovery rate numerators double-count or miss cash. Trace fields align cohort membership to CP truth, not DCA campaign labels.

Why this supports DCA comparison

Comparing DCA vendors fairly requires similar populations and handoff points. If one vendor receives more “cold” R2 transfers from failing peers, raw recovery curves mislead unless reasons and refer balances are visible.