Credit provider (CP) as system of record: files and reconciliation

CP and DCA files, system of record, and reconciliation

For the conceptual frame (SoR vs GL, write-off and charge-off, why CP stays authoritative), read Source of Record first, then return here for files and dual-state detail.

Non-negotiable principle

The credit provider (CP) is the system of record for balance, payments, status, and outcomes that drive regulated or financial reporting. The DCA executes collection, reports state, sends payment notifications, and may request recall. The DCA must not silently override CP truth.

NPV (short)

Net present value compares discounted expected recoveries minus costs (internal, DCA commission, legal, time) across internal work, first DCA, second DCA, debt sale, or abandon. Conduct overlays (vulnerability, complaints, hardship, legal bars) can override pure NPV.

File types in detail

Names differ by vendor; functions should not.

Minimum file set

Aligned with Requirements (interface inventory). CP pushes authoritative payments, balance, and master-data updates; DCA pushes collections, requests, and reported state.

FlowDirectionFrequency (typical)Role
Allocation / placementCP to DCADaily or weeklyNew placements, tier (1st, 2nd), refer amount
CP payment and balance feedCP to DCADaily or same-dayPayments and adjustments on CP ledger; updated balance
CP account delta (master-data)CP to DCADailyContact details, flags, hardship or complaint hold, status changes
Recall / stopCP to DCADaily or intradayStop work; reason codes; suppression
Contact / activityDCA to CPDailyOutcomes, disposition taxonomy
Payment collected by DCADCA to CPDailyAmounts, allocation, reconciliation
Remittance / feesDCA to CPDaily or weeklyNet to client after fees and tax lines
DCA requests and escalationsDCA to CPDaily or eventRecall request (RQT), hardship request or referral, dispute, close or escalate; CP decides
DCA-reported stateDCA to CPDailyReported balance, arrangement status, PTP (reconcile to CP authoritative ledger)

Recall process and file design

Recall must be buildable and provable. Treat it as two paired flows: CP to DCA (instruction and authority) and DCA to CP (request, evidence, acknowledgement). Narrative: Recall and reassignment. Control domains: Controls framework.

Recall file (CP to DCA)

Must carry stable identifiers and intent. Typical columns: Account_ID (CP key), Placement_Id or vendor batch reference, Recall_Effective_DateTime in agreed timezone, Recall_Reason_Code, Recall_Category (compliance, strategic, data defect), Stop_Instruction (all channels, outbound only, letters only, as policy defines), Suppression_Flags (credit bureau, marketing, third party), CP_Authorised_By or system id for audit, Narrative_Text only as secondary to codes. For compliance recalls, avoid optional “defer” fields on the CP side unless explicitly prohibited by policy.

Recall request and extension (DCA to CP)

The vendor feed must support: Account_ID, Request_Type (recall request, extension, strategy proposal), Request_DateTime, Request_Reason_Code, Proposed_Next_Strategy, Supporting_Rationale (structured plus short text), Arrangement_Reference if the request ties to an active plan, Requested_Effective_DateTime for extensions. CP responses should return as a decision file or workflow API with accept or reject, decision maker, and effective time.

Recall SLA and runtime

Define expected timing for: vendor acknowledgement of receipt, removal from dialler, cessation of new letters, confirmation that runtime status is no longer “active collection” for that placement, and update of DCA-reported state files to match. Separate SLAs for compliance versus strategic recalls. Failure to meet SLA is both a vendor breach and a conduct risk event when customers are contacted after a valid stop instruction.

Recall reconciliation

Detect: CP shows recalled while DCA still shows active; DCA status stale; contact or letter events after recall effective time; arrangement conflict after recall (for example plan still shown as active at vendor). Automated checks should compare last contact timestamp to recall effective timestamp and flag exceptions. See Reconciliation and exception management and R1 / R2 traceability.

Dual-state reconciliation

Store CP fields and DCA-reported fields in parallel (for example CP_Balance vs DCA_Current_Balance; arrangement status on both sides). Reconcile daily for operations, weekly for trends, monthly for governance and attestation.

When CP and DCA differ

Differences are normal during latency windows; they are unacceptable when they drive customer contact with wrong balances or after a recall should have stopped work. Operational rule: customer-facing scripts use CP authoritative balance unless policy explicitly allows a temporary DCA-side display with documented tolerance.

Arrangement and payment mismatch examples

Double contact risk

If recall files batch overnight while diallers run intraday, you can contact customers who should be suppressed. Mitigation: intraday recall channel for conduct-urgent cases; kill lists; reconciliation checks that compare “last contact time” to “recall effective time.” See Reconciliation and exception management.

Recall: CP vs DCA request

Six audit questions (per account)

  1. Refer date to DCA1?
  2. Refer amount at that time?
  3. Recall date from DCA1?
  4. Balance at recall and current CP authoritative balance?
  5. Why recalled (coded)?
  6. Why moved to DCA2 (strategy, not only “recalled”)?

See Glossary for R1, R2, SoT. Back to pack home