Reporting data lineage
Purpose. Layer 3 exists so that finance, first line, and risk see one coherent story. This page maps which system should drive which fields and where DCA-reported data plays a supporting role. It complements the conceptual frame in Source of Record.
Hard link: Layer 3 reporting should be built from CP-controlled data and reconciled views. DCA-reported data supports operations, vendor challenge, and dual-state checks. It does not replace CP truth for authoritative balance, placement state, or financial outcomes.
Controls: Lineage is part of the controls framework. If you cannot explain which system produced a number, you cannot control it.
Layer 3 pack: Pack section definitions and metrics align with STD-DCA-REPORT-001 in docs/DCA-Governance; each Layer 3 field should trace to CP or DCA source per Reporting. A filled example sits in Sample monthly pack dashboard under DCA Governance (canonical).
Principle: CP-controlled backbone
Authoritative balances, payments posted to customer accounts, recall execution, and end-state codes should originate from CP systems (core plus recoveries book as designed). DCA feeds explain what the vendor did; CP feeds explain what the bank recognises.
Recovery rate (example lineage)
Definitions vary; pick one and publish it. A defensible pattern:
- Numerator: cash collected and attributed to the cohort in CP ledgers, net of refunds per policy, in the measurement window.
- Denominator: refer balance at cohort start on CP, with exclusions documented (for example fraudulent accounts removed).
Both should be computable from CP-controlled tables. If the DCA’s “recovery rate” differs, treat the gap as a reconciliation insight, not as an alternate truth.
Typical field ownership
| Reporting concept | Primary source | Secondary or challenge source |
|---|---|---|
| Open placement balance | CP recoveries book | DCA-reported balance |
| Cash collected | CP cash allocation / GL attribution rules | DCA payment file |
| Fees payable | CP accrual from contract rules | DCA remittance advice |
| Accounts placed / recalled | CP placement and recall logs | DCA confirmation files |
| Contact attempts and outcomes | DCA activity file (defined taxonomy) | QA sampling by CP |
| Complaints count | CP complaints register (system of record) | DCA internal log for triage |
| Hardship holds | CP flags driving suppression | DCA identification referrals |
Governance pack construction
Build the monthly pack by joining:
- CP cohort snapshot at period boundaries.
- CP-recognised cash and adjustments in period.
- Trace fields for R1 and R2 from R1 / R2 traceability.
- Vendor sections where DCA attests to operational metrics under contract.
Attestation should confirm that vendor sections were produced from agreed sources and any known breaks are listed.
Anti-pattern: parallel spreadsheets
If risk uses a spreadsheet built only from DCA PDFs while finance uses GL, you will get “successful” vendor meetings and failed audits. Lineage discipline is boring and essential.
Related: Reporting · Reconciliation · Back to pack home